[rdfweb-dev] XSLTs for FOAF, Spring v1.3.1 and plans for FOAF spec improvements

Leigh Dodds ldodds at ingenta.com
Tue Jun 24 14:52:42 UTC 2003

Hi Dan,

> So, (i) is inevitable. 

Makes sense

> Re (ii), vocabulary stability and confusion, I have a plan(!). Rather than 
> worry whether FOAF itself is 'stable' or not, I intend to tag each vocabulary 
> item with 'stable','unstable','testing'. For eg., 'foaf:homepage' is stable;
> 'foaf:surname' is unstable; much of the rest is 'testing'. More on this in due
> course. I hope this should clear up some concerns folk have w.r.t. deployability
> of different bits of FOAF vocab.

I think thats a good idea: if we can't version the schema without stifling 
experimentation then going down a level and marking the stability of the 
individual properties allows much more freedom.

Presumably you were planning to annotate the FOAF schema with these 
additional properties, allowing us to auto-generate docs describing the 
stable/unstable/testing profiles?

> Re (iii), variation in the sense of their being different XML ways of writing
> down the same RDF claims (triples) about the world. This is something which 
> RDF-based implementors barely encounter as a problem, but which can be 
> frustrating for those using XSLT and XML-level tools. I would like to do something
> to improve this situation.

Agreed. Being able to hack on this data with multiple tools seems good to me.

How about two profiles:

+ "App FOAF" is for passing between RDF applications, allows the full range of 
   RDF syntax, etc.

+ "User FOAF" is more person friendly, is XSLT consumable, hand-craftable, etc.
   Skimming through the XSLT files you linked to looks like they're pretty reliant 
   on the kind of FOAF document generated by the FOAF-a-Matic (oops! :). Mark 
   2 uses Jena for exporting the data and the output is slightly different (Jena seems 
   to prefer properties as attributes rather than sub-elements, in some cases; but 
   this can be cleanly handled with appropriate XSLT templates).

The additional requirements would be stylesheets or apps to normalise "App FOAF" 
to "User FOAF".

This may fit with different kinds of uses of FOAF documents: the majority I've 
seen so far are individual people describing themselves, their relationships and 
their work. But, IIRC the ecademy FOAF exports included multiple people. These 
bulk files seem more intended for consumption by crawlers (FOAFBot) rather than end 
user tools (FOAF Explorer; FOAF-a-Matic, etc).

Teaching people to generate FOAF docs, e.g. your Wiki based walk-through 
might be easier with a well-specified profile.

Mind you, all this will be self-reinforcing: its likely that "User FOAF" may 
become more prevalent because its easier to work with (less tools/experience required). 
If the aim is for FOAF to showcase RDF tools and technologies then this might 
be self-defeating.



More information about the foaf-dev mailing list