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

[Dan Brickley]

So I've just written a brief article for the FOAF site about the new 
version of Spring, which offers some drag'n'drop support for loading FOAF data.
I'm also starting to clean up the FOAF spec (ie. http://xmlns.com/foaf/0.1/) and
it would be good to be responsive to their (and everyone else's!) experiences
with deploying FOAF in a non-experimental software package.

Spring FOAF writeup is at:
http://rdfweb.org/mt/foaflog/archives/000031.html

They use XSLT to transform FOAF into data that Spring natively understands. It 
appears to have been a source of some frustration for them that FOAF data is 
quite varied. There are a number of sources for this variation: (i) people choose
to write different things in their FOAF docs (level of detail, selection of 
vocab); (ii) vocabulary confusion, eg. around naming (surname etc); (iii) RDF's
syntactic flexibility, which allows different ways of XML encoding basically
the same thing.

So, (i) is inevitable. Nothing is mandatory in FOAF, although it is probably 
polite/sensible to minimally mention your foaf:name, and typically mailboxes
(hashed?) and homepage and maybe an image. So that sort of variety we can't do 
much about. Just as nobody says what you can write in your homepage, nobody 
gets to dictate what you write in your machine-readable homepage, ie. your 
FOAF file.

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.

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.

Focussing on (iii), what can be done:


- Compare different XSLT approaches to consuming FOAF (and other RDF) data
  http://xml.mfd-consult.dk/foaf/explorer/ is currently XSLT-based, and quite 
  widely used. 
  Morten, could you comment on any robustness issues, tips, 
  problems etc you have encountered?
 
  Several of the Japanese sites I linked yesterday are using XSLT, see article
  at http://rdfweb.org/mt/foaflog/archives/000028.html and Wiki entries at 
  http://antipop.zapto.org/wiki/?The%20%27friend%20of%20a%20friend%27%20project%20-%20FOAF
	http://www.kanzaki.com/info/foaf.xsl
	http://diary.noasobi.net/foaf.xsl
	http://www.megaegg.ne.jp/~tirukuru/aboutme/foafstyle.xsl
	http://www.ne.jp/asahi/books/inugami/foaf.xsl
	http://candana.org/nonsense/foaf.xsl
	http://www.remus.dti.ne.jp/~a-satomi/common/xsl/foaf_predation.xsl
	http://www.remus.dti.ne.jp/~a-satomi/common/xsl/foaf2html.xsl   
	(I've not looked at detail of these, but then I can't read XSLT...)
	
  Do these various approaches work for 100% of RDF/XML FOAF docs out there?
  Maybe 80% Quite likely 100% of those files built by foaf-a-matic?

  Are there lessons we can learn, eg. have the FOAF spec call out 
  a 'syntactic profile' of FOAF-in-RDF, so that we don't have needless and 
  confusing variation in the way FOAF is written in XML?

  If we did that, we have a careful balance to strike: we can't dictate a 
  single XML encoding without making it hard for people using RDF tools, 
  since RDF software (Jena, Redland, RDFLib etc) often automates the task 
  of writing out RDF as XML, and such libraries wouldn't be written to 
  know about the conventions we chose.

 - How about generic RDF-in-XSLT parsers? ie. tools that take any RDF-in-XML
  and output an XML representations of the triples that the document encodes.
  
  eg. http://www.w3.org/2001/12/rubyrdf/xsltrdf/ uses a 'two pass' approach.
  maybe that style would also help with normalising FOAF to a more manageable 
  set of XML structures?

  Also James Carlyle's RDF to NTriples XSLT parser, 
  http://www.semanticplanet.com/library/RdfToTriplesStylesheet
  http://lists.w3.org/Archives/Public/www-rdf-interest/2003Apr/0010.html

  ...these might help. But the Spring folks would still need to consume the 
  RDF triples somehow. What lightweight tools are there for doing that?

Other thoughts anyone? How can we make this easier for people...?

Dan