Re: Comments on TF-Graphs/Minimal-dataset-semantics

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