Re: D-entailment question in http://www.w3.org/TR/2014/PR-rdf11-mt-20140109/

Hi Pat, all,

thanks for the clarifications in this and the earlier message. 

ad a) 

> I will work through the document and see if I can make the linking more transparent.

That’d be appreciated, and I re-emphasize that this change is purely editorial.

ad b) 

[…]
> What it says is that the meaning of an IRI may be determined by something outside the RDF semantics.
[…]
> The semantic Web *is* a mixture of formal and informal, however, and sometimes we have to face up to that reality :-)

Allow me to take these statements as follows: the intention of the group was to be 
deliberately more vague than in RDF 1.0 … If that is indeed the group’s 
intention, I can live with that and acknowledge my comment dealt with. 


(additional points below here I am happy to discuss further offlist, i.e., 
 no further formal group reply expected ):

>> What I am trying to say is that I have the feeling that the current spec is 
>> here less clear than the old spec. Was this the intention?
>
> No, but the old style required readers to understand the idea of a "datatype map”, 
> which was a completely artificial construct, divorced from Web reality.
> Nobody has ever implemented or even seriously considered such a map that is 
> not simply the use of Web conventions to assign meanings to IRIs. 

Frankly, I am a bit surprised about the argument that "nobody ever implemented datatype maps", 
 doesn't any RDF implementation that supports a fixed set of datatypes, 
implicitly also implements a respective datatype map (while not strictly in the RDF 1.0 sense 
where D-entailment was only defined on top of RDFS. As mentioned before, I appreciate that D-Entailment 
was made independent from RDFS): I had always understood the definition of datatype maps as just 
the formal backing for “supporting” an extensible set of standard datatypes. 

Plus, OWL2 uses the concept of datatype maps as well to define the semantics of datatypes (based on the 
RDF1.0 definitions). Likewise SPARQL1.1 Entailment Regimes, relies on the definition of datatype maps from RDF1.0.
Anyway, both these specs rely - in principle - on RDF1.0 and will not break.

So, while I am still surprised that the change of D-Entailment required to drop the definition of 
datatype maps on the way, again, if the intention is to be more vague in this regard in the RDF1.1 spec, 
I accept that.

best regards,
Axel

--
Prof. Dr. Axel Polleres
Institute for Information Business, WU Vienna
url: http://www.polleres.net/  twitter: @AxelPolleres

On 01 Feb 2014, at 07:23, Pat Hayes <phayes@ihmc.us> wrote:

> 
> On Jan 31, 2014, at 1:21 PM, Axel Polleres <axel.polleres@wu.ac.at> wrote:
> 
>> Hi Pat, 
>> 
>> Thanks for your answer, as per my reply to Richard, part a) of my comment was mainly editorial: while I think some more effort with crosslinking  (which I do understand means more group resources) could improve readability and clarity, I can live with the generic reference to Concepts in the beginning of the section.
>> 
>> As per b) please see also my more detailed reply to Richard…
>> 
>>>> As I understand the discussions, the intention here is 
>>>> to simplify things, by assuming that known IRIs *identify* datatypes, i.e. there is a fixed interpretation for such known IRIs,
>>> 
>>> Yes.
>> […]
>>>> Also, I find the remote definition of *identify* in section 4 ("when we wish to refer to such an externally defined naming relationship, we will use the word identify and its cognates.”)
>>>> insufficient to give a proper definition to what a datatype is.
>>> 
>>> Indeed. This notion of identification applies to many kinds of entity and is not restricted to datatypes, so to give such a definition there would not be appropriate.
>> 
>> 
>> … I do understand that “identify" means that a fixed interpretation is assigned
> 
> Yes, but that is not the central point. The key point is that we are relying here on **external Web conventions** to fix the interpretation. Thus, RDF is required to treat the XML Schema datatype IRIs as having the meanings specified by the XML Schema specifications. If you read those specs, they do this by describing the datatypes in some detail, then simply asserting, in English, that the various IRIs identify their corresponding datatypes; and these IRIs are then used all over the Web to refer to those datatypes. What we wanted to say was that RDF simply follows such usage, and indeed is required to do so. 
> 
>> , in this case a fixed "interpretation as a datatype", so, one might just call this out and calling it a (partial) interpretation function from IRIs to datatypes, let’s call it I_datatype()…  (which in the original doc was called datatype map, right?)
>> It is totally fine to have multiple such interpretations for IRIs (as resource, as datatype, as graph…), but why not call them out but use this vague description of “identify” instead?
> 
> I am simply following the usage of TimBL and others, who have been talking about what IRIs (and URIs and URLs etc.) "identify" for over a decade. I needed some way to say "following conventional ideas of being a Web name for something", and this seemed as good a way as any. Of course it is vague and open-ended, but this is exactly the point at which a formal model theory makes contact with the messy social/engineering reality of how IRIS are used on the actual Web. 
> 
>> 
>> What I am trying to say is that I have the feeling that the current spec is here less clear than the old spec. Was this the intention?
> 
> No, but the old style required readers to understand the idea of a "datatype map", which was a completely artificial construct, divorced from Web reality. Nobody has ever implemented or even seriously considered such a map that is not simply the use of Web conventions to assign meanings to IRIs. The fact that the XSD IRIs denote the XSD datatypes is not defined by describing a "datatype map": the XML Schema part 2 specs do not mention that concept. In fact, it is not used anywhere outside the 2004 RDF Semantics document itself. So even if it was clearer (I would dispute this, but even if), it does not relate RDF meaning properly to the actual way that IRIs are used on the Web. 
> 
> Pat
> 
>> 
>> best regards,
>> Axel
>> 
>> --
>> Prof. Dr. Axel Polleres
>> Institute for Information Business, WU Vienna
>> url: http://www.polleres.net/  twitter: @AxelPolleres
>> 
>> On 29 Jan 2014, at 18:48, Pat Hayes <phayes@ihmc.us> wrote:
>> 
>>> Alex, thank you for your comments. Responses are added in-line below. 
>>> 
>>> On Jan 28, 2014, at 1:53 AM, Axel Polleres <axel.polleres@wu.ac.at> wrote:
>>> 
>>>> Dear RDF 1.1 WG,
>>>> 
>>>> First of all let me thank the WG for their efforts and work on gettin the new RDF1.1 spec to PR.
>>>> My new affilation organization (WU Wien) has recently joined W3C and I have started looking 
>>>> in a bit more detail into the new specs.
>>>> 
>>>> When looking over the definition of D-entailment, and also related comments on the list, I have some small question:
>>>> 
>>>> If I see it correctly, and that’s good news, D-entailment is no longer stacked on top of RDFS Entailment. I very much welcome this change.
>>>> Next, I wonder only about one thing regarding the removal of datatype maps. As I understand the discussions, the intention here is 
>>>> to simplify things, by assuming that known IRIs *identify* datatypes, i.e. there is a fixed interpretation for such known IRIs,
>>> 
>>> Yes.
>>> 
>>>> and that this fixed interpretation of a datatype IRI aaa is associated with a known lexical-to-value mapping L2V.
>>> 
>>> The fixed interpretation is assumed to be a datatype, and the datatype has an associated lexical-to-value mapping. 
>>> The lexical-to-value mapping of a datatype D is L2V(D). (That is, L2V is a 'global' map from datatypes to their lexical-to-value mappings.) The argument D here is the actual datatype, not the datatype IRI. So if aaa is a datatype IRI, then it is interpreted to denote a datatype: D = I(aaa), which then has a lexical-to-value mapping L2V(D)  =  L2V(I(aaa)). 
>>> 
>>>> However, Section 7.1 seems to have no pointers to a *definition* of what is a *datatype* or a *lexical-to-value* actually is, nor give any information of how a custom datatype is defined,
>>> 
>>> That is given in Concepts section 5, which is linked from the third paragraph of this section: "RDF literals and datatypes are fully described in Section 5 of [RDF11-CONCEPTS]. "
>>> 
>>>> e.g. 
>>>> 
>>>> "For every other IRI aaa in D, I(aaa) is the datatype identified by aaa, and for every literal "sss"^^aaa, IL("sss"^^aaa) = L2V(I(aaa))(sss)”
>>>> 
>>>> seems to miss that L2V is the associated lexical-to-value mapping for I(aaa).
>>> 
>>> L2V assocates each datatype to its unique lexical-to-value map. In this equation. I(aaa) is the datatype denoted by the datatype IRI; L2V(I(aaa)) is the lexical-to-value map associated with this datatype; L2V(I(aaa))(sss) is the result of applying this lexical-to-value map to the string sss. (This is all unchanged since 2004, except that the basic mapping I here is described as an interpretation rather than as a "datatype map".) 
>>> 
>>>> Also, I find the remote definition of *identify* in section 4 ("when we wish to refer to such an externally defined naming relationship, we will use the word identify and its cognates.”)
>>>> insufficient to give a proper definition to what a datatype is.
>>> 
>>> Indeed. This notion of identification applies to many kinds of entity and is not restricted to datatypes, so to give such a definition there would not be appropriate.
>>> 
>>>> I would kindly ask the group for two things:
>>>> a) to add more explanatory text or pointers to other specs to make these definitions more self-contained.
>>>> b) explain, even if only in an informal section, how custom datatypes should be defined (which several existing RDF datasets do)
>>> 
>>> Please check Section 5 of Concepts and see if this gives the information that you feel is required. (I would add that the definition of RDF datatype has not changed since the RDF 1.0 specification of 2004.) 
>>> 
>>>> If I understand this correctly, such informal addition as well as adding explaining text or references to other specs containing the resp. definitions 
>>>> would not be a substantial change, and not affect PR status.
>>> 
>>> I hope that this reply gives you enough explanation. If you still feel that more explanatory text is necessary, please let me know and I will try to find a way to explain things more intuitively.
>>> 
>>> Pat
>>> 
>>>> best regards,
>>>> Axel
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Prof. Dr. Axel Polleres
>>>> Institute for Information Business, WU Vienna
>>>> url: http://www.polleres.net/  twitter: @AxelPolleres
>>>> 
>>>> 
>>>> 
>>> 
>>> ------------------------------------------------------------
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> ------------------------------------------------------------
> 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 Sunday, 2 February 2014 18:25:49 UTC