Re: Graph labels vs. graph names. (was: Re: complete graphs)

On 5 Oct 2011, at 17:57, Sandro Hawke wrote:
>>> If my code talks to a new sparql server, and doesn't know which of
>> these
>>> conventions is being used, how can it do its job?  
>> 
>> It might ask the store for graphs that fulfil certain criteria.
>> 
>> Or there might be a SPARQL Service Description document that explains
>> what's in the graphs.
> 
> Those would probably work in the SPARQL world, but I'm thinking of
> SPARQL as just an interactive pseudo-TriG document.

Put the metadata in the default graph?

> Yes, the document could have a nearby document which tells you how to
> interpret it.   But that sounds pretty awkward to me.

Hence the default graph.

> Do we have a licensing use case?    
> 
> TimBL's foaf file contains:
> 
> <> cc:license <http://creativecommons.org/licenses/by-nc/3.0/>
> 
> It'd be nice to have that kind of thing survive in some usable way
> through being fetched and passed on.    Here, it's important that the
> subject and the fourth-column are the same.

Not really. The fourth column can be anything as long as there's some metadata holding everything together:

   <urn:uuid:12345> { <timbl/foaf.ttl> cc:license <…> }
   { <urn:uuid:12345> ex:source <timbl/foaf.ttl>. }

(A thought experiment to counter the argument that different conventions destroy interoperability: Imagine if we had only blank nodes as graph “names”. (Ignore questions of blank node scope etc.) I think it's clear that we could still do everything we could do before, it just requires better metadata attached to the blank nodes, and more indirection triples. And no, we should *not* use blank nodes as graph “names”. I hope Pat doesn't read this.)

Best,
Richard

Received on Wednesday, 5 October 2011 18:22:11 UTC