- From: Pat Hayes <phayes@ihmc.us>
- Date: Wed, 14 Dec 2011 15:02:19 -0600
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: Guus Schreiber <guus.schreiber@vu.nl>, RDF WG <public-rdf-wg@w3.org>
On Dec 14, 2011, at 7:31 AM, Richard Cyganiak wrote: > Pat, > > On 14 Dec 2011, at 01:40, Pat Hayes wrote: >>> [[ >>> PROPOSAL: Close all graph model+semantics issues by accepting the RDF Datasets design [1] as the data model, and by adding no new semantics. >>> ]] >> >> But that design refers to 'named graphs', which already introduces new semantics (that is, semantics which goes beyond that defined in the RDF specs.) > > Isn't it a fallacy to think that because a symbol is called X, its formal meaning has to be what's implied by X? Yes, but that does not seem to have anything to do with what we are talking about. I am concerned with the actual meaning of this rather important phrase. > > “Blank node identifiers” exist in concrete syntaxes but do not occur at all in the formal semantics, much less “identify” anything. > > The xsd:anyURI datatype is supported in RDF Semantics, and its value space is IRIs, but these IRIs don't “denote” or “identify” in the formal semantics. They simply are inert string values. > > Same with “graph names”, they exist in the abstract syntax, but that doesn't mean they have to occur in the formal semantics. They're ways of grouping RDF triples together, that's all. Well, that is a meaning which the semantics should address. Presumably they have some function: if that functionality produces any entailments that would not hold without it, then the semantics should address and clarify these. > > Research on adding formal semantics for named graphs Named graphs already have a precise semantics. Both the phrase and the full semantics of it were published in the original paper I co-authored with Jeremy and others. If you mean something else by "named graph", please use a different terminology (and so should the specs). > can happen outside of this WG, and different approaches to that problem can compete in the marketplace. They wont compete, but they will produce incompatibilities and make interoperation hard or impossible. Which is exactly what it is our job is to prevent, as far as possible. > >> (I was under the continuing impression that there was a consensus that this solution was unacceptable. > > No such consensus ever existed. What makes you think it did? I understood that people want to be able to use an IRI to 'label' a graph (to be the fourth field in a quad store) while at the same time considering that IRI to denote something else, such as a person. OK, but this means that the relationship between the IRI and the graph it labels cannot be that of naming. Under these conditions, with the RDF semantics unchanged, the fourth field in a quad store, or the IRI associated with a graph in a SPARQL RDF Dataset, is *not* the name of the graph, and these items are *not* named graphs. However, Concepts currently says they are named graphs. OK, you can take the position: to hell with what 'named graph' used to mean, Concepts is currently *defining* it to be simply a <IRI, graph> pair; end of story. Which is a coherent position, as long as you stop there. But in fact, everyone wants more: they want to be able to *use* the IRI to *refer to* the graph, inside some RDF triples. And this simple definition of named graph does not cut it for that use. You have to also specify that the IRI denotes the graph (a semantic condition.) Just being a handy organizing tag isn't enough to get the intended meaning of this 'tag' into RDF. I confess that I am now rather puzzled about what position the WG has actually taken. On the one hand, there seems to be a strong feeling that this kind of labeling flexibility must be permitted: on the other, there seems to be a resolution that the labeling IRI in a SPARQL store does indeed denote the graph. Taken together, these directly contradict the current RDF semantics, so *something* has to be changed. Pat > > Best, > Richard > > > > >> >> Pat >> >>> Knowing who can't live with this minimalist approach would be a form of progress IMO. >>> >>> Best, >>> Richard >>> >>> >>> [1] http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-multigraph >>> >> >> ------------------------------------------------------------ >> 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
Received on Wednesday, 14 December 2011 21:03:03 UTC