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

I am not sure that an explicit 'import' is really necessary... It sounds very 'operational'. In the sense that I am not sure any semantics should describe everything that can be or will be done with RDF and their g-boxes.

My very sketchy feeling that if we define a good old class, say, G-box, we can then:

- say that <g> rdf:type G-box which is the identification of a g-box (this is not the SPARQL sense, see below
- we _may_ want to define relationships like <g> rdf:subsetOf <h>, maybe <g> rdf:disjointOf <h>, ie, to describe relationships among g-boxes (I am not sure that is necessary but it sounds useful)
- we will have some additional predicates of the form <g> rdf:tags <h>, where <h> rdf:type G-box. Ie, other relationships among g-boxes and URI-s are possible beyond a strict identification (maybe rdf:tags is the only such predicate, actually, but there may be more...).

In other words, a SPARQL (<u>, G) means that <u> rdf:tags <Resource-for-G>, where <Resource-for-G> is an internal id for a graph (yes, it can even be a blank node or an internal URI used by a triple store)

Adding these to the RDF Semantics does not seem to be a big deal in line of what is already there, they are some additional terms in the rdf (or rdfs? I never know) vocabulary with some additional semantic conditions or equivalent entailment rules.

There might be some features that are not described by these. 

Caveat: I am not a logician, so I am sure Peter and Pat will jump at me saying...

Ivan


On Apr 15, 2011, at 24:29 , 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.
> (although I agree that some g-boxes may not be REST resources, as the
> concern was raised today at the F2F)
> 
>> 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"
> 
> nothing prevent you to label your graphs this way.
> 
>>> 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"
> 
>> 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
> 
>> 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
> 
>> 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...
> 
>> Importation is quite a big deal to get
>> right, and assumes a robust graph naming scheme.
> 
> Agreed.
> 
>  pa
> 
>> 
>> Pat
>> 
>> 
>>> especially if we have graph:import to manage this redundancy without too
>>> much overhead !
>>> 
>>> <foaf.rdf>    {  [[some-triples-gere]] }
>>> <foaf.rdf#pa> {  <> graph:imports <foaf.rdf>  }
>>> <other-graph> {  <> graph:imports <foaf.rdf>  }
>>> 
>>> et voila!
>>> 
>>> Granted, this would have to be carefully explained along with the
>>> graph:imports proposal, should we keep it. But I don't think it is too bad.
>>> 
>>> pa
>>> 
>>> On 04/14/2011 07:09 PM, Pat Hayes wrote:
>>>> Well, the use of a URI inside an RDF triple assumes that the URI is being used as a name, to refer to something. Using a URI which is the name of a named graph, for example, would refer to the graph. But in this decision we *explicitly* say that this is *not* how the SPARQL association of URIs to graphs works: that the 'associated' graph which is 'tagged' (if I have that right) by a URI might well not be the entity referred to by the URI. The example was given in which the URI is the name of a person, ie refers to a person, and still can be used to 'tag' a graph for SPARQL purposes. If such a URI is used as the object of an RDF triple, it will refer to the person, not to the SPARQL-tagged graph. As there is no way to know whether the graph that is SPARQL-tagged by a URI is, or is not, the referent of the URI, any use of that URI as a name inside an RDF triple must be basically unrelated to its use as a SPARQL graph tag; or at any rate, that is the only safe assumption to 
> ma
>>> ke. 
>>>> 
>>>> In a nutshell, RDF uses URIs as referring names. Apparently, SPARQL does not, when it comes to identifying graphs. So the uses of URIs in RDF triples and in SPARQL tags are dissociated from one another, and need have no relationship. So, no relationship can be relied upon. The 'naming' of graphs in SPARQL is a wholly SPARQL-local business, unrelated to RDF semantics and therefore to any RDF content. 
>>>> 
>>>> I assumed this was obvious at the time we were discussing this, by the way. But I confess I had not at that time read the Wiki proposal fully, and not seen the 'imports' examples. 
>>>> 
>>>> Pat
>>>> 
>>>> On Apr 14, 2011, at 11:55 AM, Ivan Herman wrote:
>>>> 
>>>>> Pat,
>>>>> 
>>>>> sorry, but you will have to explain (me) what the problem is.
>>>>> 
>>>>> Ivan
>>>>> 
>>>>> ----
>>>>> Ivan Herman
>>>>> web: http://www.ivan-herman.net
>>>>> mobile: +31 64 1044 153
>>>>> 
>>>>> On 14 Apr 2011, at 18:43, Pat Hayes <phayes@ihmc.us> wrote:
>>>>> 
>>>>>> I note in passing that the Proposed WG Decision dated 14 April has the consequence that the IRi associated with a graph in SPARQL cannot be used inside an RDF triple to reliably refer to the graph. This means in particular that uses such as those contemplated in
>>>>>> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal, which use the SPARQL name as the object in an 'imports' triple, are ruled out by this decision. 
>>>>>> 
>>>>>> Pat
>>>>>> 
>>>>>> On Apr 13, 2011, at 4:29 AM, RDF Working Group Issue Tracker wrote:
>>>>>> 
>>>>>>> 
>>>>>>> ISSUE-30: How does SPARQL's notion of RDF dataset relate our notion of multiple graphs?
>>>>>>> 
>>>>>>> http://www.w3.org/2011/rdf-wg/track/issues/30
>>>>>>> 
>>>>>>> Raised by: 
>>>>>>> On product: 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------
>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> ------------------------------------------------------------
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> ------------------------------------------------------------
>> 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
>> 
>> 
>> 
>> 
>> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf