This is the second article in the “Get Your FOAF On” series which provides some short overview of how to use various FOAF features. In this edition we’ll look at the FOAF vocabulary elements for describing project as well as stating your involvement.
Let’s jump straight in with an example:
<foaf:Project>
<dc:title>My Pet Project</dc:title>
<dc:description>A project involving pets in some fashion. Probably cats</dc:description>
<foaf:homepage rdf:resource="http://www.example.com/projects/pet-project"/>
</foaf:Project>
This example mixes two vocabularies: FOAF and Dublin Core. The FOAF vocabulary furnishes us with a class for describing projects (foaf:Project
) and the foaf:homepage
property for identifying the homepage of some “thing”. We can use this property to amalgamate descriptions of projects taken from multiple sources, whilst still allowing us to talk about the homepage document separately from the project itself. The Dublin Core vocabulary gives us the ever useful description and title properties.
Now this is your pet project, so how do you say that you’re it’s creator? One way would be to use the dc:creator
property from Dublin Core. However there are some issues with using Dublin Core creator, so we’ll instead use foaf:maker
which is more clearly defined:
<foaf:Project>
<dc:title>My Pet Project</dc:title>
<dc:description>A project involving pets in some fashion. Probably cats</dc:description>
<foaf:homepage rdf:resource="http://www.example.com/projects/pet-project"/>
<foaf:maker>
<foaf:Person>
<foaf:name>Dr. Doolittle</foaf:name>
</foaf:Person>
</foaf:maker>
</foaf:Project>
Or alternatively:
<foaf:Person rdf:nodeID="me">
<foaf:name>Dr. Doolittle</foaf:name>
</foaf:Person>
<foaf:Project>
<dc:title>My Pet Project</dc:title>
<dc:description>A project involving pets in some fashion. Probably cats</dc:description>
<foaf:homepage rdf:resource="http://www.example.com/projects/pet-project"/>
<foaf:maker rdf:nodeID="me"/>
</foaf:Project>
So you’re a bit further down the line with your project and you’ve picked up some help along the way. How do you indicate that other people have contributed to the project? Simple just add additional foaf:maker
properties, not forgetting to reference the other persons FOAF file using rdfs:seeAlso
:
<foaf:Project>
<dc:title>My Pet Project</dc:title>
<dc:description>A project involving pets in some fashion. Probably cats</dc:description>
<foaf:homepage rdf:resource="http://www.example.com/projects/pet-project"/>
<foaf:maker rdf:nodeID="dr"/>
<foaf:maker>
<foaf:Person>
<foaf:name>Eliza Doolittle</foaf:name>
<rdfs:seeAlso rdf:resource="..."/>
</foaf:Person>
</foaf:maker>
</foaf:Project>
Instead of using additional foaf:maker
properties you could also use the dc:contributor
property, although this suffers from the same problems as dc:creator
. However it does allow one to distinguish between the orginal author of a project and the role of contributor.
All of the above examples have used foaf:maker
. The inverse of foaf:maker
is foaf:made
. You can use this to point to things you’ve made; the above examples showing a thing pointing to it’s maker.
FOAF also provides two other properties for linking you to your projects: foaf:currentProject
and foaf:pastProject
. The meanings of these should be pretty obvious. How they’re used is a little counter-intuitive though as the properties are commonly used to refer to a document describing a project, e.g. it’s homepage, rather than the project itself:
<foaf:Person>
<foaf:name>Dr Doolittle</foaf:name>
<foaf:currentProject rdf:resource="http://www.example.com/projects/pet-project"/>
<foaf:pastProject rdf:resource="http://www.example.com/projects/talking-to-animals"/>
</foaf:Person>
The FOAF specification notes the ambiguity here and suggests that some further work is required. However I think the above usage — pointing to a project home page — is relatively safe as there’s a general trend in FOAF to describe things indirectly, using smushing to aggregate descriptions. Also note that there’s no restriction on the number of time you can use these properties, so you can have as many current and past projects as you want. And if you’re anything like me you’re accumulating projects faster than you can shake them off!
To round off this mini-tutorial I want to point to some example data for people interested in building applications around project descriptions. Freshmeat provide a regular export of their project descriptions, and I recently announced a quick XSLT conversion that generates data from this export.
One thing that this highlights is that there are other interesting facets of software projects that could be usefully captured. Edd Dumbill has done a preliminary survey of what we might need from a DOAP (Description of a Project). Max Voekel has also published some notes on DOASP (Description of a Software Project).