I've been talking with Mike Linksvayer of Creative Commons and Robert Kaye of MusicBrainz about the idea of a foaf:tipjar property that relates an 'agent' to a 'document' which serves as some form of 'tip jar' page, so that artists, content creators etc could use RDF to make statements that help them get rewarded for works they make available online. This initially wouldn't be very machine-readable, just a normal human-oriented Web page perhaps pointing to PayPal or Amazon wishlist pages. We can start simple and get fancy later.
The details need further discussion, but I like this idea a lot. It brings together concerns from the FOAF, CreativeCommons and MusicBrainz communities, and -- from a technical perspective -- allows us to explore the use of RDF to combine information expressed using the FOAF, Creative Commons and MusicBrainz datasets. One way to implement this would be to have a common notion of 'agent' shared across the three datasets/vocabularies. Leigh Dodds has been working on the RDF schema for MusicBrainz; we could define MM:Artist as a sub-class of foaf:Agent, so that FOAF tools would have some partial understanding of the MusicBrainz dataset. Mike also mentioned some discussions within CC of having an RDF representation of the notion of an agent.
How might this work in practice? One idea was for tools which generate CreativeCommons markup describing online content to have an option to include a declaration of the creating agent's FOAF description, including a link to a foaf:tipjar page. From a MusicBrainz perspective we could try to associate tipjar information with as many artists as possible, ideally alongside their homepage URLs and other handy metadata (photos, weblogs, ...). This would hopefully assist users of content in finding their way to a page that explains how to reward the content-creator (with online payments, Amazon gifts, etc.).
Feedback welcomed...
(update: Mar 18 2004 - foaf:tipjar has been added to the spec.)
The FOAF specification now includes a new (and long anticipated) property, foaf:gender. Like all FOAF properties, 'gender' is optional - nobody is required to describe themselves in any more detail than they choose to, and the new text in the spec goes to some lengths to stress this, amongst other concerns. I announced it to the FOAF mailing list (rdfweb-dev) earlier today following editorial discussions in #foaf, our IRC channel.
Typical values for foaf:gender are 'female' and 'male', which can be added to most FOAF files simply by including an element such as <foaf:gender>male</foaf:gender> inside any foaf:Person element(s) in the document. See the foaf:gender definition for details and accompanying documentation. Feedback on the design and documentation is welcome, either through weblog comments or by email.
The addition of a 'gender' property to FOAF is obvious, but also not something to do lightly. I have tried in the documentation to highlight a few issues that users and developers should be aware of. FOAF is often compared to centralised databases such as Six Degrees (the old pre-crash version; the domain name seems to have been recycled) or Friendster. However, the FOAF "data set" (ie. the collection of all Web documents and services which use FOAF vocabulary) is highly distributed, ie. not under central control. FOAF is being put to uses that are literally out of control; there is no "FOAF sysadmin" who can delete, edit or update all FOAF profiles. The data is scattered throughout the Web, under the control of the people who publish it.
Consequently we need to proceed with a certain amount of caution when increasing the expressiveness of FOAF. Adding gender information to FOAF means that whenever someone is looking for a way to describe a person's gender in an RDF/XML document, there is a simple piece of FOAF markup that will do the job. We can't control what other information this will be mixed with, whether the information is accurate, or the uses to which it will be put. An obvious application people have been discussing is 'dating', and doubtless we'll see additional vocabularies to accompany FOAF which will go into more detail on that topic than FOAF itself will ever attempt. Other application areas include the (again long-awaited) treatment of 'family tree' data within FOAF, where foaf:gender could be used to help define other concepts, like 'brother', 'aunt', etc.
It's also worth noting that this addition to FOAF has been defined in general terms so that it is very widely applicable. We can talk about the foaf:gender of things that aren't human, eg. other animals. This is a good example of unexpected re-use, something often seen with RDF-based data formats such as FOAF. By adding the foaf:gender property, and combining FOAF with other vocabulary such as Wordnet, we could for example use FOAF and RDF to catalogue digital photos and say things like "this is a photo of a female Anteater". A random example, but one that illustrates the variety of unexpected uses that a single addition to an RDF vocabulary can facilitate. It will be interesting to see how foaf:gender gets used...
So after discussions sprawling across IRC, email and various weblogs, we are going ahead with adding a property called foaf:myersBriggs to the FOAF vocabulary. This property takes as its values the 16 codes (INTP, ENFP etc.) used in the Myers Briggs Type Indicator (MBTI) personality description scheme.
Example FOAF snippet:
<foaf:Person>
<foaf:name>Dan Brickley</foaf:name>
<foaf:mbox rdf:resource="mailto:danbri@rdfweb.org"/ >
<foaf:myersBriggs>INTP</foaf:myersBriggs>
</foaf:Person>
Adding such markup will make it possible to browse, search and filter FOAF-related data using the MBTI classifications. For example, you might use it to search for weblogs created by people with some specified Myers Briggs entry (perhaps to check out to see if they fit the expected stereotype...? ;-).
There are a bunch of MBTI-related web sites out there; the Open Directory listing gives some reasonable starting points. The HumanMetrics site has an online version, which is probably what you're after if you just want a four letter code to paste into your FOAF description. For those taking this more seriously, the Personality Page has commentary and characterisation of the various distinctions emphasised in the MBTI.
For what it's worth I don't take MBTI too seriously as a piece of science, but it's interesting to see how people fit (or don't fit) into their scheme, and (like all of FOAF) it is entirely optional. Only publish a foaf:myersBriggs classification if you're happy making such information public. Same goes for your foaf:geekCode or foaf:schoolHomepage.
More detailed exploration of RDF/XML vocabulary for this sort of thing will probably happen in other vocabularies than FOAF, for example in Bill Kearney's draft MBTI namespace. There are of course dozens of other similar schemes and online questionnaires that we could hook up to FOAF, but this should make for an interesting toe in the water.
Unless anyone finds some huge flaw or better idea in the next week, we'll add this to the FOAF vocabulary documentation later this month.