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

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.

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

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

Received on Monday, 18 April 2011 13:01:08 UTC