W3C home > Mailing lists > Public > public-rdf-wg@w3.org > February 2013

Re: datatype maps in Semantics and Concepts

From: Pat Hayes <phayes@ihmc.us>
Date: Wed, 27 Feb 2013 10:05:38 -0600
Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, RDF WG <public-rdf-wg@w3.org>, Richard Cyganiak <richard@cyganiak.de>
Message-Id: <1FE812D3-58EC-43F4-B312-E59EC6C30D71@ihmc.us>
To: Antoine Zimmermann <antoine.zimmermann@emse.fr>

On Feb 27, 2013, at 3:51 AM, Antoine Zimmermann wrote:

> I am on Peter's side. RDF 1.1 Semantics should say that, if xsd:integer, xsd:dateTime, xsd:etc ... are in the datatype map, then they MUST denote the datatypes defined by XSD 1.1.
> More generally, if a URI is used normatively in a W3C standard as the URI of a datatype, then the datatype map has to map this URI to the corresponding datatype.

I am fine with saying that, although I prefer to state it as condition on interpretations rather than datatype maps. I understood my phrasing to cover that case. Perhaps we are in agreement after all. 

> It does not matter that the datatypes are subject to evolve in later versions. Whenever we require that something conform to a normative reference, we take the risk that applications conforming to a new version of the reference are not conformant with our spec.

But I want such evolution to remain conformant. The entire design of the datatype semantics was intended to allow for such future expansions of the datatype suite in use. RDF should not be normatively restricted to XSD datatypes. 


> AZ
> Le 27/02/2013 06:56, Pat Hayes a écrit :
>> On Feb 26, 2013, at 9:09 PM, Peter F. Patel-Schneider wrote:
>>> On 02/26/2013 06:34 PM, Pat Hayes wrote:
>>>> On Feb 26, 2013, at 7:48 PM, Peter F. Patel-Schneider wrote:
>>>>> If we want to have the standard datatypes fixed to their usual
>>>>> meaning, then why not just say that?
>>>> I think that "the datatype conventionally identified by" an IRI
>>>> does say that. I'm open to a change of phrasing if you prefer
>>>> something different. Suggestions?
>>> We can't just say conventionally identified in a normative part of
>>> our documents.   We can say "If you use xsd;string, ... then you
>>> must use them as defined in Concepts or in XSD Datataypes", and
>>> normatively point to the appropriate documents.  However, what
>>> document are you going to point to for the convention?
>> I can't point to documents that havnt been written yet. And in any
>> case, there might not be a document. It is perfectly fine for some
>> people to invent and use a new datatype in their RDF without it being
>> normatively sanctioned by any RDF specification.
>>>>> The current document talks about "the datatype conventionally
>>>>> identified by aaa".  What does this end up meaning?  How are
>>>>> new datatypes set up?  How does "recognition" interact with
>>>>> "conventional indentification"? This just seems like magic to
>>>>> me.
>>>> Its how the Web works. People define datatypes and assign them a
>>>> URI, and then other people use that URI to refer to the datatype.
>>>> How did http://www.w3.org/1999/02/22-rdf-syntax-ns#PlainLiteral
>>>> get to refer to the datatype we all know and love,
>>> It got to be so because a buch of people got together and fought
>>> over it.  It got to be so so because they convinced W3C to put out
>>> a REC.
>> Thats how it got to be a W3C REC, but there's no requirement that all
>> datatypes used in RDF have to be approved by the W3C.
>>> RDF 1.1 can now use rdf:PlainLiteral by normatively pointing to
>>> that document.  RDF systems and applications can say that they
>>> implement rdf:PlainLiteral by saying that their datatype map
>>> includes the mapping for rdf:PlainLiteral from that document.  They
>>> could, if they wanted, say that they implement a different datatype
>>> with name rdf:PlainLiteral.  I wouldn't recommend it, but they
>>> could.
>>> Appealing to an undefined convention is much worse.  Whose
>>> convention?  I could just make up a convention on the spot!  OK,
>>> here's one:  an XS datatype IRI conventionally indentifies the next
>>> datatype  in XSD 1.0, but interpreted as in XSD 1.1.  What in the
>>> current Semantics document is the convention violating?
>> It isn't. But I can also define a similarly crazy datatype mapping
>> and call it D, and the 2004 semantics will apply to it. The RDF
>> semantics approach to datatypes has always taken the stance that the
>> association between IRIs and datatypes is somehow defined externally
>> to RDF, and RDF will work with whatever such conventions are being
>> used. Nothing in that is being changed here.
>>> From now a system conforms to the current Semantics if it uses this
>>> convention, even without mentioning it.
>>> Yes, yes, I know this is being really stupid, but that's the point.
>>> Our documents have to rule out *this* kind of stupidity (as opposed
>>> to the stupidity of building a system that does the above but says
>>> so in its documentation).
>>>> the Edsel of the datatype world? It does so because
>>>> http://www.w3.org/TR/rdf-plain-literal/ says it does. It does
>>>> *not* do so because the pair
>>>> <"http://www.w3.org/1999/02/22-rdf-syntax-ns#PlainLiteral", [the
>>>> datatype described in http://www.w3.org/TR/rdf-plain-literal/] >
>>>> is in some datatype map.
>>> Well, in RDF 1.0 this is definitely the way for systems and
>>> applications to go.
>> But they don't. What they do is, they use whatever conventions are
>> currently in use to associate IRIs used to name datatypes, with the
>> datatypes they name. People simply refer to datatypes by using the
>> URI. We do it ourselves in our emails and discussions. We just say
>> "xsd:number", we don't spell out how to identify the datatype named
>> by this IRI. And I don't think the RDF specs should even pretend to
>> legislate how this IRI naming process is done. All that matters for
>> us is to specify which datatypes are being treated as 'real' in a
>> particular application of entailment, and we do this by mentioning
>> the IRI of the datatype, just like everyone else does.
>>>> In any case, how is a new datatype set up in the current
>>>> D-semantics? This is just as mysterious and magical.
>>> Not at all.  Appplications and systems say what their datatype map
>>> is.
>> That isn't required by the 2004 specs; and in any case, they don't.
>>> (Yes, yes, lots of them don't say so so explicitly, but that is the
>>> mechanism.)
>>>> At least the new way of stating admits that it is just using the
>>>> normal conventions of the Web to determine what datatype IRIs
>>>> denote, instead of confusing things with some impressive-looking
>>>> but essentially meaningless pseudo-mathematics.
>>> But what are the normal conventions?
>> Whatever mechanisms the user community wants to use and tends to find
>> useful, to discover what an IRI refers to. What these actually *are*
>> is not our problem, fortunately.
>>> Where is the W3C REC (or equivalent) that these conventions are
>>> written in?
>> Who cares? Presumably, users will either know this, or it will be
>> possible to get to it from the base IRI of the datatype. If they
>> don't, or can't, then they will have to treat it as an unknown
>> datatype and will not be able to make some inferences that they could
>> make if they were better informed. Well, duh.
>>>> BTW, for more on this, see this exchange between Richard and
>>>> Antoine (which I only just discovered):
>>>> (from
>>>> http://answers.semanticweb.com/questions/9781/regarding-plain-literal-and-rdfplainliteral-equality
>>>> )
>>>> ===
>>>> The semantics of "foo" and "foo"^^xs:string is the same only if
>>>> you assume a datatype map which maps xsd:string to the
>>>> corresponding XML Schema datatype. In any other situation,
>>>> nothing mandates these two things to be the same (i.e., to have
>>>> the same interpretation). In particular, the RDF and RDFS
>>>> semantics do not mandate that (though it's likely to change in
>>>> RDF 1.1, yes). (23 May '11, 08:37)Antoine Zimm... ♦
>>>> You pedant! That's true of course, but I submit that talking
>>>> about the value of a typed literal obviously assumes that the
>>>> datatype is in the datatype map, and mapping xsd:string to
>>>> anything but XSD's string type would be nuts. (23 May '11,
>>>> 09:05)cygri ♦
>>>> You're right, it would be nuts! Yet it is allowed in RDF 2004,
>>>> hopefully not in RDF 2013. (23 May '11, 12:02)Antoine Zimm... ♦
>>>> ===
>>> RDF 1.1 can simply say that any datatype map must conform to [some
>>> mixture of Concepts and XSD and whatever].
>> But all this amounts to, is saying that interpretations must have the
>> datatype IRI denoting the datatype specified in Concepts and XSD and
>> whatever. It is a constraint on interpretations. The "datatype map"
>> does not need to be called out as a special construction, as it is
>> part of the interpretation: it is a mapping from IRIs to what they
>> are required to denote.
>> So, suppose a new document gets written which replaces XSD and
>> becomes more widely adopted, and everyone wants to use those new
>> datatypes instead of the XSD datatypes in their RDF. Is this illegal,
>> on your view? Would it require RDF 1.1 to be replaced by RDF 1.15,
>> composed by a new WG, which changes the normative list of approved
>> datatypes? This is completely pointless. The RDF model works with any
>> datatypes which fit the RDF model, including those that havn't been
>> defined yet. We don't even know how they will be defined, not does it
>> matter. All we need is that they will be, somehow, and that they will
>> have an IRI assigned to them, using some mechanism or convention that
>> is accepted by Web users as a way to name things using IRIs.
>>> In fact, I would be happy saying that RDF-entailment includes
>>> xsd:string and several other datatypes.  (Which Semantics says is
>>> the case, but needs to be accepted by the WG, if there is not
>>> already a resolution so saying.)
>> I was simply following Concepts here.
>> Pat
>>>> Pat
>>> peter
>> ------------------------------------------------------------ IHMC
>> (850)434 8903 or (650)494 3973 40 South Alcaniz St.
>> (850)202 4416   office Pensacola                            (850)202
>> 4440   fax FL 32502                              (850)291 0667
>> mobile phayesAT-SIGNihmc.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/

IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Wednesday, 27 February 2013 16:06:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:54 GMT