Re: Comments on Last-Call Working Draft of RDF 1.1 Semantics

In fact, I think there is an issue with this repsonse.

It insists very much on the fact that the old design allowed non 
standard mapping. This is besides the point. Non-standard mappings would 
only be allowed in an entailment regime that does not dissallow them. 
But in RDF 1.1 we made the entailment regimes to necessarily disallow 
non standard datatype mappings. The new design, avoiding datatype map in 
the definitions, does not change anything to the issue. The issue is 
solved by adding explicit additional semantic conditions that disallow 
an XSD datatype (or OWL or RDF datatype) to be interpreted differently 
from their normative specifications. This can be done with datatype maps 
all the same.


Le 23/10/2013 05:40, Pat Hayes a écrit :
> Hi Antoine
>
> Yes, I sure did have a strong sense of deja vu while reading
> Michael's comment:-)
>
> Let me suggest the following editorial change, to expand the second
> "change note" in section 7 to read something like this:
>
> In the 2004 RDF 1.0 specification, the semantics of datatypes were
> stated in terms of datatype maps.

This sentence is unnecessary.


  The current treatment subsumes
> datatype maps into the interpretation mapping on recognized IRIs. The
> <dfnf>datatype map</dfn> corresponding to D is exactly the
> restriction of a D-interpretation mapping to the set D of recognized
> datatypes.

Ok for this.


  The 2004 definitions permitted "non-standard" datatype
> maps (such as one that maps the IRI
> 'http://www.w3.org/2001/XMLSchema#decimal' to the datatype identified
> by http://www.w3.org/2001/XMLSchema#gYearMonth). Semantic extensions
> based on such non-standard mappings are not sanctioned by this
> specification.

This should just be mentionned as a side note saying that we 
*additionally* provided constraints on how datatype IRIs should be 
interpreted. While this is completely independent from Michael's 
concern, it may please him to see this nice change that may keep him 
happier.


AZ.

>
> WG comments on this?  It might help by providing both a reason for
> the change and a link to an exact definition of "datatype map" for
> legacy uses.
>
> Pat
>
>
> On Oct 22, 2013, at 2:47 AM, Antoine Zimmermann wrote:
>
>> All,
>>
>>
>> I would like to stress that I brought to the Working Group the
>> *very same* arguments against the change on datatype map.  None of
>> these arguments have been considered important at the time, such
>> that it was deemed purely editorial. The current text is the result
>> of a compromise that I can live with, but I still prefer, because
>> of the arguments given below, to keep datatype maps as before (but
>> I don't want to block the ref track process).
>>
>> Here are links to the relevant discussions, to help solve the issue
>> efficiently.
>>
>> My review of Semantics, with the objection to the change:
>> http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jun/0085.html
>>
>>
>>
See the rest of the thread (note that it includes discussion on union of 
graphs which is not relevant to the datatype issue).
>>
>> Peter's reply wrt the datatype issue:
>> http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jun/0102.html
>>
>>
>>
(and following emails)
>>
>> There are also minutes of teleconferences containing discussions on
>> this topic, where it is very clear that at least Pat, Peter,
>> Sandro, Ivan and David consider the issue to be purely editorial,
>> and so, not even worth a formal objection.
>>
>>
>> The main argument of the Working Group can be summarised with PFPS
>> concise sentence:
>>
>> "NOTHING HAS REALLY CHANGED IN DATATYPES BETWEEN 2004 and
>> NOW!!!!!"
>>
>> in lists.w3.org/Archives/Public/public-rdf-wg/2013Jun/0134.html
>>
>> And less bluntly:
>>
>> "Datatype maps didn't get you anything.  They looked as if they
>> provided an extra level of formality, but all that they did was
>> require an extra level of magic.  Sure, this extra level of magic
>> was generally benign, and invisible from users, but it certainly
>> didn't match up with the way datatypes are defined in XML Schema
>> datatypes the source of most of the usable RDF datatypes."
>>
>> I do not agree with this statement but it has been the "official"
>> answer to me at the time, and the arrangements in the text were
>> sufficient for me to live with it, so I see no reason to use any
>> other arguments in response to Michael, pointing to the relevant
>> emails.
>>
>>
>>
>>
>> AZ.
>>
>>
>> Le 22/10/2013 01:29, Michael Schneider a écrit :
>>> Dear RDF Working Group!
>>>
>>> This is my review of the Last-Call Working Draft of the "RDF 1.1
>>> Semantics" specification.
>>>
>>> I like to repeat that I wasn't able to finish my review in the
>>> very short given time since the announcement of the LCWD as of 3
>>> October, and that I have a strong stake on this document. As for
>>> my review of the "Concepts and Abstract Syntax" LCWD, I have
>>> created the review for the most-current Editor Draft, available
>>> at
>>>
>>> <https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html>
>>>
>>> In general, I am quite pleased with this document, even with
>>> most of the deliberate changes being made to the original RDF
>>> Semantics, and most of my comments are only about small details,
>>> and are not design-related (and can thus be, in principle, be
>>> dealt with later in the context of the upcoming CR). However,
>>> there is a single, design-related, issue which I consider urgent
>>> (as for to be treated in the context of the Last-Call phase), and
>>> important.
>>>
>>> URGENT ISSUES (DESIGN-RELATED):
>>>
>>> * §7: The notion of a "datatype map" has been effectively
>>> replaced by a new notion of "recognized IRIs". No further
>>> explanation is being given for this change. I have to note that
>>> the notion of datatype maps has been used and is deeply
>>> integrated in several of the other core Semantic Web
>>> specifications: SPARQL 1.1 (in the SPARQL Entailment Regimes
>>> spec), OWL 2 (specifically in the RDF-Based Semantics), and RIF
>>> (in the RDF-and-OWL Compatibility spec), and it is probably
>>> generally in quite wide use, for example in many scientific
>>> papers and books. I believe the notion of a datatype map as very
>>> basic and relevant for the stack of semantics specifications that
>>> are based on the RDF Semantics spec. In addition, I have never
>>> encountered any bigger problem with this notion, even though I
>>> have been highly involved with it during the years, in particular
>>> in my work as the editor of the OWL 2 RDF-Based Semantics. So
>>> under these circumstances, I consider this change harmful for the
>>> foundation of the Semantic Web, and with the lack of any rational
>>> the change even appears to me to be an arbitrary choice. In my
>>> opinion, it goes too far for a "1.1-style revision" of the RDF
>>> specification. In summary, I cannot accept this change and ask
>>> the WG to bring back the old notion of a datatype map.
>>>
>>> NON-URGENT ISSUES (NOT DESIGN-RELATED):
>>>
>>> * §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.
>>>
>>> * §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".
>>>
>>> * §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.
>>>
>>> * §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.
>>>
>>> * §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.
>>>
>>> * §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.
>>>
>>> * §7, 1st par: typos: - "... which datatype is identifier by..."
>>> should probably say "identified" - "... and should treat any
>>> literals type": probably "typed literals"
>>>
>>> * §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.
>>>
>>> * §7, 3rd par: "RDF processors are not REQUIRED". The word "not"
>>> should also be written in uppercase to avoid misconception while
>>> reading the text.
>>>
>>> * §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.
>>>
>>> * 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.
>>>
>>> * Appendix D: I don't see a reason to repeat the "non-normative"
>>> declaration for the appendix in each of its sub-sections.
>>>
>>> * Appendix D.2, vocabulary table: I suggest to add the
>>> additional RDFS terms for the container vocabulary as well.
>>>
>>> * References: I do not understand why the following documents are
>>> listed as "normative references": - OWL2-SYNTAX -
>>> RDF-PLAIN-LITERAL
>>>
>>> Best regards, Michael Schneider
>>>
>>>
>>>
>>
>> -- 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/
>>
>>
>
> ------------------------------------------------------------ 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 15:57:29 UTC