Re: New Proposal (6.1) for GRAPHS

On Apr 2, 2012, at 17:04 , Sandro Hawke wrote:

> On Wed, 2012-03-28 at 16:35 +0200, Ivan Herman wrote:
[skip]
>> 
>> Hm. We get to the same issue as with the properties. Within the RDF world, we only have blank nodes, URIrefs, and literals. If you want to talk about rdf:Graph as a class in the RDF sense the way you describe, then either (a) a graph should be defined in terms of a blank node, URIRef or a literal or (b) we have to extend the notion of 'things' that can be in RDF.
> 
> I don't really understand.
> 
> Allow me to fall back on computer programming terminology, please, since
> that's where I'm most comfortable.
> 
> If I implement an RDF parser, triplestore, an serializer, with 2004 RDF,
> in an object oriented programming style, then yes, I probably am going
> to have classes for BlankNode, LabeledNode (aka URIRef), and Literal.
> 
> I think you're saying you're concerned that with proposal 6.1 folks will
> have to also implement some kind of Graph class in their code.
> 
> But don't they need something like that if they're going to handle
> multiple graphs, eg with TriG or SPARQL with named graphs?  Right now,
> doesn't that code have some kind of Graph class now?  Well, it probably
> either has a Graph -- a set of triples -- or it uses quads with the
> fourth column being a graph id -- identifying some kind of Graph object.
> 
> Am I in the right space here?    Can you explain your concern like this,
> in terms of code changes people might have to make?

Yes, you are the right space. What you say is that graphs are different then what constitute an RDF triple today.

What this means is that, if we go the road you refer to, we will have to extend the RDF concepts, the RDF Semantics, and of course all the various other documents, to have a new type of RDF, where the constituents of a triple may be BlankNode, LabeledNode, Literal, and Graph. I guess this can be done, but it requires a significant amount of work, it has consequences in a number of different specs, like OWL, RIF, SPARQL, etc.

As for implementations: today, an implementation probably has the notion of a triple, which may have s,p,o, which can be of class... well, you know that. Those classes, including all the code that rely on those classes, will have to be extended to allow for a 4th type of thing, otherwise they may throw exceptions, go wrong, blow up, etc. I am not sure I can foresee all the consequences.

(I know a bit RDFLib from inside. It does have the notion of a Graph, of course, which can even have an associated label. But all the code that, say, retrieves triples from a graph store rely on the fact that any resource has to be Literal, URIRef, or BNode, to use the RDFLib terminology. Those methods are not necessarily prepared for the possibility of having a Graph at places.)

And... what does it buy us? There is nothing that forces us to go down that route. The type of a Graph 'label' can be defined outside of the formal RDF Semantics and concepts, and things work just as well (I know Pat will shoot me down, though:-)

Ivan

> 
>    -- Sandro
> 
>> Personally, I would keep away from that: I am not sure we can do it in time, I am not sure it is consensus ready for a standard. The labels in a (l,G) pair are URI refs (or BNodes), ie, they can be typed to any RDF graphs; but I think the exact semantics of what that means should be defined _outside_ of the formal RDF semantics (essentially in English prose).
>> 
>> Maybe RDF 2.0 can provide a mathematically precise semantics. Maybe we can publish a note for the direction such a recommendation might take. But I am not sure we can go beyond that.
>> 
>> (Yes, I may be in my pessimistic mood.)
>> 
>> Ivan
>> 
>> 
>> 
>>> 
>>>  -- Sandro
>>>> 
>>>> peter
>>>> 
>>>> 
>>>> On 03/27/2012 10:23 PM, Sandro Hawke wrote:
>>>>> I've written up design 6 (originally suggested by Andy) in more
>>>>> detail.  I've called in 6.1 since I've change/added a few details that
>>>>> Andy might not agree with.  Eric has started writing up how the use
>>>>> cases are addressed by this proposal.
>>>>> 
>>>>> This proposal addresses all 15 of our old open issues concerning graphs.
>>>>> (I'm sure it will have its own issues, though.)
>>>>> 
>>>>> The basic idea is to use trig syntax, and to support the different
>>>>> desired relationships between labels and their graphs via class
>>>>> information on the labels.  In particular, according to this proposal,
>>>>> in this trig document:
>>>>> 
>>>>>   <u1>  {<a>  <b>  <c>  }
>>>>> 
>>>>> ... we only know that<u1>  is some kind of label for the RDF Graph<a>
>>>>> <b>  <c>, like today.  However, in his trig document:
>>>>> 
>>>>>   {<u2>  a rdf:Graph }
>>>>>   <u2>  {<a>  <b>  <c>  }
>>>>> 
>>>>> we know that<u2>  is an rdf:Graph and, what's more, we know that<u2>
>>>>> actually is the RDF Graph {<a>  <b>  <c>  }.  That is, in this case, we
>>>>> know that URL "u2" is a name we can use in RDF to refer to that g-snap.
>>>>> 
>>>>> Details are here: http://www.w3.org/2011/rdf-wg/wiki/Graphs_Design_6.1
>>>>> 
>>>>> That page includes answers to all the current GRAPHS issues, including
>>>>> ISSUE-5, ISSUE-14, etc.
>>>>> 
>>>>> Eric has started going through Why Graphs and adding the examples as
>>>>> addressed by Proposal 6.1:
>>>>> http://www.w3.org/2011/rdf-wg/wiki/Why_Graphs_6.1
>>>>> 
>>>>>     -- Sandro (with Eric nearby)
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> ----
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>> 
>> 
>> 
>> 
>> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf