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

[Julian Bond]

James Carlyle <james.carlyle at takepart.com> wrote:
>I think that for publishers should not be constrained by the serialisation
>format of their RDF in XML - if they are, then someone could start to argue
>that FOAF might just as well be a plain XML language.

FOAF might just as well be a plain XML language. Oh, you want
justification too? Sorry the margin's not big enough. ;-)

James Carlyle <james.carlyle at takepart.com> wrote:
>Or
>canonicalisation in the context of FOAF might mean shaping FOAF specific
>statements (i.e. knows, Person etc, with a defined and consistent nesting
>structure) and removing other non-FOAF statements.

I think RSS 2.0 can teach us something here. It should be possible to
use namespaces to allow extendability and to allow intermixed RDF while
still maintaining a consistent structure of FOAF elements that are
parsable by plain XML parsers.

To take one example I've seen recently.
<foaf:Person rdf:ID="1">
  <foo:acquaitanceOf>
    <foaf:Person rdf:ID="2">

This could just as easily have been coded
<foaf:Person rdf:ID="1">
  <foaf:knows>
    <foaf:Person rdf:ID="2">
    <foo:relationship>Acquaintance</foo:relationship>
or
<foaf:Person rdf:ID="1">
  <foaf:knows foo:relationship="Acquaintance">
    <foaf:Person rdf:ID="2">

The second two extend FOAF but are still easily parsable by a FOAF
specific XML parser. It may miss the new information but it will still
pick up the 1->2 relationship. The first is going to hide person 2
behind an unknown tag.

The only downside I can see to having an agreed hierarchy is that if a
particular person wants to use foaf elements in an RDF file in a way
that doesn't follow the hierarchy then they can. But they do it in the
knowledge that foaf specific parsers might barf on the file and
misunderstand what they were conveying.

Which is all a log winded way of saying, if FOAF can be evolved so that
the majority of FOAF data out there can be parsed by plain-XML non-RDF
parsers as well as RDF parsers then it will be more of a success. It'll
be easier to get widespread implementation. The end result will still be
RDF. This seems so obvious to me that I think it's up to the purists to
argue and explain the downside. If the downside is too big I'll have to
think again.

-- 
Julian Bond Email&MSM: julian.bond at voidstar.com
Webmaster:              http://www.ecademy.com/
Personal WebLog:       http://www.voidstar.com/
M: +44 (0)77 5907 2173   T: +44 (0)192 0412 433