- From: David Wood <david@3roundstones.com>
- Date: Thu, 16 Aug 2012 11:55:23 -0400
- To: Ivan Herman <ivan@w3.org>
- Cc: Peter F. Patel-Schneider <pfpschneider@gmail.com>, W3C RDF WG <public-rdf-wg@w3.org>
Hi all, On Aug 16, 2012, at 11:45, Ivan Herman <ivan@w3.org> wrote: >> >> I find that this document goes quite a bit beyond what I think is necessary or desirable to support named graphs. I propose instead a minimalist version of graph identification. I will describe this minimalist version by stripping away pieces of the document. >> >> Major changes: >> >> 1/ No mutability: >> >> Mutability is not required for named graphs or graph stores. To effect this change, excise the first part of Section 2, Section 2.1, and Section 2.4. Also fix up the abstract and Section 1. >> >> I am somewhat ambivalent about whether the working group should do anything about mutability, but I am sure that the working group should not tie mutability to named graphs and certainly not to datasets. >> > > It is indeed the question whether mutability should be mentioned. The reason we thought of retaining this is because SPARQL has already introduced this with the differences between data stores and datasets. As the diagram shows this means that there is something 'missing' in the RDF related concepts (something that became also clear at the very beginning of the group's life when the term g-boxes were introduced) to make the picture complete. Indeed, the group may decide not to do anything here, but I still feel that the overall picture would be incomplete... > > It is all SPARQL's fault!:-) …and SPARQL's uses in the real world of deployed information systems constitute a major set of use cases for RDF. I agree with Ivan here; the mutability of SPARQL's Graph Stores and slots suggested (rightly, I think), that the concept of spaces be added to complete the symmetry with the non-mutable concepts already defined in earlier specs. Regarding Peter's proposal, it is still very much an open question whether the mutable aspects of Graph Stores, slots and spaces (which are all mutable by definition) require extensions to the formal semantics. Perhaps that is where we should think next. Pat has said in the past that perhaps we should forgo a semantics for RDF given the widely divergent interpretations in the wild. I (and others) don't think we can or should just throw away the semantics, if for no other reason than OWL, RIF, etc, currently depend on them. That would be an overreaction, to be sure. Instead, perhaps we should consider drawing a line between the semantics of immutable (RDF 1.0) concepts and mutable (RDF 1.1, SPARQL 1.1) concepts. Many could probably live with such a separation. > > >> 2/ Semantic fixes >> >> The document is rather confusing in Section 3.1 where it introduces the semantics of datasets. I would instead just say that the semantics of the named graphs in a dataset are not affected by the semantics of the default graph. >> >> I see little to retain in Section 3.2. I mention two major issues below, but there are also some minor problems. Also the definition of interpretations of datasets is rather badly flawed, it probably means to refer to interpretations of DG, but I can't tell whether this was just missed or whether some portion of the definition was supposed to be this instead. >> >> I don't see why the vocabulary of a dataset should include the RDF vocabulary. Why not just exclude this? I see no reason make RDF graphs disjoint from literal *values*. If someone wants to create their own datatype for RDF graphs, using whatever syntax they dream up, then why not let them? I find it very strange to permit repeated names in a dataset. Why not just require unique names (which is already a condition earlier in the document)? Certainly permitting unequal but simply equivalent values is without precedent and unsupported. The possible requirement that graph names not be blank nodes or not literals belongs in a syntax section, not in the semantics. >> >> There does not appear to be any observable differences between the interpretations for RDF graphs and interpretations for datasets, except if a name is used twice, which can lead to inconsistency (even with requirement 2, unless identity for RDF graphs is modified to mean mutual simple entailment). In any case, Section 2.2 says that names can't be repeated in datasets. The semantic extension is essentially useless, so should just be eliminated. >> >> I suggest instead either saying nothing, or saying that the semantics of an RDF dataset is just the semantics of its default graph. >> > > As we tried to make clear in the document: the 'essence' of the proposal is what you just said and what we tried to put there, ie, that "the semantics of an RDF dataset is just the semantics of its default graph" (by default). If the formal, mathematics part is wrong and if it would lead to too much complications to to get it right then, by all means, I am *personally* happy to just nuke it. Right, the point is the stuff in 3.1. How that may be expressed is currently eluding me, but Peter you can help here. We need you for that. Regards, Dave > > Ivan > >> >> Minor changes: >> >> Whether the name of a named graph can be a blank node is mostly a syntactic issue. Comments about this being a semantic issue should be removed. >> >> The wording in Section 3.1 is rather confused. RDF Graphs don't have "truth". Instead say "semantics". Similarly, RDF graphs don't have "interpretation", which should also be replaced by "semantics". >> >> peter >> >> >> > > > ---- > Ivan Herman, W3C Semantic Web Activity Lead > Home: http://www.w3.org/People/Ivan/ > mobile: +31-641044153 > FOAF: http://www.ivan-herman.net/foaf.rdf > > > > > >
Received on Thursday, 16 August 2012 15:55:51 UTC