Re: New Proposal (6.1) for GRAPHS

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? 

> 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?

> 
> <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? 

> 
> + 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. 

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

Received on Thursday, 29 March 2012 22:35:15 UTC