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

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 Saturday, 1 February 2014 06:23:30 UTC