Re: New Proposal (6.1) for GRAPHS

On Mar 30, 2012, at 7:01 AM, Eric Prud'hommeaux wrote:

> * Pat Hayes <phayes@ihmc.us> [2012-03-29 22:35-0500]
>> OK, I got it. But I don't like it. With this picture, we *never* name a graph. We only name a particular "expression" of the graph, and every time we write out the graph, we get a different expression.
> 
> Isn't that a reality?

Not in my world. Its hard to see how things can be more identical than { <a> <b> <c> } and  { <a> <b> <c> } .

> <u1> says "{ <a> <b> <c> }" and <u2> says "{ <a> <b> <c> }" and we want to attach different observations to them (e.g. that one is an rdf:Graph).

Well, no, I don't want to do that. YOU want to do that :-) But that seems like a mistake to me. They are (obviously?) the same thing, so if 'one of them' is something, so is the other. The fact is, this idea of using membership in a class to indicate identity of labeling simply does not work. Trying to rescue it by breaking the basic notions of RDF graph seems like a bad way to go. 

> Two approaches come to mind:
> 
>  1: speak in utterances of graphs:
>     There is *a* graph G1: { <a> <b> <c> }, and we talk about it indirectly:
>       <G1> { <a> <b> <c> }  # Never make direct assertions about <G1>.
>       { <u1> :utters <G1> . # <u1> has an utterance of { <a> <b> <c> } (using the *has* distinction below)
>         <u2> :utters <G1> . # <u2> has an utterance of { <a> <b> <c> }
>         <u2> a rdf:Graph }  # { <a> <b> <c> } is asserted
>      This isn't really our reflex when using named graphs and I'd expect lots of abuses.

I wouldnt expect people to even use it at all. 

> 
>  2: named graphs *are* utterances
>       <u1> { <a> <b> <c> } # <u1> has an utterance of { <a> <b> <c> }
>       <u2> { <a> <b> <c> } # <u2> has an utterance of { <a> <b> <c> }
>       { <u2> a rdf:Graph } # { <a> <b> <c> } is asserted
> 
>> I am left wondering what the point is of even having this? SPARQL datasets don't even have graphs in them any more. 
> 
> There may be other ways of achieving this goal, but SPARQL datasets being a mapping from name to utterance seems workable to me.

It might work for SPARQL but it will break RDFS and OWL and anyone who uses owl:sameAs or tries to do anything remotely intuitive involving identity of graphs. The point is, its a hack to rescue a broken idea, and it screws up the basic semantic intuitions. So its not a good design, even if we can somehow kind of make it work with enough pretzeling.

> Nothing changes mechanically; we just change our excruciatingly precise explanation of the operators, e.g. { <u1> :equals <u2> } is really { <u1> :isExpressionOfSameTheGraphAs <u2> }.

But that has all kinds of knock-on effects. It means that a class with two copies of the same graph in it has two things rather than one thing in it, for example. 

> 
> I admit the SPARQL query equivalent utterances is considerably more intuitive for the former:
>       ASK { <u1> :utters ?g .
>             <u2> :utters ?g
>           } # ask if <u1> and <u2> utter the same platonic graph.
>    vs.
>      !ASK { { GRAPH <u1> { ?s ?p ?o }
>               MINUS { GRAPH <u2> { ?s ?p ?o } } }
>             UNION
>             { GRAPH <u2> { ?s ?p ?o }
>               MINUS { GRAPH <u1> { ?s ?p ?o } } }
>           } # ask if there are any assertions in one which aren't in the other
> 
> The latter is fugly but the former doesn't align with how folks use named graphs today.

Neither of them make intuitive sense to me. 

Pat

> 
> 
>> Pat
>> 
>> On Mar 29, 2012, at 9:01 PM, Eric Prud'hommeaux wrote:
>> 
>>> * Pat Hayes <phayes@ihmc.us> [2012-03-29 17:34-0500]
>>>> 
>>>> On Mar 29, 2012, at 3:11 PM, Eric Prud'hommeaux wrote:
>>>> 
>>>>> * Pat Hayes <phayes@ihmc.us> [2012-03-29 10:47-0500]
>>>>>> Sandro
>>>>>> 
>>>>>> First, congratulations on expalining the idea so elegantly (I will try to take a style lesson from you). But I don't think your neat idea for defining the class rdf:Graph actually can be made to work in the way you want. See below.
>>>>>> 
>>>>>> 
>>>>>> On Mar 27, 2012, at 9: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
>>>>>> 
>>>>>> From there:
>>>>>> 
>>>>>> We define the class rdf:Graph such that for its instances, the rdf:hasGraph relation is the identity relation. That is, a Graph hasGraph itself.
>>>>>> 
>>>>>> [edit]Test
>>>>>> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#
>>>>>>> 
>>>>>> { <u1> rdfs:comments "A good graph", a rdf:Graph. }
>>>>>> <u1> { <a> <b> <c> }   # u1 *is* this graph
>>>>>> <u2> { <a> <b> <c> }   # u2 merely *has* this graph
>>>>>> 
>>>>>> DOES NOT ENTAIL
>>>>>> 
>>>>>> { <u2> rdfs:comments "A good graph" }
>>>>>> 
>>>>>> ......
>>>>>> 
>>>>>> But it does entail that. The relation is on the entailed objects, not on the IRIs, right? So that first quad says that what <u1> denotes, let me write I(<u1>) for that, and the graph { <a> <b> <c> }, are actually the very same thing: I(<u1>) =  { <a> <b> <c> }. And this is so because  I(<u1>) is in the class rdf:Graph. Which is the same as saying that {<a> <b> <c>} is in that class (because these are the very same thing.) So now look at the second quad. That says that the rdf:hasGraph relation holds between I(<u2>} and {<a> <b> <c>}, and we know that the second of these is in the class rdf:Graph. So, the rdf:Graph relation on it is the identity relation, so I(<i2>) = {<a> <b> <c>} as well. 
>>>>>> 
>>>>>> This follows because you have made the criterion be membership of the denoted thing in a class. As soon as you do that, you lose any way to distinguish between binary cases based on one of the argument IRIs. 
>>>>> 
>>>>> What if { <a> <b> <c> } isn't the same thing as { <a> <b> <c> }?
>>>> 
>>>> Not sure I follow. An RDF graph is a set of triples. That is the same set of triples. OK, I guess we can call them graph-primes and say they are distinct. But now, when are graph-primes *ever* the same? 
>>> 
>>> Sorry, I should have edited (or at least read) my text. I intend them to be graph-primes, so they are never the same. When we want to assert equivalence, e.g. to say that the graph had by <u1> has the same triples as the graph had by <u2>, we need a predicate which includes that dereference.
>>> { <u1> :isExpressionOfSameTheGraphAs <u2> }
>>> 
>>> 
>>> 
>>>>> Apart from mathematical reflexes, do we have a reason to want to graphs to be the same? Taking the above Trig, in another order for the purposes of illustration:
>>>>> 
>>>>> <u1> { <a> <b> <c> }   # u1 *is* this graph
>>>>> gives me: <u1> :hasGraph Parse1{<a><b><c>} . where Parse1{<a><b><c>} is an instance of { <a> <b> <c> }
>>>> 
>>>> Again I don't follow. What is an instance of a set?
>>> 
>>> Hmm, s/instance/expression/.
>>> 
>>> Parse1 was also a poor choice; it's just some expression of a graph. In Trig, we associate labels with the representations of graphs. In the default graph, we make some assertions about those representations, in the form a a type arc on the label (sure, why not). One of those assertions is that the author of the Trig document intends those statements in the graph which has a representation which has the label <u1> to carry the same strength of assertion as the triples in the default graph.
>>> 
>>> 
>>>>> <u2> { <a> <b> <c> }   # u2 merely *has* this graph
>>>>> gives me: <u1> :hasGraph Parse2{<a><b><c>} . where Parse2{<a><b><c>} is an instance of { <a> <b> <c> }
>>>>> 
>>>>> { <u1> rdfs:comments "A good graph", a rdf:Graph. }
>>>>> gives me Parse1{<a><b><c>} a :Graph . which magically ('cause something will have to be magical) asserts everything in { <a> <b> <c> }.
>>>> 
>>>> Why would that parse of it be parse1 rather than parse369 ? The graph is mentioned three time in the Trig in total, so if the second two are magically different, how come the first one is the same as the third? 
>>> 
>>> Ahh, I should not have used a small number. It's not any particular identifier, it's yet another representation of { <a> <b> <c> }.
>>> 
>>> 
>>>>> + We never risk assigning properties to the platonic graphs, only our utterances of them.
>>>>> - Every assertion we want to make about the triples in a platonic graph will need to dereference, which will look clumsy.
>>>>> 
>>>>> Is this as good as it gets?
>>>> 
>>>> You lost me a while ago, Im afraid. 
>>> 
>>> Let's see if this one helps.
>>> 
>>> 
>>>> Pat
>>>> 
>>>>> 
>>>>> 
>>>>>> Contrary to what I said in the telecon yesterday, I now don't think there is any way out of this within the current RDF framework. Basically, you want to talk about the naming relation between a URI and a denotation, and you can't do that in a conventional  rdf-2004-style model theory. You need a small amount of referential opacity to make this work. We will have to change something to get that.
>>>>>> 
>>>>>> Pat
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 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)
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------
>>>>>> IHMC                                     (850)434 8903 or (650)494 3973   
>>>>>> 40 South Alcaniz St.           (850)202 4416   office
>>>>>> Pensacola                            (850)202 4440   fax
>>>>>> FL 32502                              (850)291 0667   mobile
>>>>>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> -- 
>>>>> -ericP
>>>>> 
>>>>> 
>>>> 
>>>> ------------------------------------------------------------
>>>> IHMC                                     (850)434 8903 or (650)494 3973   
>>>> 40 South Alcaniz St.           (850)202 4416   office
>>>> Pensacola                            (850)202 4440   fax
>>>> FL 32502                              (850)291 0667   mobile
>>>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> -- 
>>> -ericP
>>> 
>>> 
>> 
>> ------------------------------------------------------------
>> IHMC                                     (850)434 8903 or (650)494 3973   
>> 40 South Alcaniz St.           (850)202 4416   office
>> Pensacola                            (850)202 4440   fax
>> FL 32502                              (850)291 0667   mobile
>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>> 
>> 
>> 
>> 
>> 
> 
> -- 
> -ericP
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Saturday, 31 March 2012 04:56:37 UTC