Re: comments re issue-166

One comment below.


Le 23/10/2013 07:09, Sandro Hawke a écrit :
> On 10/23/2013 01:03 AM, Pat Hayes wrote:
>> My responses to all the 'easy' suggestions by Michael are in-line below.
>>
>> Issue-165 will be handled separately.
>>
>> I have a version of the document ready to commit with all the needed
>> edits made, when/if the WG agrees.
>
> Do you want to check it in with another name, and I'll make a diff? (or
> you can, if you have a good tool for that.)
>
>>
>> * §3: The chapter introduces the term "entailment regime",
>>     but does not say much about it. As this term is also
>>     introduced and quite intensively used in the SPARQL 1.1 spec
>>     (in particular by the SPARQL Entailment Regimes spec), I
>>     suggest to be a little more elaborate on the term, in order
>>     to avoid that the terms are not understood differently in
>>     the contexts of the two specifications.
>>
>> Good point. I suggest making this edit:
>>
>> Each semantic extension defines an entailment regime (used here in the
>> same sense as in the SPARQL 1.1 Entailment Regime recommendation
>> [SPARQLENTAIL]) of entailments which are valid under that extension.

I'm not sure Michael wants this. He says "in order *to avoid* that the 
terms are *not* understood differently" (my emphasis).

This looks like a double negation which means: "we want the two concepts 
to be understood differently."

I don't see why he would claim that though. My hypothesis is that 
Michael thinks of SPARQL Entailment Regimes as the whole machinery that 
defines the answers to queries. But I would rather understand SPARQL 
Entailment Regimes as "SPARQL *with* entailment regimes", where the 
answers to queries are defined *wrt* entailment regimes, as defined in 
RDF 1.1.

Perhaps we should tell him that. In any case, it would be a pitty that 
the two specs diverge on the use of this term.


--AZ


>>
>>
>> * §4, 2nd par: I would change the order of "referent and
>>     denotion" to "denotion and reference" to match the order
>>     of the two corresponding terms mentioned earlier in the text:
>>     "denotes and refers to".
>>
>> Agreed, done.
>>
>> * §5.3 (and for other entailment regimes as well): I suggest
>>     to always be explicit on the entailment regimes, when it
>>     comes to the terms "satisfies", "entails", etc. So it should
>>     always be "simply entails", or "RDF entails", instead of only
>>     "entails", even if this may be obvious from the context (it
>>     probably isn't for everyone). After all, these are definitions
>>     and should be as precise as possible.
>>
>> Sigh. OK, all the 'simply's added.
>>
>> * §5.3: the "Technical Note" on not defining entailment
>>     between graphs is in fact also a Change Note, and should
>>     be marked as such in addition.
>>
>> It is impossible to style something both as a technical and a change
>> note. In fact this is not a change, strictly speaking, since the text
>> simply does not provide the definition (of entailment by a set of
>> graphs) which would have been changed.
>>
>> * §5.4: The Simple-semantics theorem "Every graph is
>>     satisfiable" is followed by the statement that "this
>>     does not hold for extended notions of interpretation".
>>     This text should be modified to say that it does not
>>     _always_ hold for extended notions of interpretation.
>>     One could still construct some extended notion where
>>     it does hold, although not for any of the extended
>>     notions in the RDF 1.1 Semantics.
>>
>> Agreed, done.
>>
>> * §5.4, Technical Note: I recommend to remove the claim about
>>     graphs containing many bnodes that this is "unlikely to
>>     occur in practice". Actually, it is relatively common,
>>     namely for OWL documents with many Boolean class expressions
>>     when serialized in RDF, because for a union or intersection
>>     class expression, the number of bnodes is proportional to the
>>     number of classes occuring in the class expression.
>>     Apart from this concrete case, an assumption of the given kind
>>     has in my opinion no place in a spec document, specifically
>>     not within a technical note.
>>
>> Fair point. I will also clarify the oddity of Jeremy's construction by
>> changing "many bnodes" to "only bnodes".
>>
>> * §7, 1st par: typos:
>>     - "... which datatype is identifier by..." should probably
>>       say "identified"
>>     - "... and should treat any literals type": probably
>>       "typed literals"
>>
>> Both fixed.
>>
>> * §7, 2nd par: Why does the text not refer to the term
>>     "lexical space", which is introduced in the RDF 1.1 Concepts
>>     document and has been used in the original RDF Semantics
>>     (and other standards as well)? In the given form, I see no
>>     reason for the term's omission, and the text reads rather
>>     awkward without a direct reference to the lexical space.
>>
>> Fair point. The text is now edited to use "lexical space", as follows:
>>
>>   A datatype is understood to define a partial mapping, called the
>> <dfn>lexical-to-value mapping</dfn>, from a lexical space (a set of
>> character strings) to values. The function <dfn>L2V</dfn> maps
>> datatypes to their lexical-to-value mapping. A literal with datatype d
>> denotes the value obtained by applying this mapping to the character
>> string sss: L2V(d)(sss). If the literal string is not in the lexical
>> space of the datatype, so that the lexical-to-value mapping gives no
>> value for the literal string, then the literal has no referent.
>>
>>
>> * §7, 3rd par: "RDF processors are not REQUIRED". The word
>>     "not" should also be written in uppercase to avoid
>>     misconception while reading the text.
>>
>> ReSpec uses strict RFC 2119 rules, and 'NOT REQUIRED' is not a defined
>> phrase in RFC 2119.
>>
>> * §8: Why is there no table presenting the "RDF Vocabulary"?
>>     The RDFS chapter provides such a table, and the original
>>     RDF Semantics did so as well. It would be useful, at least.
>>
>> Good point. I have added it.
>>
>> * Appendices: Several of the appendix titles contain the text
>>     "(Informative)", directly followed by the sentence
>>     "This section is non-normative". This is redundant. I suggest
>>     to remove "(Informative)" from the titles, in accordance
>>     with the rest of the document.
>>
>> This is kind of tedious, but there is a reason for it. The italicised
>> sentence is added by ReSpec, but we think it desirable to have the
>> table of contexts clearly indicate normativity and its lack, hence the
>> inclusion of the bracketed qualifier in the section titles. I prefer
>> to keep this for extreme clarity even if it is kind of silly.
>>
>> * Appendix D: I don't see a reason to repeat the "non-normative"
>>     declaration for the appendix in each of its sub-sections.
>>
>> ? In the version I see, they aren't so repeated.
>>
>> * Appendix D.2, vocabulary table: I suggest to add the additional
>>     RDFS terms for the container vocabulary as well.
>>
>> Agreed, done.
>>
>> * References: I do not understand why the following documents
>>     are listed as "normative references":
>>     - OWL2-SYNTAX
>>     - RDF-PLAIN-LITERAL
>>
>> Um, neither do I. Does the WG have any guidance on what the rules are
>> here?
>
> I think that must be an typo in the reference syntax.
>
>         -- sandro
>
>> Pat
>>
>>
>>
>> ------------------------------------------------------------
>> IHMC                                     (850)434 8903 home
>> 40 South Alcaniz St.            (850)202 4416   office
>> Pensacola                            (850)202 4440   fax
>> FL 32502                              (850)291 0667   mobile (preferred)
>> phayes@ihmc.us       http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>


-- 
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 Wednesday, 23 October 2013 07:20:59 UTC