XSLTs for FOAF, Spring v1.3.1 and plans for FOAF spec improvements
danbri at w3.org
Tue Jun 24 13:27:33 UTC 2003
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:
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
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
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
(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,
...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...?
More information about the foaf-dev