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

Re: datatypes

From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
Date: Wed, 19 Jun 2013 18:43:17 +0200
Message-ID: <51C1DFA5.40102@emse.fr>
To: public-rdf-wg@w3.org, Pat Hayes <phayes@ihmc.us>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>

I've just seen the changes in RDF 1.1 Semantics regarding "Semantic 
conditions for datatyped lietrals".
I'm sorry I did not noticed this last edit, being too occupied with the 
The situation is definitely better, even perhaps good enough (the 
semantic conditions actually say now that the IRI must denote the 
datatype, which is basically all I want).

I'll read it through again later but at first sight, I find the current 
state potentially satisfying.

Sorry for the heated discussion.


Le 19/06/2013 05:45, Peter F. Patel-Schneider a écrit :
> The whole point of the message is to describe the situation in 2004 and
> to point out the difference between them in a way that hopefully makes
> it clear that nothing has really changed.
> But let me put it bluntly,
> Slightly less bluntly,
> Datatype maps didn't get you anything.  They looked as if they provided
> an extra level of formality, but all that they did was require an extra
> level of magic.  Sure, this extra level of magic was generally benign,
> and invisible from users, but it certainly didn't match up with the way
> datatypes are defined in XML Schema datatypes the source of most of the
> usable RDF datatypes.
> peter
> On 06/18/2013 09:35 AM, Antoine Zimmermann wrote:
>> Short answer: there is no argument in this answer. It simply describes
>> the situation in 2004 and the situation in 2013. I stick to my objection.
>> In 2004: given a mapping D, I had a fully specified entailment regime.
>> In June 2013: given a D, I have a whole family of entailment regimes,
>> but if I am provided with the mapping from IRIs in D to datatypes, I
>> can find out to what D-entailment I'm referred to. To make sure that
>> we're always given the complete entailment regiems, we add some text
>> outside the formal definition to the effect that the mapping MUST be
>> given or known. This is supposed to be understood as if there was a
>> formal constraint on the interpretation of the recognised IRIs.
>> Not only the new design formally imposes to provide the mapping (so
>> why not give it a name and call it D) but it makes it a bit
>> convoluted. I don't see how this can possibly clarify anything. But in
>> addition, it amounts to no actual change in either implementation or
>> formal results. So, if it does not change anything, why the change?
>> It's changing for the sake of changing.
>> Why are you struggling so fiercefully to NOT use datatype map? You
>> don't have any evidence of any problem related to this. All
>> modifications, if they change the normative definitions, should come
>> with a clear indication that the change is required and/or beneficial.
>> In your response hereafter, you do not provide any argument: you
>> simply describe the two situations. I know the situation.
>> Le 15/06/2013 20:05, Peter F. Patel-Schneider a écrit :
>>> Here is my reply on the datatypes portion of the thread.  I have
>>> deliberately not included any of the previous discussion.
>>> To have a datatype in 2004 you said:
>>> I'm doing D-entailment where D = {<foo:bar>,A} and A is my datatype
>>> with lexical space, value space, and L2V map.
>>> Now you say
>>> I'm doing D-entailment where D = {foo:bar} and foo:bar is my datatype
>>> with lexical space, value space, and L2V map.
>>> That's the entire change, modulo that for certain IRIs the datatype
>>> is fixed by the RDF spec and now doesn't even have to be mentioned.
>>> peter
>>> PS:  Well, except that I think that the semantic conditions for
>>> D-intepretations have to be strengthened to say that an IRI in D has
>>> to denote the datatype that it identifies.  I don't believe that I
>>> have seen a response on this point.
>> That's what happens when one tries to fix something that is not
>> broken. You introduce problems and troubles. There was a clear, clean,
>> straightforward solution that would have led us to Last Call much
>> faster: to not change D beyond requiring that normative XSD, RDF and
>> OWL datatypes must be interpreted as they should be.
>> I will make a concrete proposal indicating the kind of text I would
>> like to see.

Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
Received on Wednesday, 19 June 2013 16:43:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:14 UTC