- From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
- Date: Wed, 27 Feb 2013 18:23:04 +0100
- To: public-rdf-wg@w3.org
Le 27/02/2013 17:05, Pat Hayes a écrit : > > 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. But you can't preestablish conformance with future documents that are not written yet, unless you use vague terms like "Web conventions" that in the end don't really enforce anything. We should refer to XSD 1.1, even if that means there will be an edited recommendation to support XSD 2.0, another for XSD 3.0, etc. In any case, the W3C takes backward compatibility very seriously, so even if a new version of XSD comes, all the XSD 1.1 types will liekly be identical in 2.0. AZ > > Pat > >> >> >> >> 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 > > > > > > > -- 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, 27 February 2013 17:23:38 UTC