W3C home > Mailing lists > Public > public-rdf-wg@w3.org > September 2012

Re: Re3 : Draft for a "minimal dataset semantics"

From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
Date: Fri, 07 Sep 2012 17:15:19 +0200
Message-ID: <504A0F87.7090606@emse.fr>
To: public-rdf-wg@w3.org
Ivan, I agree.


FWIW, here are my votes about the issues:

  0. Yes, we should define a formal semantics.  +1

  1. No, not in the spec, although applying different regimes amount to 
making incomplete OWL Full + RIF reasoning in all graphs, so it can be 
done in a concrete implementation.  -0

  2. Dunno. I still think that "no-semantics" is wierd and kinf of 
absurd, yet if the assumed semantics can be declared, then it might be 
useful.  -0

  3. No, not normatively, but it can be done with the SPARQL 1.1 Service 
Description vocabulary anyway. In any case, this should just be an 
/indication/ for the consumer, who is free to ignore the declaration.  -0
  4. My choice would be IGEXT:IRI -> Graph but I'll take what majority 
wants.  -0

  5. The IRI denotes anything.  -1 if it must denotes the graph, in the 
RDF 1.0 sense of "denote"

  6. IGEXT(x) has to entail the graph associated with x.  -1 if 
equivalence is required instead.

  7. No.  -1


In any case, issues 1, 2 and 3 can be addressed outside, or after this 
WG, I believe. The other issues can put barriers for future improvements.


AZ

Le 07/09/2012 15:32, Ivan Herman a écrit :
> Antoine, Richard,
>
> I have re-edited
>
> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Minimal-dataset-semantics
>
> to separate the issues. I have merged some of the issues where I felt that was helpful, and also incorporated Richard's extra issues. Have a look to see if I misunderstood something.
>
> If we three agree (and I have the impression we do), then we may ask the chairs to put this on the agenda next week...
>
> Ivan
>
>
> 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.
>>
>>
>>> 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).
>>
>>
>>>> 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.
>>
>>
>>>> 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.
>>
>> 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
>
>
>
>
>
>
>

-- 
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 66 03
Fax:+33(0)4 77 42 66 66
http://zimmer.aprilfoolsreview.com/
Received on Friday, 7 September 2012 15:15:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:51 GMT