Re: Draft for a "minimal dataset semantics"

Hey Richard, 

I have the impression that Antoine, you and I have a consensus on the issues listed on the page, comparing this reply and my earlier one[1]. We also have a consensus saying that Antoine is a star:-)

Some more comments on the issues you raise below. Editorially, and for readability, it may be a good idea to change the page to look more 'final' in terms of the text and push all the issues into a separate section. As far as I see the only change on the current technical text is to change the semantics to what Richard called the RES-IGEXT (in case Antoine agrees with that, too). (Antoine, if you have other commitments today, I am happy to do that this afternoon.)

As for the additional issues you raise:

On Sep 6, 2012, at 23:01 , Richard Cyganiak wrote:

> Antoine,
> 
> You're a star. See inline for my opinions on the various issues, some requests for clarification, and some proposed additional issues.
> 

[skip]

> 
> I guess I'd add a couple more issues:
> 
> Issue 7: Should it be sufficient for the truth of I(<n,g>) that IGEXT(n) E-entails g, or do we require that IGEXT(n) is equivalent to g under E-entailment? This is open-graph versus closed-graph semantics.
> 
> It seems to me that the open-graph version (entailment, not equivalence) meshes better with the open-world assumption of RDF. I believe it is also the weaker semantics, and closed-graph can be done as a proper semantic extension.
> 


To be honest with you, I do not have strong feelings about this one. The reason I am more in favour of the current formulation is because that allows

g { .... }

to describe a subgraph of the graph that 'g' denotes (and I use 'denote' loosely here...). 

Ie, I agree with you to have a preference for the current approach.


> Issue 8: Should the truth of a named graph require that the named graph satisfies the default graph?
> 
> It seems to me that this could be useful, because I could dump some “global truths” like vocabulary definitions into the default graph, and actually have them take effect in all the named graphs. But I haven't thought hard about this, and it may have undesirable side effects that I'm missing. I could live with the simpler “no” answer.
> 

I am not really sure what you mean. The current formalism on the page definitely says 'yes' (unless I miss something); in fact, the truth effectively depends on the truth of the default graph only, except for some other restriction on how the pairing of a name and a graph looks like.


> Issue 9: Should we allow different entailment regimes in different named graphs based on statements made in the dataset?
> 
> This seems to be coming up again and again, so it's worth flagging as an open issue. I'd prefer no as an answer.
> 

Oh yes, this is a slightly more extended version of Issue 1. 

In my original reaction[1] I said 'no' to actually this issue, not Issue 1 (which is subsumed by this one). It is interesting to note that SPAQL Entailment went actually along the line of having different entailments per graphs, which made me think. But maybe it is safer to answer 'no' in this round as part of the Rec; we may put a Note or an informal appendix somewhere hinting at the fact that it is possible to formulate the semantics in that enlarged format, but not as a normative section.

> Issue 10: In <n,G>, does n denote G, or may n denote any resource?
> 
> This may or may not be the same as your Issue 4 above, and perhaps no one is arguing for “n denotes G” any more. At any rate I think it would be worth getting a formal resolution. For my vote, see Issue 4 above.

I do believe this is the same as Issue 4. I may miss some nuance, though.

> 
> And, perhaps:
> 
> Issue 0: Should we say anything about the semantics of RDF datasets at all? (I know Peter's vote on that one.)
> 

Yes. We should formally vote on this. I know my vote goes for what we have here:-)

Cheers

Ivan

[1] 

http://www.w3.org/mid/7B69F49E-7063-45FF-90F8-6A97EF19F2D3@w3.org


> Best,
> Richard


----
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 Friday, 7 September 2012 08:47:58 UTC