Re: datatype maps in Semantics and Concepts

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

Received on Wednesday, 27 February 2013 05:57:19 UTC