- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 22 Oct 2013 22:40:34 -0500
- To: Antoine Zimmermann <antoine.zimmermann@emse.fr>, RDF WG <public-rdf-wg@w3.org>
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. 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. 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. 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
Received on Wednesday, 23 October 2013 03:41:05 UTC