Re: Draft for a "minimal dataset semantics"

On Sep 7, 2012, at 12:34 , Antoine Zimmermann wrote:

> Le 07/09/2012 10:47, Ivan Herman a écrit :
>> 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:-)
> 
> I'm not sure I deserve this qualifier but thank you.
> 
> 
>> 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.)
> 
> Ok.  I agree but only with a +0.  I think we should still mention the issue somewhere.  But I approve putting this for the moment, in the interest of moving forward.  And I have no problem having my prose be modified inside a good version control system.  It is a collaborative work, so go ahead.
> 
> 

You misunderstood. What I meant was to put the issues into a separate section.

I still have to do some mailing (like this one:-) and I may have a go at it.


>> As for the additional issues you raise:
>> 
>> On Sep 6, 2012, at 23:01 , Richard Cyganiak wrote:
>> [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.
> 
> Using "equivalent" instead of "entails" makes a huge difference.
> 
> E.g.,
> 
> <g> {
>  <s> <p> <o> .
>  <a> <b> <c> .
> }
> 
> would not entail:
> 
> <g> {
>  <s> <p> <o> .
> }
> 
> no matter what entailment regime is used (unless you can define a custom regime where the two graphs are equivalent).
> 

Right, this is the subgraph issue. Hence my preference to the "entails" 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.
> 
> The default graph may be used in different ways:
> 1. It expresses meta-information about the graphs or dataset, which may or may not be consistent with the individual graphs. Or express your belief in the default graph, and express other people's beliefs in named graphs. Or any other situation where there may be disagreements between what the default and the named graphs say.
> 2. It contains the merge or the union of the named graphs. Useful if you have a big graph that you want to slice, for instance.
> 3. It contains "global truth" as you say, e.g., ontologies used by the named graphs.
> 
> If there is no specified relationship between the default graph and the rest, you can still cover all 3 cases with a proper semantic extension, or simply with careful implementation of the system.
> 
> 

+1


>>> 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.
> 
> I think, too, that it is safer to say "no" but I support the idea of having a note.
> 
>> 
>>> 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.
> 
> I understand that the term "denote" is used to talk about the resource associated with an IRI by the function IS in the formal definition of (simple) interpretation (http://www.w3.org/TR/rdf-mt/#interp). If IGEXT maps IRIs and not resources, you could call this "denote" if you want, as it would be a kind of punning, but the IRI would also denote something else via the function IS.
> It's better not use the word denote for this.


Actually, this 'punning' effect was also the reason why I preferred the approach whereby IGEXT maps resources. The fact that 'n' would get two different mappings within the same interpretation sounds like an issue to me.

Ivan

> 
> If this Issue 10 is talking about denoting in the sense of RDF 1.0, then no, n should not denote the graph as it would lead to essentially no useful entailments.
> 
> <n> {  <s> <p> <o> . <a> <b> <c> .  }
> 
> would not entail:
> 
> <n> {  <s> <p> <o> .  }
> 
> under any entailment regime.
> 
>>> 
>>> 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:-)
> 
> Apart from Peter, I don't remember anybody raising their voice against having some kind of semantics.  I remember there was, at the beginning, some other people saying we don't need a semantics.  But the debate (battle?) was only starting.
> 
> 
> AZ
> 
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Antoine Zimmermann
> ISCOD / LSTI - Institut Henri Fayol
> École Nationale Supérieure des Mines de Saint-Étienne
> 158 cours Fauriel
> 42023 Saint-Étienne Cedex 2
> France
> Tél:+33(0)4 77 42 83 36
> Fax:+33(0)4 77 42 66 66
> http://zimmer.aprilfoolsreview.com/


----
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 12:13:13 UTC