Re: New Proposal (6.1) for GRAPHS

On Mar 31, 2012, at 8:09 AM, Eric Prud'hommeaux wrote:

> * Pat Hayes <phayes@ihmc.us> [2012-03-30 23:56-0500]
>> 
>> 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> } .
> 
> I surmise that the one on the left was written before the one on the right, which I can only do if they are logically identical, but still different representations of the same thing.

Use/mention confusion. I was talking about the graphs, you are talking about the syntax I was using to refer to them. 

> 
> 
>>> <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. 
> 
> What if these were copies of a book?

Yes, but they aren't. They are RDF graphs, and RDF graphs don't have editions or copies. (Fortunately: lifs is messy enough as it is.)

> You and I both go buy the latest edition of 2012 International Plumbing Code (excited to hear that it includes international private sewage disposal code) and we stamp them with our respective names. Your book belongs to you and mine belongs to me -- pretty non-controversial. We read them cover-to-cover and pawn them off on the same used bookstore, where they sit on a shelf side by side.
> 
> This seems consistent with saying that a Trig document, or a SPARQL graph store, is a library of representations¹ of potentially identical graphs with the practical stipulation that they have distinct labels (so we don't have to consider order and that sort of thing). YOU don't specifically want to attach different observations to them, but I think we need to in order to solve any of the problems we want to solve.
> 
> ¹ I'll just repeat it until it becomes true.

Ah, the power of prayer.

> 
> 
>>> 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.
> 
> There is a bit of pretzeling; you end up manipulating the platonic graphs with tongs (represents equivalent graph) rather than by hand (same as).

Here's a better analogy: you have to use insulated gloves because there just might be a live wire. But people will find that often, it's not live, and the gloves are a nuiisance, so they will just grab them anyway. And then someone gets electrocuted. This is why we have electrical codes. 

> 
> I believe you stipulate that <u1> and <u2> label the same thing, which means that anything you say about one, you say about the other.

Well, that is not exactly me stipulating this, it is the way that the specs stipulate it, and how everyone has read it up until now. And I suspect, how almost everyone will go on reading it. 

> Is there anyway to avoid crazy pretzeling without putting and undo burden on the user (e.g. approach 1 above)? Perhaps we can answer that in another few months.

We don't HAVE to try to solve this by using membership in a class. There might be a different way to do it. We might for example say that the 'real' name label itself has a special status which glues it to the graph. That would avoid the need to pretzel the graphs, at a modest cost in tweaking an RDF rule for some triples used in dataset metadata (or even not even that, if people are OK with using URI literals.) 

But in any case, I'm not at all sure I know what problem it is that you are pretzeling to solve here. WHY do you want one graph label to be a real name but another one to not be? Was this ever a design condition for SPARQL datasets? To me, this comes out of left field, and it alone is causing all the trouble here.

Pat


> 
> 
>>> 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
>> 
>> 
>> 
>> 
>> 
> 
> -- 
> -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 19:48:56 UTC