- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Wed, 18 Dec 2013 12:28:12 +0000
- To: Antoine Zimmermann <antoine.zimmermann@emse.fr>
- Cc: Pat Hayes <phayes@ihmc.us>, Guus Schreiber <guus.schreiber@vu.nl>, Peter Patel-Schneider <pfpschneider@gmail.com>, RDF Working Group WG <public-rdf-wg@w3.org>
Hi Antoine, Does the following help? You probably think of D-Entailment as an entailment regime. An entailment regime that is parameterised by a datatype map. But D-Entailment is not really an entailment regime, but more a template for entailment regimes. “Batteries not included”. How do you turn this template into an actual entailment regime? You write a specification. A very simple specification. You call it something like My-Entailment. My-Entailment becomes an actual entailment regime by defining it in a specification. The specification states the following: 1) That My-Entailment is a kind of D-Entailment. 2) What the set of recognised datatype IRIs for My-Entailment is. 3) For every datatype IRI in that set, you state the referent, or normatively reference a spec that already does this. An example: [[ My-Entailment is a form of D-Entailment [RDF11-MT]. An implementation of My-Entailment MUST recognise the datatype IRIs xsd:string, xsd:decimal, xsd:boolean, rdf:langString, rdf:HTML, and geo:GMLLiteral, as defined in [RDF11-CONCEPTS] and [GEOSPARQL]. ]] Note that this entails the following sentence: “In My-Entailment, the IRI geo:GMLLiteral MUST denote GeoSPARQL’s GMLLiteral datatype.” So, if you like, you can read this document as placing a semantic condition on My-interpretations: I(geo:GMLLiteral) = the datatype defined in [GEOSPARQL] > Is U a global mapping that all implementations must use? Is it implementation specific? U is not defined by RDF Semantics but MUST be defined by the specific entailment regime: [[ RDF processors may recognize other datatype IRIs, but when other datatype IRIs are recognized, the mapping between the datatype IRI and the datatype it refers to MUST be specified unambiguously, and MUST be fixed during all RDF transformations or manipulations. ]] So, it is not global. It is entailment regime specific. > Is is defined on all IRIs? On a predefined subset of the IRIs? That question is irrelevant for IRIs outside of D, and the requirements for IRIs in D are clearly stated, see quote above. > Does it depend on the set D? No, it depends on the entailment regime. > If it does depend on D, is it possible that for D1 = {http://ex.com/d1} and D2 = {http://ex.com/d1,http://ex.com/d2}, the U associated with D1 differ from the U associated with D2 on the interpretation of http://ex.com/d1? It doesn’t depend on D. > If this U is global, then there are problems in determining conformance. For instance, if a datatype (with IRI ex:d) evolves from version v1 to v2, and an {ex:d}-entailment implementation uses v1 while another implementation uses v2, one of these two implementations is necessarily non-conformant. But which one of them? It’s not global. > In fact, can D-entailment implementations be tested for conformance at all? Yes, if D only includes datatypes IRIs that are W3C standards. No otherwise. How is this different from RDF 2004? Implementations of D-Entailment in RDF 2004 cannot be tested for conformance, unless you fix D and define all the datatypes. > For instance, I have an implementation of {http://ex.com/}-entailment. […] Is it a conforming {http://ex.com/}-entailment implementation? Show me the definition of {http://ex.com/}-entailment, and I can tell you. With the information you have given me, your entailment regime is not fully specified and violates the spec. Again, RDF Semantics says: [[ RDF processors may recognize other datatype IRIs, but when other datatype IRIs are recognized, the mapping between the datatype IRI and the datatype it refers to MUST be specified unambiguously, and MUST be fixed during all RDF transformations or manipulations. ]] So your question is like asking in RDF 2004 about conformance to D-Entailment with a datatype map described as “consisting of the IRI http://ex.com/ mapped and an unspecified datatype”. You can’t say whether an implementation conforms to that either. > I do not note this, it is not editorial because it changes how conformance can or cannot be tested, as explain above. I don’t think that’s true, see above. Best, Richard > On 17 Dec 2013, at 22:30, Antoine Zimmermann <antoine.zimmermann@emse.fr> wrote: > > Pat, > > > I'm sorry but I very strongly disagree with your response. It reinforces my decision to formally object. > > > > Here are remarks that also relate to previous emails: > > First, I do not think it is necessary to introduce "datatype maps" in Concepts. It is sufficient to say that implementation may recognise a set of IRIs to be denoting datatypes, in which case any literals typed with these IRIs must be interpreted according to their respective datatype (the current text pretty much says this, so its ok). > > But in the formalisation of this concept in model theory, some kind of mapping from a set of IRIs to datatypes must be introduced and used in the semantic conditions. It is quite logical to name this mapping "datatype map" in accordance with what was standardised in 2004, and to what is used in various other specifications. > > > The text of RDF 1.1 Semantics CR clearly says that D-entailment works assuming that there is an association between some datatype IRIs and datatypes, which is another way of saying that there is a mapping from a set of IRIs to datatypes. Let us now name this mapping U, to avoid relying on the notion of datatype map. > > The semantic conditions are expressing, in a different way, that a D-interpretation I is such that for any recognised datatype IRI x, I(x) = U(x). The problem is that, by meticulously avoiding introducing and using a name for this mapping U, it is not clear what is the scope of U and the precise definition of it. > > Is U a global mapping that all implementations must use? Is it implementation specific? Is is defined on all IRIs? On a predefined subset of the IRIs? Does it depend on the set D? If it does depend on D, is it possible that for D1 = {http://ex.com/d1} and D2 = {http://ex.com/d1,http://ex.com/d2}, the U associated with D1 differ from the U associated with D2 on the interpretation of http://ex.com/d1? > > If this U is global, then there are problems in determining conformance. For instance, if a datatype (with IRI ex:d) evolves from version v1 to v2, and an {ex:d}-entailment implementation uses v1 while another implementation uses v2, one of these two implementations is necessarily non-conformant. But which one of them? > > In fact, can D-entailment implementations be tested for conformance at all? Yes, if D only includes datatypes IRIs that are W3C standards. No otherwise. > > For instance, I have an implementation of {http://ex.com/}-entailment. My implementation says the following: > > { :s :p "abc"^^<http://ex.com/> } > > entails: > > { :s :p "123"^^<http://ex.com/> } > > Is it a conforming {http://ex.com/}-entailment implementation? > > > I find these issues to be way beyond editorial. > > > Now some comments on your text below: > > "the restriction of a D-interpretation mapping to the set D of recognized datatype IRIs" > > This would be the definition of a datatype map if and only if a D-interpretation was constrained to have its recognised datatype IRIs denote the associated datatypes (that is, constraint to use a given mapping from datatype IRIs to datatypes, a.k.a. a datatype map). > > There is a kind of circular argument: we say that the interpretation of datatype IRIs is constrained by a certain mapping that we do not name, then say that the restriction (which is in fact the unnamed mapping) is what was named "datatype map" before. > > > "The newer style of description is more intuitive, less artificial, simpler (fewer semantic clauses, fewer new concepts introduced)" > > That it is more intuitive, less artificial and simpler is subjective, and I disagree. But even though it was the case, it is incomplete (it does not have enough information to describe conformance, as I mentioned above). The fact that fewer semantic clauses are present is false. I made explicit all the changes that should be made to RDF 1.1 Semantics in order to reintroduce datatype map. It results in exactly the same number of semantic clauses. > To say that it introduces fewer new concepts is dishonest: you behave as if RDF semantics has been defined without datatype map and that Michael and I are trying to impose a new concept that would fondamentally change RDF. It is the opposite: D-entailment has been defined in terms of datatype map, as well as it is in other specifications, and you are trying to impose a change to the existing standard. By doing so, you even added a new concept, recognised datatype IRIs. > > > "more directly related to concepts in wide use in other Web standards and literature, such as the 2004 Architecture of the Web" > > I don't see how this is true but in any case, it may relate more to other Web standards, but it disconnects it from other existing Web standards like OWL 2 RDF-based semantics, SPARQL 1.1 Entailment regimes and RIF OWL/RDF compatibility (as well as tons of publications). > > > "It also introduces the useful terminology of "recognition" of a datatype IRI" > > Introducing this notion does not require any change at all to RDF. > > > "We also note that the changes to which you objected are editorial" > > Who are "we"? I do not note this, it is not editorial because it changes how conformance can or cannot be tested, as explain above. > > > > > AZ. > > > Le 17/12/2013 09:07, Pat Hayes a écrit : > > > > > > On Dec 16, 2013, at 12:13 PM, Guus Schreiber <guus.schreiber@vu.nl> > > wrote: > > > >> Peter, Pat, > >> > >> For this weeks telecon we need a proposed resolution to resolve > >> ISSUE -165 (Datatype maps). I assume that the proposal will be to > >> keep to the current state of affairs, stating briefly the > >> rationale. > > > > Yes, noting the textual modifications that have been made in response > > to the comments. > > > >> Could you propose text? > > > > Below. > > > >> > >> Thanks, Guus > > > > -------------------------- > > > > Thank you for your comment concerning datatype maps, noted in > > http://lists.w3.org/Archives/Public/public-rdf-comments/2013Oct/0067.html > > which was recorded by the WG as ISSUE-165 > > (https://www.w3.org/2011/rdf-wg/track/issues/165). > > > > You requested that we "bring back the old notion of a datatype map." > > In subsequent correpondence, we explained that the idea is in fact > > still present in the newer description, it being the restriction of a > > D-interpretation mapping to the set D of recognized datatype IRIs. > > Since your email suggested that this was not as clear as we had > > intended, we have re-worded parts of the relevant section 7 to give > > this as an explicit definition of the 2004 concept of 'datatype map' > > and added a sentence to clarify how other specifications and > > recommendations which refer to and impose extra conditions on > > datatype maps, can be interpreted as applying to the newer form of > > description. We also added a sentence clarifying how external > > specifications of datatypes can typically define both the type itself > > and the fixed interpretation of its referring IRI, using the > > "datatype map" language to help make the connection clear. > > > > You also objected that there was no motivation for making the change > > to the way that the semantics is described. Here we disagree. The > > newer style of description is more intuitive, less artificial, > > simpler (fewer semantic clauses, fewer new concepts introduced), more > > uniform with the rest of the semantic description (the mapping in > > question is simply a partial interpretation mapping) and more > > directly related to concepts in wide use in other Web standards and > > literature, such as the 2004 Architecture of the Web > > (http://www.w3.org/TR/webarch/) document. It also introduces the > > useful terminology of "recognition" of a datatype IRI, which is used > > throughout the document and also in the Concepts document, and which > > we anticipate will be useful more generally. > > > > We also note that the changes to which you objected are editorial and > > descriptive rather than substantive, since no semantic structures are > > changed, and no entailments are changed. > > > > Please check the wording changes referred to above in the latest > > version of the Semantics document, section 7, and respond to this > > list indicating whether this response resolves the issue raised by > > your comment, including [RESOLVED] in the subject line if it does > > resolve this to your satisfaction. > > > > > > ------------------------------------------------------------ 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, 18 December 2013 12:28:40 UTC