- From: Graham Klyne <GK@ninebynine.org>
- Date: Tue, 18 Sep 2012 19:05:22 +0100
- To: Ivan Herman <ivan@w3.org>
- CC: RDF comments <www-rdf-comments@w3.org>, Graham Klyne <graham.klyne@zoo.ox.ac.uk>

On 18/09/2012 11:17, Ivan Herman wrote: > On Sep 18, 2012, at 11:22 , Graham Klyne wrote: > >> Ref. http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Minimal-dataset-semantics >> > > [snip] > >> >> >> DD4, DD5: http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Minimal-dataset-semantics#DD4:_Does_the_graph_extension_assign_graphs_to_resources_or_to_IRIs.3F >> >> I'm treating these together, because I think my response to DD5 renders DD4 somewhat moot. >> >> I think it would be very useful if a graph name n *does* denote the IGEXT(n) graph, as this would provide a hook for future semantic extensions. In the context of provenance, we want to be able to express contexts/situations that are specializations of other (e.g. when talking about a web document on a particular date as a particular instance of that document during a particular year). While I would not (necessarily) expect the specifics of such a mechanism to be part of the RDF Dataset semantics, having a name for talking about the graphs leaves open the possibility of introducing new properties with their own extension semantics. The inconsistencies that would arise if the URI is used as some other kind of resource seem to me to be quite benign (i.e. "don't do that"). >> > > I am not sure I understand the argumentation. > > The present proposal has a strong analogy to the way properties are modeled in the current RDF semantics. If a property has the URI 'p', 'p' does not 'denote' that property, because I(p) is not set of pairs itself but, rather, IEXT(I(p)) is. That provides a smoother way to talk about 'p' or I(p). The current IGEXT approach has a full analogy to this; I(g) is not a graph, but IGEXT(I(g)) is. > > What you favour would mean that the IGEXT is defined on the URI-s themselves. Why would that "...would provide a hook for future semantic extensions" as opposed to the current situation? For practical purposes 'n', in a named graph is, shall we say, 'associated' with the graph, and that seems to be enough for the kind of additional properties you are referring to. Again, just as it is perfectly possible to make all kinds of statement on property 'p', in spite of the fact that, strictly speaking, 'p' does not denote the Property either... Regarding the analogy: By my understanding, the reason for using ICEXT for class extensions is that it allows a class name to be associated with the set of its members without running into problems with the set theoretic logic - http://www.w3.org/TR/rdf-mt/#technote Further, the use of property extensions allows an extensional notion of identity for properties (i.e. two different properties may hold for the same set of value pairs, yet retain their distinct identity.) In the case of IGEXT, as I read it, that's a mapping from URIs to *single* graphs, not sets of graphs. And there does not seem to be any possibility here of self-referentiality. So I'm not seeing any compelling reason to use IGEXT here rather than direct denotation. Unless I'm mistaken (which is entirely possible), the role of IGEXT could be subsumed by the interpretation Id itself. Thus, accepting the suggestion "DD5: Does the graph name denote the graph?" the part of graph interpetation: "for an IRI n and RDF graph g, I(<n,g>) is true iff IGEXT(Id(n)) is defined and E-entails g;" might become "for an IRI n and RDF graph g, I(<n,g>) is true iff Id(n) is a graph E-entails g;" For expositional purposes, it might be useful to keep the IGEXT function (or similar), but add additional semantic constraints on the interprtation to require that the graph names also denote the corresponding graphs. Turning to the second part of your question. If the graph URIs do denote graphs, then one can imagine that new specifications can define new vocabularies with associated semantic extensions that constraint the graph interpretations in interesting ways. I'm thinking that something like: g1 rdfgr:contextSpecializationOf g2 would come with an additional semantic constraint Id(g1) entails Id(g2) for all <g1,g2> in IEXT(rdfgr:contextSpecializationOf) Thinking about your question, it occurs to me that maybe something like this can be achieved without having Id(n) = IGEXT(n), but I'd still ask why bother with the extra machinery and indirection, which seems to be used to avoid what seems to me to be a pretty harmless potential problem (i.e. the inconsistency if n is used in a way that implies it's something other than a graph). ... I clearly haven't worked out the technical details, but I'm hoping this is sufficient to explain my motivation for offering the response that I did. #g

Received on Tuesday, 18 September 2012 18:05:58 UTC