Re: ISSUE-30: How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?

On Apr 14, 2011, at 5:29 PM, Pierre-Antoine Champin wrote:

> On 04/15/2011 12:01 AM, Pat Hayes wrote:
>> 
>> On Apr 14, 2011, at 4:32 PM, Pierre-Antoine Champin wrote:
>> 
>>> Pat,
>>> 
>>> I hadn't notivece this proposal either, I must confess.
>>> 
>>> Aside note: I have a minor problem with that proposal: does the
>>> graph:import statement *have* to be in the default graph? Why not in the
>>> importing graph? Why not in another graph that is trusted to contain
>>> that kind of metadata?
>>> 
>>> By raising the problem, I assume you are referring to my scenario, where
>>> I want to "name" a graph with, e.g., the URI of the foaf:Person it describe.
>> 
>> Yes. And he other variations pointed out by Dan Brickley.
> 
> of course; I was not trying to imply it was just my idea!
> 
>>> 
>>> <foaf.rdf#pa> { [[triples of my foaf profile]] }
>>> 
>>> If I want another graph to import my foaf profile, it would be tempting
>>> to state
>>> 
>>> <other-graph> {  <> graph:imports <foaf.rdf#pa>  }
>>> 
>>> which, I agree, would be a problem (because I refuse to be considered as
>>> a graph ;). The correct way to do it would be to write instead:
>>> 
>>> <other-graph> {  <> graph:imports <foaf.rdf>  }
>>> 
>>> and you seem to imply that it would also be a problem.
>> 
>> Well, no, I am happy with this provided that the connection between
>> the URI '<foaf.rdf>' and the FOAF graph itself is really one of naming,
>> ie that the URI refers to the graph in RDF interpretations.
> 
> That was indeed my assumption here.
> 
>> We have yet
>> to define how to do this, but everyone assumes that we will eventually.
> 
> I tend to consider that a REST resource identified by a http: URI, which
> happens to produce RDF/XML representations, *is* indeed a g-box.

I agree, provisionally. However, that still does not automatically imply that the URI which 'identifies' it is also a name for it. I agree this makes so much sense that it is hard to see how any other convention could be superior; but it needs to be actually stated as a semantic requirement. It does not fall out automatically from any of the semantic or structural properties of RDF as currently defined. This is what I meant when I said that the WG has not yet decided on how to do this.

> (although I agree that some g-boxes may not be REST resources, as the
> concern was raised today at the F2F)

On that point, I did not follow the reasoning involved, but am happy to go with a more general notion, if one is available. My understanding of a REST resource is that it is an entity which can be identified by a URI and emits representations at times. It is hard for me to imagine a more general notion  than this, I must confess. 

> 
>> But what we *have* decided is, that the SPARQL-dataset-labelling syntax
>> does *not* make the URI a name of a graph.
> 
> "does not *necessarily* make the URI a name of a graph"

What I mean is, the actual act of using a URI in this way does not (we have now agreed) itself set up a naming or referential relationship between the URI and the graph. It does not 'baptise' the graph with a name. So if there is such a relationship (I agree, there might be) then it has to be established some other way, one yet to be defined. 

> 
> nothing prevent you to label your graphs this way.

Well, no, there is a lot to prevent you. If graph labeling is indeed graph *naming*, then if you use a name of something else - such as a person - to label your graph, then you have set up a semantic clash. If we were to define graph naming properly (which I sincerely hope we will eventually do), then it would follow that in *all* satisfying interpretations, the URI labeling the graph must denote the graph. So you had better not use a URI which you (or others) think is the name of something other than a graph, because any assertion to that effect will be a logical contradiction.

The point is, if 'labeling' is indeed naming, so that URIs used inside RDF refer to their labels, then you must take the semantics seriously. It is, after all, normative. Or, if we decide that 'labeling' is nothing whatever to do with naming or reference - which is what I thought we had decided at the F2F - then any use of the URI inside RDF bears no relationship at all to the 'labeling' use. You have to choose one or the other: you can't have both. 

> 
>>> But you make
>>> assumptions here:
>>> 
>>> * that the dataset does *not* also contain a graph named <foaf.rdf>,
>>> with the same content
>>> 
>>> * that the engine processing the graph:imports only uses the named
>>> graphs of the dataset to access the imported graph
>> 
>> No, really, it has nothing to do with engines.
> 
> see below
> 
>> It has to do with
>> semantics. What does that URI in the object position of the imports
>> triple *mean*? What does it refer to? What is it the name of?
> 
> according to the phrasing of the proposal, it seems to mean "a g-box"

No, according to the phrasing of the proposal, *absolutely nothing* is implied about what the URI refers to or is the name of. We have *explicitly* said that there is no such connection being made here. 

> 
>> THAT is
>> what must determine what any engine must do.
> 
> indeed, so I jumped (maybe too quicly, granted) to expressing it in
> terms of what an engine should do.
> 
> Rephrasing my second point:
> 
> * that you have no other mean than the dataset to know what a graph URI
> means

You have no way in the dataset either. The dataset only sets up a 'labeling' relationship (tagging? association?) which we have explicitly said has no connection to meaning, semantics or naming.  

> 
>> Imports in OWL and CL does
>> not even require that an engine access a graph at all, in fact, strictly
>> speaking. It is defined purely semantically.
>> 
>>> 
>>> I believe that it is possible to falsify at least one of those
>>> assumptions, and to make graph:impots work. The most natural thing to do
>>> would be to have at least *some* graphs "named" with a proper
>>> identifier, even if that mean some reduncancy in the dataset...
>> 
>> Surely you want to allow importations from outside the particular
>> dataset, right?
> 
> I was not even going that far.
> 
>> If not, I can;t really see what the point of the
>> proposal is.
> 
> * prevent repeating triples in multiple graphs of a dataset
> * automatically reflect the modifications of a graph in another one

But it does not do the latter at all, as far as I can see. We did not even mention the idea of modifications to a graph anywhere in the entire discussion, unless I missed part of it. 

> 
>> As a meta-point, it seems clear that there are a host of unstated
>> assumptions behind these ideas, that really ought to be brought out into
>> the open in WG discussions.
> 
> Sure. I think those two days we have made quite a few of them more
> explicit...

I think there are a lot more waiting. I get the sense that what you think we agreed to, and what I thought we agreed to, have only the thinnest of connections :-)

Pat

Received on Thursday, 14 April 2011 23:07:13 UTC