- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 18 Apr 2011 08:40:21 -0500
- To: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Cc: Ivan Herman <ivan@w3.org>, RDF Working Group WG <public-rdf-wg@w3.org>
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