Alexandre Passant | 6 Dec 2010 14:55

[foaf-dev] CFP - Abstracts deadline : ESWC2011 - Social Web and Web Science Track

(apologies for cross-posting)

### Abstracts due today ###

=====================================================================================                 

CALL FOR PAPERS : The 8th Extended Semantic Web Conference (ESWC)
Social Web and Web Science Track

http://www.eswc2011.org/
May 29 - June 2, 2011, Heraklion, Greece

=====================================================================================

* Chairs:  Alexandre Passant, DERI, IE and Denny Vrandecic, KIT, DE
* Abstract submission: December 6, 2010 (compulsory, no extension)
* Full-paper submission: December 13, 2010

http://www.eswc2011.org/content/cfp#Social%20Web%20and%20Web%20Science

=====================================================================================

The success of Social Web applications (often referred to as ‘Web 2.0’ applications) is manifested
through the fast growth of social networks and sites with user-generated content, like Facebook,
Twitter, YouTube, Wikipedia, Flickr, and many more. Many Social Web applications have simplified the
data publishing process using user-friendly and interactive tools and practices (such as Wikis,
tagging, and microblogging) and have decreased the cost and increased the incentive to contribute data.
In addition, some trends such as ubiquitous computing lead to new ways and means to share content in
real-time within social communities.

(Continue reading)

Toby Inkster | 13 Dec 2010 11:55
Picon
Gravatar

[foaf-dev] Fwd: relationship vocab

> -------- Forwarded Message --------
> From: Toby Inkster <mail@...>
> To: Ian Davis <lists@...>, foaf-dev@...
> Subject: relationship vocab
> Date: Mon, 13 Dec 2010 07:59:38 +0000
> Mailer: Claws Mail 3.7.2 (GTK+ 2.18.9; i586-mandriva-linux-gnu)
> 
> Ian,
> 
> Any chance of relaxing some of the domains and ranges?
> 
> My cats are brothers, but it would be pushing the definition of
> foaf:Person to assert that they're people.
> 
> rel:employedBy should probably have range foaf:Agent, as a significant
> number of people are employed by companies, partnerships and other
> organisations. Ditto the domain for rel:employerOf.

--

-- 
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>
Dan Brickley | 13 Dec 2010 13:16

Re: [foaf-dev] Fwd: relationship vocab

On Mon, Dec 13, 2010 at 11:55 AM, Toby Inkster <tai@...> wrote:
>> -------- Forwarded Message --------
>> From: Toby Inkster <mail@...>
>> To: Ian Davis <lists@...>, foaf-dev@...
>> Subject: relationship vocab
>> Date: Mon, 13 Dec 2010 07:59:38 +0000
>> Mailer: Claws Mail 3.7.2 (GTK+ 2.18.9; i586-mandriva-linux-gnu)
>>
>> Ian,
>>
>> Any chance of relaxing some of the domains and ranges?
>>
>> My cats are brothers, but it would be pushing the definition of
>> foaf:Person to assert that they're people.

"""The Person class represents people. Something is a Person if it is
a person. We don't nitpic about whether they're alive, dead, real, or
imaginary. """ http://xmlns.com/foaf/spec/#term_Person

If you describe your cat as a foaf:Person, you're just saying the cat
is a person. Many might disagree with you, but philosophers have been
arguing the toss over this for centuries and debatewise I expect it's
only going to get worse with the progress of science, rather than
better.

( I'd start with apes rather than cats, perhaps
http://en.wikipedia.org/wiki/Great_Ape_Project ...)

It's not FOAF's place as a technology to either decide whether (say)
human embryos at n weeks, or various living great apes, are 'persons'.
(Continue reading)

Toby Inkster | 13 Dec 2010 13:54
Picon
Gravatar

Re: [foaf-dev] Fwd: relationship vocab

On Mon, 2010-12-13 at 13:16 +0100, Dan Brickley wrote:
> If you want to say your cat is a person, you can do that. It's not
> wrong to do so, just a little unconventional or metaphorical. If you
> want to say something about your cat without asserting personhood,
> don't use foaf:Person. 

I am actually completely happy to assert personhood about my cats. My
own personal definition of personhood includes not just humans, but
anybody we'd say had a personality - most pets fall into that category -
at least as far as their owners are concerned.

But my broader point was that there are instances where one would want
to apply many of the relationship properties to non-human agents without
getting into a philosophical quandary.

Last week's episode of QI mentioned that all modern thoroughbred horses
are descended from at least one of just three stallions: the Byerley
Turk, the Darley Arabian, and the Godolphin Arabian. Thoroughbred horses
have their genealogy recorded in detail that you rarely see outside
records of genealogy of royalty. However, this couldn't be represented
using rel:descendantOf using the current definition of that property.

--

-- 
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>
Kevin Pickens | 13 Dec 2010 14:20
Picon
Gravatar

Re: [foaf-dev] Fwd: relationship vocab

Toby,


I agree with your point regarding relationship properties.  Further, it would seem to me that relationship properties should be almost universally expanded to refer to and imply that the entity having the property is a foaf:Agent.  A simple example: the grocery store down the street is a neighbour of the pharmacy next to it.  Neither is likely to be considered a foaf:Person, but they are both reasonably foaf:Agents.  The only relationship properties that seem inconsistent with non-foaf:Person entities are some of the more formal ones (I just can't see the the grocery store settling down, getting rel:engagedTo and becoming the rel:spouseOf the pharmacy - what would they talk about?).

To put this in a practical form, a person may want to say that they work for the grocery store next to the pharmacy.  With the current relationship properties, that doesn't work properly.  They could assert that they are a foaf:Person who is rel:employedBy (assuming the definition is expanded) the grocery and that they are the rel:neighborOf a foaf:Person who is rel:employedBy the pharmacy, but that would generally be interpreted as "we're neighbours and we work at the grocery and the pharmacy, respectively."

Cheers,
Kevin

On Mon, Dec 13, 2010 at 7:54 AM, Toby Inkster <tai-hn3ClYY61nJaa/9Udqfwiw@public.gmane.org> wrote:
On Mon, 2010-12-13 at 13:16 +0100, Dan Brickley wrote:
> If you want to say your cat is a person, you can do that. It's not
> wrong to do so, just a little unconventional or metaphorical. If you
> want to say something about your cat without asserting personhood,
> don't use foaf:Person.

But my broader point was that there are instances where one would want
to apply many of the relationship properties to non-human agents without
getting into a philosophical quandary.

_______________________________________________
foaf-dev mailing list
foaf-dev@...
http://lists.foaf-project.org/mailman/listinfo/foaf-dev
Karen Coyle | 13 Dec 2010 15:07
Gravatar

Re: [foaf-dev] Fwd: relationship vocab

Does it really make sense to try to shoehorn all of these concepts  
into foaf? It seems to me that in this and other projects we are  
trying to add general terms and relationships to more specific  
schemas. Why not elevate some concepts (like "next to", "name",  
"place") to be direct descendants of owl:Thing or owl:Class? They can  
still use the foaf namespace (it doesn't really matter what namespace  
is used) but people wouldn't struggle with trying to fit them into the  
original foaf realm of social networking. (Yes, it's true that RDF  
doesn't constrain you, but the human mind does. The fact is, using the  
term "Person" is not neutral; it means something to people, who in  
this case are less flexible than machines.) It's ok to outgrow the  
original concept, and not to try to keep everything inside its  
boundaries.

Besides, I see us re-defining the same general properties over and  
over, and most of them are buried in schemes where no one would think  
to look for them because it's just not the logical place to look.

kc

Quoting Kevin Pickens <kbpickens@...>:

> Toby,
>
> I agree with your point regarding relationship properties.  Further, it
> would seem to me that relationship properties should be almost universally
> expanded to refer to and imply that the entity having the property is a
> foaf:Agent.  A simple example: the grocery store down the street is a
> neighbour of the pharmacy next to it.  Neither is likely to be considered a
> foaf:Person, but they are both reasonably foaf:Agents.  The only
> relationship properties that seem inconsistent with non-foaf:Person entities
> are some of the more formal ones (I just can't see the the grocery store
> settling down, getting rel:engagedTo and becoming the rel:spouseOf the
> pharmacy - what would they talk about?).
>
> To put this in a practical form, a person may want to say that they work for
> the grocery store next to the pharmacy.  With the current relationship
> properties, that doesn't work properly.  They could assert that they are a
> foaf:Person who is rel:employedBy (assuming the definition is expanded) the
> grocery and that they are the rel:neighborOf a foaf:Person who is
> rel:employedBy the pharmacy, but that would generally be interpreted as
> "we're neighbours and we work at the grocery and the pharmacy,
> respectively."
>
> Cheers,
> Kevin
>
> On Mon, Dec 13, 2010 at 7:54 AM, Toby Inkster <tai@...> wrote:
>
>> On Mon, 2010-12-13 at 13:16 +0100, Dan Brickley wrote:
>> > If you want to say your cat is a person, you can do that. It's not
>> > wrong to do so, just a little unconventional or metaphorical. If you
>> > want to say something about your cat without asserting personhood,
>> > don't use foaf:Person.
>>
>> But my broader point was that there are instances where one would want
>> to apply many of the relationship properties to non-human agents without
>> getting into a philosophical quandary.
>>
>>
>

--

-- 
Karen Coyle
kcoyle@... http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Alexander Dutton | 14 Dec 2010 10:56
Picon

Re: [foaf-dev] Fwd: relationship vocab

On 13/12/10 13:20, Kevin Pickens wrote:
> To put this in a practical form, a person may want to say that they
> work for the grocery store next to the pharmacy.  With the current
> relationship properties, that doesn't work properly.  They could
> assert that they are a foaf:Person who is rel:employedBy (assuming the
> definition is expanded) the grocery and that they are the
> rel:neighborOf a foaf:Person who is rel:employedBy the pharmacy, but
> that would generally be interpreted as "we're neighbours and we work
> at the grocery and the pharmacy, respectively."

Can I stick my pedantry hat on and say that you're conflating the
organisation with the buildings it occupies?

#me rel:employedBy #grocery-co .
#grocery-co org:hasPrimarySite #grocery-store .

Now that your building isn't also an organisation, if you want to use
rel:neighbourOf for both people and places then either buildings are
agents (feasible if e.g. they can phone the police if burgled), or your
rel:neighbourOf can apply to non-agents too. I'd reckon you'd want a
separate ex:adjoins property that applies between geo84:SpatialThings
(and that this is a different concept to neighbourliness).

Alex
Dan Brickley | 20 Dec 2010 14:24

Re: [foaf-dev] js RDF help wanted! integrating FOAF++ RDF into Firefox Contacts

On Mon, Dec 20, 2010 at 1:25 PM, Tim Berners-Lee <timbl@...> wrote:
>
> On 2010-06 -12, at 18:36, Dan Brickley wrote:
>
>> +cc: TimBL ( ... Tim, can you pass this along to tabulator folks?)
>>
>> Hi folks
>>
>> I have made a rough start at integrating FOAF into the (rather cool)
>> Firefox 'contacts in the browser' Mozilla Labs codebase.
>
> pointer?
> Is that something I should try to integrate with Tabulator?

I got wedged as Contacts stopped working with any of my Firefox
installations. I'll try to dig out my works-in-progress.

I definitely encourage you to take a look at https://mozillalabs.com/contacts/
-> https://addons.mozilla.org/en-US/firefox/addon/243985/
(note the link in the mozillalabs.com page was to an outdated version,
last time I checked).

Their code repo is http://hg.mozilla.org/labs/people

Mailing list,
http://groups.google.com/group/mozilla-labs-online-identity

They have a pile of importers (I think using a separate oauth addon),
http://hg.mozilla.org/labs/people/file/f5bee994fb14/modules/importers

My own was pretty much just copied from the hCard one, and I didn't
get very far, so I suggest starting here -
http://hg.mozilla.org/labs/people/file/f5bee994fb14/modules/importers/hcard.js
as it should be up to date with their latest APIs. I only looked at
public data read from simple Web fetch, no auth or platform API stuff.
But since the tool does pull in date from behind many such APIs,
providing a foaf/rdf view over the aggregated contacts data (in SQL)
would be good too.

Hope this helps,

Dan
Dan Brickley | 20 Dec 2010 20:03

[foaf-dev] Fwd: A Proposal for Universal Identification of Genetic Sequence Features and Biological Parts By Sequence Hashes

Just when i was thinking we should hide foaf:dnaChecksum even more
from casual readers of the FOAF spec, ... ;)

(and yes, foaf:dnaChecksum is still a joke...)

Dan

---------- Forwarded message ----------
From: Timothy Ham <timothyham@...>
Date: Mon, Dec 20, 2010 at 7:54 PM
Subject: A Proposal for Universal Identification of Genetic Sequence
Features and Biological Parts By Sequence Hashes
To: Synthetic Biology Data Exchange Group <synbiodex@...>

Request for Comments [Draft v. 2010-12-20]
The original file of this draft can be found at
http://loche.lbl.gov/tim/static/TSH-RFC-2010-12-20.doc

Title:
A Proposal for Universal Identification of Genetic Sequence Features
and Biological Parts By Sequence Hashes

Authors:
Timothy Ham
Others?

Purpose:
This Proposal specifies a single method to generate a hash for an
arbitrary DNA sequence for identification purposes.

Abstract:
Sequences of arbitrary lengths can be universally and uniquely
identified using a hash generated by the SHA-256 algorithm. A short
identifier generated in a consistent way would facilitate global
identification of genetic sequences, sequence features, and biological
parts across different assembly standards and packaging formats.
Furthermore, the use of the hash as a token would facilitate discovery
of information related to a defined sequence on the Internet by
providing a unique keyword for search engines, supplementing sequence
similarity searches such as BLAST.

Body Text:
Currently, an arbitrary sequence of DNA is identified by its gene name
or protein sequence. For example, the Beta-lactamase gene (bla) can be
identified by its amino acid sequence. However, the amino acid
sequence alone does not give enough specificity to identify a
synthetic biological part. A gene with a different codon usage could
generate the same amino acid sequence, but perform differently under
experimental conditions. A truly distinct identification is achieved
only with an unambiguous DNA sequence.

Using the entire DNA sequence for identification and identity
verification is cumbersome. It is possible to use identifiers
generated by biological databases (NCBI, EMBL, Protein Databank etc.),
but as it is not possible to generate identifiers on the fly, their
use in experimental biology is limited.

In the field of computer science, algorithms have been devised to
convert arbitrary length of data into a fixed length “digital
fingerprint” or a “hash”. These family of algorithms called
“cryptographic hash functions” have the property that it is infeasible
to find two different input data that would generate an identical hash
result. The hash values generated by the algorithm is analogous to a
bar-code, except anyone can generate them and they are always the same
for the same input.

We propose that once an unambiguous DNA sequence for a biological part
is determined, its cryptographic hash value should be calculated and
associated with that sequence, along with any description, measurement
or experiment performed with that DNA sequence.

By adopting a standard method to calculate these hash values, it would
be possible to:
1.Create a globally unique and unambiguous identification token for
any arbitrary DNA sequence.
2.Unambiguously identify same parts encoded in different assembly
standards.
3.Unambiguously identify the same parts or DNA sequences created by
different people. This enables association different experiments
performed by different people to the same DNA sequence.
4.Facilitate search and indexing of biological parts by providing a
short yet unique identifier token to search engines.

We propose that the hash value is calculated as follows:
1.SHA-256 algorithm must be used. Adopted as a US Federal Information
Processing Standard, it is regarded as a robust, secure algorithm and
widely implemented and used.
2.Letters a, t, g, c in lower case must be used to to represent DNA
sequence. Ambiguous nucleotide alphabets must not be used.
3.Blank lines, spaces, or other symbols must not be included in the
sequence text.
4.The sequence text must be in ASCII or UTF-8 encoding. For the
alphabets used, the two are identical. UTF-16 encoding must not be
used, as its Byte Order Mark will change the calculated hash value.
5.For DNA sequences in assembly formats, two calculations must be
performed: One for the entire sequence including the assembly prefix
and suffix, and another for the desired or functional sequence
enclosed between the prefix and suffix (called inner hash). Generally,
this would mean sequences exclusive of the prefix and suffix.
6.If the desired or functional sequence overlaps parts of the prefix
or the suffix, then these sequences should be included in the second
hash calculation. For example, when two BglBrick formatted parts
encoding two protein domains are assembled together to create a single
protein, utilizing the reaction scar as a Glycine-Serine linker, then
the the protein domains that incur into the prefix and suffix regions
should be included in the inner hash calculation for the two original
parts.
7.The resulting hash value must be represented in hexadecimal
representation, also known as a hex digest. Only the numbers 0-9, and
leters a-f in lower case must be used.
8.It is not necessary to store both the forward and reverse values.
However, when performing searches, both directions must be calculated
and checked for completeness.
9.This proposal is only to identify specifically and uniquely a
particular DNA sequence. If different version of a sequences are used
in an experiment—for example sequences that lack start or stop codons,
point mutations, silent mutations, codon optimizations, etc.—they are
considered as different sequences with different hash values. A
separate mechanism must be used to deal with variations.

Frequently Asked Questions:
1.Why not blast?
The purpose of the hash values are to facilitate search algorithms,
not to replace them. Blast and other sequence comparison algorithms
are great at finding similar sequences, but that very feature makes
them cumbersome to use for identification. To abuse an old analogy:
blast is good for looking for needle like metallic objects in a hay
stack. The hash value is used to find the exact needle in a stack of
similar looking needles. Furthermore, in order to use blast, the
sequences must be deposited into a blast database. But not everyone is
inclined to host a blast enabled database or deposit all their parts
into one. Since hash values are easily calculated (via a web form, for
example. See http://loche.lbl.gov/tim/seqhash/), they can quickly
enable searches by Internet search engines.
2.What are some use cases?
a)In part assembly usage, instead of using arbitrary and synthetic
identifiers (a database ID for example), composite part can be defined
as a list of sequences hashes (or as a list of inner, scar, prefix and
suffix hashes). As the parts are repackaged in different assembly
formats or no assembly formats at all, instead of keeping track of
arbitrary part numbers, inner hashes will remain constant and
predictable.
b)When biological devices composed of multiple composite parts are
exchanged, it is not necessary to exchange all the sub parts. A sub
parts' positions would be annotated, and when further information is
desired, it can be searched for on the Internet using its hash value.
c)At JBEI, when a new annotated Genbank file is entered, all the
annotated features are identified, hashes calculated and stored. By
keeping track known features, we are able to know amount of part/
sequence/gene reuse, identification of mis-annotations, and facilitate
automatic feature annotation.
3.Would I be required to memorize a 64bit hexadecimal string all the
time?
No. Clearly hash values are primarily for machine use only. Users
should be presented with friendly part numbers or names whenever
possible.

Example:
One version of the Beta-lactamase gene has the DNA sequence:

>gi|58000284:100368-101228 Escherichia coli A2363 plasmid pAPEC-O2-R, complete sequence
ATGAGTATTCAACATTTCCGTGTCGCCCTTATTCCCTTTTTTGCGGCATTTTGCCTTCCTGTTTTTGCTC
ACCCAGAAACGCTGGTGAAAGTAAAAGATGCTGAAGATCAGTTGGGTGCACGAGTGGGTTACATCGAACT
GGATCTCAACAGCGGTAAGATCCTTGAGAGTTTTCGCCCCGAAGAACGTTTTCCAATGATGAGCACTTTT
AAAGTTCTGCTATGTGGCGCGGTATTATCCCGTGTTGACGCCGGGCAAGAGCAACTCGGTCGCCGCATAC
ACTATTCTCAGAATGACTTGGTTGAGTACTCACCAGTCACAGAAAAGCATCTTACGGATGGCATGACAGT
AAGAGAATTATGCAGTGCTGCCATAACCATGAGTGATAACACTGCGGCCAACTTACTTCTGACAACGATC
GGAGGACCGAAGGAGCTAACCGCTTTTTTGCACAACATGGGGGATCATGTAACTCGCCTTGATCGTTGGG
AACCGGAGCTGAATGAAGCCATACCAAACGACGAGCGTGACACCACGATGCCTGCAGCAATGGCAACAAC
GTTGCGCAAACTATTAACTGGCGAACTACTTACTCTAGCTTCCCGGCAACAATTAATAGACTGGATGGAG
GCGGATAAAGTTGCAGGACCACTTCTGCGCTCGGCCCTTCCGGCTGGCTGGTTTATTGCTGATAAATCTG
GAGCCGGTGAGCGTGGGTCTCGCGGTATCATTGCAGCACTGGGGCCAGATGGTAAGCCCTCCCGTATCGT
AGTTATCTACACGACGGGGAGTCAGGCAACTATGGATGAACGAAATAGACAGATCGCTGAGATAGGTGCC
TCACTGATTAAGCATTGGTAA
After normalization (removal of spaces and converted to lower case),
this sequence results in the hash value:
2c5bc10fd145290e60b0b03fb203c474b1add56c3ede4fe26bed5408175c7cf3
Dan Brickley | 20 Dec 2010 21:34

[foaf-dev] rough notes: badges, lists and groups in RDFa/OWL

http://svn.foaf-project.org/foaftown/2010/badges/badgetest1.html
explores the business discussed here recently, of modelling groups in
a very fluid way using OWL/RDFS classes, but also treating them as
named entities that can have properties (like image/icon urls).

Previous OWL discussion re foaf:Group
http://lists.foaf-project.org/pipermail/foaf-dev/2010-November/010488.html

What I've done in
http://svn.foaf-project.org/foaftown/2010/badges/badgetest1.html is
start some RDFa example showing how a page can declare or describe a
group (aka list, badge, etc.). It gives examples from two different
badge systems: wikipedia and foursquare, but rather than showing
multi-site, provenance/claims stuff, for now we just have a simple
monolithic demo where the page itself asserts group membership.

The instance markup isn't too bad really, assuming you can live with
RDFa plus some kind of namespacing mechanism:

<ul about="http://danbri.org/foaf.rdf#danbri" typeof="foaf:Person
badge:Langskill_hr_1 badge:Location_boxee_party" >
 <li>
  name: <span property="foaf:name">Dan Brickley</span>
 </li>
 <li>
  homepage: <a href="http://danbri.org/" rel="foaf:homepage
foaf:account">danbri.org</a>
 </li>
</ul>

And here's the paragraph that defines one of those groups,

<p about="#Langskill_hr_1" id="Langskill_hr_1" typeof="foaf:Group rdfs:Class">
<span property="rdfs:label">Group 1: basic croatian</span>
<span property="rdfs:comment">People with basic language skills in croatian
</span>
This is a sub-group of the <a rel="rdfs:subClassOf"
href="#Langskill_hr">langskill_hr basic croatian</a>
<span rel="rdfs:subClassOf" href="http://xmlns.com/foaf/0.1/Person"/>
</p>

So basic idea is to move from per-site local names, to
badges/groups/lists whose definitions are to some extent machine
readable. And where the environment moves us gently towards being able
to stand back from particular groups, and look at the bigger picture.
So instead of my random twitter list for 'xml stuff', deal with 'all
the lists on twitter that ascribe some level of XML expertise to their
members'.

I've sketched a few more design issues in the svn demo page but I'll
excerpt here for convenience,

"""
Formalising

What do all these systems have in common?

They declare groups (lets say of people; we could also treat non-human
agents, organizations, groups etc. in a similar way, but simply for
now).

The give a short natural language description characterising that
group. They may also have a short name, an image link. And in many
cases they may be part of a more complex system defining groups of
groups.

Consider a Boxee Fan with basic knowledge of Croatian.

In foursquare, this person would be in group 66 by virtue of having
checked in at a Boxee.tv promotional event. This means that the group
membership is asserted by the foursquare service, rather than the
user.

In Wikipedia, the language ability could be encoded as part of a
larger 'Babel' template.

The wikipedia markup {{Babel|en|hr-1}} gives rise to HTML markup showing:

en - This user is a native speaker of English.
hr-1 - Ovaj suradnik posjeduje osnovno znanje hrvatskog jezika.
So again, we have simple local-to-some-site codes for groups; just as
our user is in group '66' on foursquare, they're in groups (let's say)
"babel en" and "babel hr-1" on Wikipedia. Unlike foursquare, these
group membership claims are typically asserted by the user, but are
accessible for anyone in the wiki to edit.

Mailing list membership, or groups in identi.ca (statusnet) or Twitter
lists can also be looked at this way. Again, they select some but not
(usually) all people and put them in a named group; in some cases
(identi.ca) the groups are self-selecting; in others (twitter) they
are annotations applied by others. On twitter for example, each user
account can create named lists with short names like 'semweb' to apply
to other users.

Is there an underlying model?

groups, lists and badges require a claims-based perspective: some
party is asserting that some (typically other) party is a member of
some group
Each group typically is defined within a Web page, with label,
description, icon etc.
Different sites provide different mechanisms for asserting group
membership, and different APIs to the resulting data
The various specific groups used in an assertion often have rich
relationships to each other (eg. compare 'en-1' with 'en-5', or the
cluster of cat-related groups defined at Wikipedia)
To varying degrees, it may be possible to make template-ized claims
about members of some group in machine-friendly form.
if person x is in this group, they work (or have worked) for organization y
if person x is in this group, they speak read or write language y,
with ability z
if person x is in this group, they are interested in entity y
if person x is in this group, they are interested in topic y
"""

Nearby in the Web, https://wiki.mozilla.org/Drumbeat/Badges
http://joshuagay.org/blog/?p=32 from mozilla folks

cheers,

Dan

Gmane