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

[Graham Klyne]

At 14:16 24/07/03 -0400, Dan Brickley wrote:
>That's the crux of it really. A big chunk of technology that supports
>FOAF, including the harvesters, databases / aggregators etc. is utterly
>generic, and has nothing to do with the FOAF vocab at all. That's also
>why the tech site for FOAF is called RDFWeb... This was carefully built
>on generic lines so we can re-apply to related problem domains without
>having to re-engineer the aggregator side of things. Being a FOAF
>scutter (indexing tool eg. see Matt Biddulph's writeup at
>http://www.hackdiary.com/archives/000021.html) is something that has
>nothing to do with FOAF vocabulary specifics. And it's all based on
>algorithms for merging completely arbitrary collections of RDF data,
>in a way that simple can't be done for XML.
>
>When someone comes up with such an algorithm for XML documents, we can
>re-open the issue.

[Arcane technical diversion, but I actually agree]

Actually, I believe something like this could be done.  Some time ago, 
Peter Patel-Schneider came up with a proposal for a radical (semantic) 
reinterpretation of RDF [1], which overlays an RDF-like semantics on XML 
using the XML query model for the underlying abstract syntax.  The result, 
as I understood it, is effectively an unlabelled directed graph, which, 
when subjected to certain restrictions, can be mapped into an RDF labelled 
directed graph.  I think that data merging then becomes a merging of pairs 
rather than triples.  But I suspect that the results of back-substituting 
into XML might be surprising in some cases.

#g
--

[1] http//lists.w3.org/Archives/Public/www-rdf-interest/2001Oct/0054.html




-------------------
Graham Klyne
<GK at NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E