Re: Graph naming?

hello Graham

On Feb 24, 2004, at 11:06 AM, Graham Klyne wrote:
>
> This reminds me of one of those simple ideas that's been kicking 
> around my head for a while, but I don't think I ever expressed...
>
> Notation3 (as I understand it) has a simple way of creating named 
> graphs within a document;  the idiom I use is:
>
>    uri :- { <formula> }
>
> It would be a small extension, I think, to do something similar with 
> RDF/XML:
>
>    <rdf:RDF rdf:ID="foo">
>      :
>     (RDF statements)
>      :
>    </rdf:RDF>
>
> or
>
>    <rdf:RDF rdf:about="uri">
>      :
>     (RDF statements)
>      :
>    </rdf:RDF>
>
> Thus, an RDF element might be treated as a syntax construct for a node 
> that happens to be a graph.
>
> Is this conceptually broken in any way I haven't noticed?

not breaking as far I can understand the RDF machinery - but I am sure 
people here will disagree - even though, things like that will be on 
the top of our wish-list for next version of the RDF/XML syntax :)

but the main problem I would see with such a syntactic sugar is that it 
would make croaking existing RDF/XML parsers and tools out there (e.g. 
"Syntax error when processing attribute rdf:about. Cannot have 
attribute rdf:about in this context..." even if some tools a more 
lenient still) - i.e. it would not be backward compatible - and it 
would not easily allow to merge different named-graphs (provenance 
info) into the same RDF chunk/piece unless the rdf:RDF element is being 
nested, repeated or tweaked somehow. But even so definitively useful to 
attach to plain triples expressed in current RDF/XML some naming, 
provenance information or whatever that other 4th component means to 
you - infinitively useful indeed.

Along these lines, we have have been experimenting (and implementing) a 
simple RDF/XML syntax compatible (compliant) extension which allows to 
"inline" graph names and treat (describe) them as normal resources. For 
example see my FOAF profile

http://foaf.asemantics.com/alberto

which uses extra/special rdfstore:context properties to flag each 
description block (not the whole rdf:RDF block though) with its 
provenance information described in the top of the file (or somewhere 
else) - such property is much more like an rdf:about, but for naming, 
and referring to a valid URI which represents the "space" 
(context/name/domain) of the triples being asserted - in the general 
case, such triples would be asserted as true as far as I am concerned. 
We have also got a bNode equivalent property called 
rdfstore:contextnodeID which is being used to distinguish between 
"real" URI qualified "names" and anonymous "spaces" i.e. resembling the 
rdf:nodeID but for naming.

Such properties can be used anywhere in the graph and being attached to 
descriptions accordingly - and like rdf:about, rdfstore:context is 
subject to xml:base sensitive processing and so on - more, unless we 
use special collection/constructs we have not been able yet to nicely 
"distribute" such contextual information to a whole serialized graph, 
like it would be possible with your rdf:about attached to rdf:RDF XML 
nodes. Attributes like rdf:about, rdf:ID, rdf:resource or rdf:nodeID 
can then refer "back" to those "spaces" accordingly using plain/normal 
RDF description i.e. all in one nicely together :)

Each RDF parser/processor aware of such a special properties/extensions 
could then generates "quads" or keep track of naming of triples 
accordingly - instead, any other standard compliant RDF/XML parser 
could simply "ignore" them and generate just some "spurious" triples, 
which would also be using special properties/namespace (i.e. I do not 
care of those vs. I need to understand everything)

Try yourself and see the different output generated for the above FOAF 
using W3C (ARP) standard validator [1] and our extended parser [2] 
which generates "quads" accordingly (no clue for me our "graphically" 
such naming would be represented though).

Now - what are we doing with such special properties? well in our 
experiments, we mainly keep track of triples, bookkeeping them, filter 
them, update/delete parts of the graph selectively and allow easier 
"smushing" of different RDF/XML pieces - and using RDQL queries like

select
	?item, ?description
where
	(?name <rdf:type> <rdfstore:Context>)
	(?name <dc:date> "2004-02-25")
          (?name <dc:source> <http://www.trustedrss10resource.com>)
	(?item <rss:description> ?description, ?name)
using
	.....

and then serialize back RDF-stored-triples into RDF/XML with full 
naming and provenance information described in it. And so on...

but yes - this is still just another hack :) but definitively RDF/XML 
"friendly" (as far as we have have experimented) and easy to use on ANY 
RDF/XML piece out there without too much work really. RSS feeds, to 
blog comments, to annotations and so on...

In fact, we are using such extensions for some of our 
pilots/demonstrators [3] - used also in combination with some URN 
extended resolution mechanism which returns metadata with full 
"provenance" information to the client - allowing really overlapping 
RDF to happen cheaply and easily. But perhaps this is already going too 
far from the subject of the original thread here....

all the best

Alberto

[1] http://www.w3.org/RDF/Validator/
[2] http://demo.asemantics.com/rdfstore/parser/
[3] http://demo.asemantics.com/biz/nb2/

Received on Tuesday, 24 February 2004 19:25:45 UTC