Re: Resolution needed: ISSUE-165: datatype map

Le 18/12/2013 13:28, Richard Cyganiak a écrit :
> Hi Antoine,
>
> Does the following help?

The following is your interpretation of the spec. Although it is a 
sensible interpretation, and I hope everyone will be able to understand 
it like this, it is not what RDF 1.1 Semantics says.

But in any case, Semantics not describe how an agreement on what IRIs 
denote is to be defined or provided. Concepts already tackles this 
subject a bit.

But I am not even certain that your interpretation is what Pat has in 
mind. You are referring to some kind of social agreement with a 
documented specification. Pat is more specific, since he refers to "Web 
machinery". By saying Web machinery, it seems that it excludes datatype 
maps that would be decided at face tod face meetings to implement the 
D-entailment in a company's information system.

Because of the necessity to rely on "Web machinery" (assuming this 
interpretation of the spec), such a scenario would lead to a 
non-conforming implementation.  So in fact, the conformance is subject 
to interpretation of the spec.  This was not true in 2004: 2004-style 
D-entailment does not leave anything to interpretation of the spec 
(although you suspect it did, but you mistakenly assume that the 
datatype to which IRIs map is unspecified).


Few comments below.


> 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.

Wrong. For all datatype maps D, the fact that a graph D-entails another 
graph is fully specified by RDF 2004. If you pretend to implement 
D-entailment with a specific D, it is verifiable from RDF 1.0 Semantics 
whether your implementation conforms or not.

Of course, there is no single D-entailment regime, it is a family of 
entailment regimes parameterised by a datatype map. So what RDF 1.0 
defines is something like {(xsd:int,d1),(ex:geometry,d2)}-entailment, 
where d1 is the datatype "int" from XSD and d2 is the datatype defined 
in the spatial extension of RDF and SPARQL. Since you have d1 and d2, 
all you have to do is check RDF Semantics to verify whether:

  :s :p "(200,60)"^^ex:geometry .

{(xsd:int,d1),(ex:geometry,d2)}-entails:

  :s :p "(-160,60.0)"^^ex:geometry .

In practice, you don't write the pairs in line as I do here. Because of 
the constraints we put in Concepts about XSD datatypes, it is not 
necessary to provide the first pair, the IRI suffices. For the second 
pair, any ways of explaining what datatype is associated with 
ex:geometry is ok. If you are a linked data enthusiast, you'd likely put 
a document that you can fetch when dereferencing ex:geometry.

Now, with a simple set, e.g., {ex:geometry}-entailment is not specified, 
so implementation have to declare they implement 
"{ex:geometry}-entailment with ex:geometry identifying spatial 
datatype". But if this is implementation specific, it means that two 
implementations of {ex:geometry}-entailment may conform while having 
different results. So it leads to the same situation where D-entailment 
must be specified in terms of a mapping rather than a set. But again, 
all of this is not clearly stated, and I'm not sure everyone has the 
same interpretation.


>> 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.

The spec pretends to define the family of entailment regimes called 
D-entailment. But you are saying it does not in fact, it only defines a 
template for such entailment regimes, where you have to fill in the 
mapping from IRIs in D to datatypes (that is to say, implementations 
have to provide the mapping anyway, which was what RDF 2004 already 
said, more explicitly).


  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”.

In RDF 2004, the datatype is part of the map. The letter D is a place 
holder for a mapping, there is no one entailment regime called 
"D-entailment" (similarly to RDF 1.1, where D is a place holder for a 
set). It is thus fully specified in 2004-style D-entailment, not quite 
in RDF 1.1.


> You can’t say
> whether an implementation conforms to that either.

You have both the IRI and the datatype it maps to, so of course you can.


AZ.

>
>> 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/
>
>


-- 
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 14:45:07 UTC