W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > February 2009

Re: Named Graphs in RDFa

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Tue, 17 Feb 2009 10:24:20 +0000
Message-ID: <ed77aa9f0902170224o14c1c887v305d14eddd5b387a@mail.gmail.com>
To: Toby A Inkster <tai@g5n.co.uk>
Cc: RDFa <public-rdf-in-xhtml-tf@w3.org>
Hi Toby,

On Mon, Feb 16, 2009 at 10:44 PM, Toby A Inkster <tai@g5n.co.uk> wrote:
> Mark Birbeck wrote:
>
>> I'm working on using local storage to capture triples that are
>> retrieved from documents, whilst browsing the web, and the approach is
>> to store the triples in a named graph that uses the document's URI as
>> the name. This means that the next time I navigate to that URL, all I
>> have to do is to delete the named graph, then parse the document, and
>> insert the triples again; I don't have to worry that there may be
>> other triples floating around that are now 'incorrect'.
>
> A solution to this would be to allow an RDFa document to contain multiple
> named graphs, but to force the URIs for those named graphs to have URIs of
> the form <document URI> + "#" + <name>. This could easily be achieved by
> making the lexical space of the graph attribute the same as label@for.

I agree, and have at various times playing around with exactly the
same idea. I've looked at it much like the way bnodes are minted, in
that they are 'local'. You could argue that these are 'local' named
graphs, and that they live and die along with the 'master' graph.

The problem though, is that a query of the 'master' should query all
graphs in the collection, and the same would have to go for any other
graph that 'contains' a graph. (We could of course duplicate triples
across multiple graphs, but it would be interesting to see if there is
a neater solution.)

Interestingly, Jeni Tennison has also been looking at similar issues,
and she has some great use-cases:

  <http://www.jenitennison.com/blog/node/101>

As with the document you wrote with Kjetil:

  <http://buzzword.org.uk/2009/rdfa4/spec>

she considers both a @graph approach, and an @id approach, but for
reasons I've given, I think that @graph causes too many problems with
provenance.

However, I do agree that @id may hold a solution.

It's certainly the front-runner. :)

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
Received on Tuesday, 17 February 2009 10:24:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 February 2009 10:24:57 GMT