- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Fri, 30 Mar 2012 08:01:00 -0400
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Sandro Hawke <sandro@w3.org>, public-rdf-wg <public-rdf-wg@w3.org>
* 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? <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). 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.
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. Nothing changes mechanically; we just change our excruciatingly precise explanation of the operators, e.g. { <u1> :equals <u2> } is really { <u1> :isExpressionOfSameTheGraphAs <u2> }.
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.
> 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
Received on Friday, 30 March 2012 12:01:39 UTC