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

On Apr 18, 2011, at 8:00 AM, Pierre-Antoine Champin wrote:

> On 04/18/2011 06:19 AM, Ivan Herman wrote:
>> 
>> On Apr 17, 2011, at 16:49 , Pat Hayes wrote:
>> 
>> <snip/>
>>> 
>>>> 
>>>> 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 by itself would not attach the name to a particular g-box,
>>> however.
> 
> neither does
> 
>  <foaf.rdf#me> a foaf:Person .
> 
> attach the name to a particular person.

Of course; but in the case of *graph* naming, we expect more than simply having a description; we expect the name to be usable to actually locate and get (a representation of) the graph. So we need a 'baptism'  syntax or convention which does the necessary attaching to the name to the graph. 

> 
>> Correct. Some hand-waving may be necessary when we define g-*.
> 
> well, if the URI of the g-box is in the http: scheme, and it is
> dereferenceable (with a 200 OK code), then the HTTP protocol may provide
> that hand-waving...

Not by itself. We need to actually state (it can be as simple as a statement in the specs) that the http GET is what indeed identifies the graph being named. (And of course this statement needs to be phrased very carefully to allow for g-boxes and so forth; are we naming the box or the graph that is its state at the time of naming? What is GOT (GETted?) by a 404 error or a 303 redirect? And so on.)

Pat


> 
>> But I
>> am not sure that a very precise mathematical apparatus is necessary
>> in practice. If we define the g-box, and we say in the text that it
>> has a URI (or as a blank node?) as an identification, that may bit
>> enough... (the engineer in me talking...). However, having that class
>> allows us to define subgraphs, disjointness of g-boxes and the like.
>> That may be all we need.
>> 
>> Yes, I try to make the possible extensions on the formal semantics as
>> minimal as possible...
>> 
>>> 
>>>> (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...).
>>> 
>>> Not so easy. When you *use* a URI in RDF, like the <g> here, it is
>>> not referring to itself, but to what it denotes. (Put another way,
>>> the URI is not quoted.) Which means that rdf:tags isn't going to
>>> have the meaning you intend. Now, we could change this, and say
>>> that rdf:tag is (uniquely) referentially opaque in its subject
>>> position. This would however be a major change to the RDF semantics
>>> and data model, and would require us to re-wrote the semantic spec.
>>> And it has other knock-on consequences eg for OWL, since OWL
>>> equality reasoning would have to be blocked from such triples. So I
>>> think we should think very hard before going there.
>>> 
>>> However, XML Schema has a datatype for making literals refer to
>>> URIs. http://www.w3.org/TR/xmlschema-2/#anyURI  and we could use
>>> that. OK, we can't have a literal in subject position (sigh), so we
>>> have to turn it around:
>>> 
>>> <h> rdf:taggedBy xsd:anyURI^^"<the URI written as a string>" .
>>> 
>>> and then it would all work, without breaking the RDF semantics.
>> 
>> I understand, but isn't this problem a reflection of the fact that we
>> try to model here the common term of tagging, ie, attaching a string
>> to a resource as some sort of a characterization of the latter? In
>> fact, as we said at the f2f, SPARQL is blissfully silent on how that
>> URI is used. If we want to avoid misunderstandings through the usage
>> of the word tagging, we can say something like
>> 
>> <g> rdf:loose_association_of_resources <h> .
> 
> nah...
> 
>  <i> owl:sameAs <g> .
> 
> entails
> 
>  <i> rdf:loose_assoctiation_of_resources <h> .
> 
> Is this what you want to say??
> 
> I prefer Pat's proposa: if you want to associate something with a *uri*
> (and not a resource), use a xsd:anyURI literal.
> 
>    pa
> 
> 
>> Actually, I am not sure anything more precise is necessary. After
>> all, SPARQL has been happily going on with its own loose terms, and
>> making it clear (as we said in the resolution) that, in the SPARQL
>> (<g>,G), <g> is not necessarily the URI that identifies the g-box G
>> may be perfectly enough.
>> 
>> 
>>> 
>>>> 
>>>> 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.
>>> 
>>> The opacity is a big deal. We cannot express this using rules added
>>> to the RDF semantics as it is now. We would need to change the
>>> foundation if we want to use 'bare' URIs to sometimes denote
>>> themselves. I suggest going the anyURI route instead.
>>> 
>>>> 
>>>> 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...
>>> 
>>> see above :-)
>>> 
>>> Pat
>>> 
>>>> 
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> ------------------------------------------------------------ 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
>> 
>> 
>> 
>> 
>> 
> 
> 

------------------------------------------------------------
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 Monday, 18 April 2011 13:41:00 UTC