Re: proposed changes to the rdf:text document for option 5

From: Pat Hayes <phayes@ihmc.us>
Subject: Re: proposed changes to the rdf:text document for option 5
Date: Wed, 27 May 2009 14:48:38 -0500

> 
> On May 27, 2009, at 2:08 PM, Peter F.Patel-Schneider wrote:
> 
>> From: Pat Hayes <phayes@ihmc.us>
>> Subject: Re: proposed changes to the rdf:text document for option 5
>> Date: Wed, 27 May 2009 12:36:35 -0500
>>
>>>
>>> On May 27, 2009, at 10:26 AM, Peter F.Patel-Schneider wrote:
>>>
>>>>
>>>> [Suggested change to Abstract - yes this is not part of option 5]
>>>>
>>>> This document presents the specification of a datatype for plain
>>>> literals in RDF.
>>>>
>>>>
>>>> [Changes to two last paragraphs of Section 1]
>>>>
>>>> To address these deficiencies, this specification introduces a
>>>> datatype
>>>> called rdf:text, which uses the rdf: prefix because it refers to  
>>>> parts
>>>> of the conceptual model of RDF.  This extension, however, does not
>>>> change the conceptual model of RDF, and thus does not affect the
>>>> specifications that depend on the conceptual model of RDF such as
>>>> SPARQL.  The value space of rdf:text consists of all data values
>>>> assigned to RDF plain literals, which allows RDF applications to
>>>> explicitly refer to this set (e.g., in rdfs:range assertions).
>>>>
>>>> Because RDF plain literals are already a part of RDF and SPARQL
>>>> syntaxes, rdf:text literals are always written as RDF plain literals
>>>> in
>>>> RDF and SPARQL syntaxes.
>>>
>>> So, can someone take existing RDF graphs and think of all the 'old'
>>> plain literals in them as being rdf:text typed? Or does it only apply
>>> to new ones that get *written* after this spec is past LC?
>>
>> Well, the 'old' plain literals are "still" just plain literals.  They
>> do not become typed literals.
> 
> Well, but this is now ambiguous. They are not RDF typed literal  
> syntax, obviously: but what this wording seems to say is, that they  
> are in fact semantically typed literals. The entailment rules for  
> datatyped entailments apply to them. So suppose I take some existing  
> RDF with plain literals in it, say
> 
> aaa ppp "abc" .
> 
> does it now entail
> 
> aaa ppp _:x .
> _:x rdf:type rdf:text .
> 
> ? Note, it did not entail this previously, with either RDF entailment  
> or D-entailment. Or would this entailment only be valid with newly  
> written RDF? 

I don't see that the date of writing makes any difference.

> Or only under {rdf:text}-entailment? Or what?

What!  My view would be {rdf:text}-entailment, for now, which doesn't
require changes to the RDF semantics.  Other people may have different
views.


>>>> [Change to entirely of Section 4
>>>> - the last paragraph might need some tweaking]
>>>>
>>>> 4 Syntax for rdf:text literals
>>>>
>>>> It is obvious from the above that the value space of rdf:text  
>>>> contains
>>>> exactly all data values assigned to RDF plain literals (with or
>>>> without a
>>>> language tag).  The rdf:text datatype thus provides an
>>>> explicit way of referring to this set.
>>>>
>>>> To eliminate another source of syntactic redundancy, the form of
>>>> rdf:text literals in syntaxes for RDF graphs and SPARQL basic graph
>>>> patterns is the already existing syntax for the corresponding plain
>>>> RDF
>>>> literal, and not the syntax for a typed RDF literal.
>>>
>>> Um... but wait. XSD requires that datatypes apply to strings (Boris'
>>> point). What is "the" string (to which the L2V mapping applies) for
>>> the plain literal "abc"@eng ?
>>
>> First of all, RDF datatypes are not necessarily XSD datatypes.
> 
> Right, but (again, Boris' point) OWL 2 datatypes are, or at least will  
> all conform (?) to the XSD datatype model, or some such phrasing.

At least one OWL 2 datatype does not meet the requirements to be an XS
datatype.  (I think.)  

All OWL 2 datatype meet the requirements for being an RDF datatype (at
least the ones from RDF concepts, that is).

>> However, the answer to this question is in Section 3.  For the  
>> "abc"@eng
>> plain literal the rdf:text lexical form is "abc@eng";  for "abc" it
>> would be "abc@".
> 
> OK.... hmm...  but your text seems to say that this *isn't* the string  
> in the literal.

If it seems to say that then it needs some wordsmithing.

>> Note that the proposal wording above is *very* careful not to say
>> typed literals.
> 
> Well, yes, but it refers to "rdf:text literals". Very few readers, I  
> suspect, are going to understand this as not meaning something of the  
> form "abc@tag"^^rdf:text. I certainly read it that way. In fact, I now  
> see that, when read with philosophical care, it actually defines a  
> whole new kind of RDF literal, one that is syntactically just like an  
> RDF plain literal but semantically just like an RDF typed literal.  

Well, yes, but precisely for the datatype where this shouldn't be
noticeable.

> Very ingenious, but I predict will give rise to endless  
> misunderstandings unless it is spelt out more carefully in plainer  
> language. So, for example, I'm still unsure whether an existing RDF  
> plain literal is one of these or not.

Is.  :-)

>>>> Therefore, typed
>>>> literals with rdf:text as the datatype do not not occur syntaxes for
>>>> RDF
>>>> graphs, nor in syntaxes for SPARQL basic graph patterns.
>>>>
>>>> As a consequence of the above, applications that employ the rdf:text
>>>> datatype *MUST* use plain RDF literals when they transfer RDF graphs
>>>> (because there is no other way to write typed literals with datatype
>>>> rdf:text) and will retain a large degree of interoperability with
>>>> applications that do not understand the rdf:text datatype.
>>>
>>>  This would be great if it worked, but I don't see how it possibly  
>>> can.
>>>
>>> Let me raise the issue that was bothering me and which led to the
>>> 'semantic extension' version of this (because they are essentially  
>>> the
>>> same notion, with different wording.)
>>>
>>> Suppose someone reads this document and thinks: that datatype is a
>>> neat idea, that will be very useful in my proposed Web 2.0
>>> international intimate services application. But this RDF tool Ive
>>> been using and which I paid good money for and my guys know how to
>>> use, doesn't know how to connect it to the plain literal syntax.  
>>> Damn.
>>> But not to worry, I will just use it as a normal RDF datatype. After
>>> all, there's nothing in the RDF spec that says I can't, and I only
>>> have to conform to RDF. So I'm happy.  And then this guy's app
>>> generates millions of marked-up web pages (using RDFa) which are
>>> covered with literals using this datatype explicitly, which is  
>>> exactly
>>> what we want to avoid. But what has he done wrong? He hasn't *said*  
>>> he
>>> is conforming to this Rec., only to the RDF specs; and indeed, he  
>>> *is*
>>> conforming to them. So he is being perfectly legal and well-behaved,
>>> according to the published W3C specs.
>>
>> Right now nothing prevents this.  However, as soon as this document  
>> hits
>> REC status he is no longer up to date.
> 
> But is he *wrong* ?

Wrong. 

>>  This view of rdf:text changes
>> the syntaxes for RDF, and that seems to be what people want.
> 
> So all current RDF changes in meaning as soon as this is published? I  
> think there will be rioting in the streets. At the very least, this  
> REC ought to say openly in its abstract and its title that it is a  
> *change* to RDF.

Well, not *all* current RDF.   Just current RDF that uses rdf:text.

>>> I don't think this can be answered by saying that if you use the
>>> datatype at all, then you have to obey the MUSTs in the spec that
>>> defines it. This hypothetical guy is considering the spec of the
>>> datatype to be what it says it is, viz. a description of a datatype.
>>> And the RDF specs tell him what a datatype description consists of,
>>> and it makes no reference to re-interpreting the RDF plain literal
>>> syntax: in fact, it explicitly requires the use of the RDF typed
>>> literal syntax, and does not say anything about semantic changes to
>>> any other part of RDF. So, he can legitimately claim (and indeed may
>>> have honestly come to this conclusion) that asking him to treat RDF
>>> plain literals "as though" they are typed with a datatype is actually
>>> in violation of the RDF specs, and so he can't do that and still call
>>> himself RDF conformant.
>>
>> This proposal does not say that plain RDF literals are supposed to  
>> be typed
>> with a datatype.  I wrote it very carefully not to say that.  (Yes  
>> this
>> is a bit of sophistry, but the details of syntax often have more  
>> than a
>> bit of sophistry in them.)
> 
> Seems to me that is exactly what it says, without saying it directly.

Nope.

>>> Here's another scenario, though I admit further fetched. A publishes
>>> some RDF and B treats it using this convention, and A objects that
>>> *his* plain literals are *not* typed with rdf: text. He wants to
>>> distinguish really plain plain literals from typed plain literals
>>> which look exactly the same but were written by a tool which uses  
>>> this
>>> convention (and he sends an email to w3c:semanticWeb asking how to do
>>> this...)
>>
>> Again, this proposal does nothing to the status of plain RDF literals.
>> They remain plain RDF literals.  They do not become typed literals.
> 
> OK, so the RDF entailment I gave above is NOT valid, is that right?  
> How does anyone know when it is and when it isn't?

Well, it becomes more and more valid as the document gets closer and
close to REC status, in some strange regulatory sense, but this is all
due to the magic of standards, after all.

It's much like how RDF entailments came and went as the RDF semantics
document changed, and just like datatyped RDF entailments continue to
change depending on the various views of the particular datatypes in
question.   Similar effects are happening as XML Schema 1.1 gets closer
and closer to REC status.

>> All this proposal says that "From REC on, you don't use rdf:text typed
>> literals in RDF syntax to write down rdf:text values".
>>
>>> See the problem?  What we are trying to do here is a change to RDF.  
>>> It
>>> really is. It is not just a definition of a new datatype.  It changes
>>> the conceptual model of RDF and the semantics of RDF, in both cases
>>> making an alteration, small but real, to what the RDF specs  
>>> themselves
>>> say. And a definition of a datatype just does not have the moxie to
>>> make such a change to an existing specification.
>>
>>> I think we need to face up to this, and not try to pretend that we
>>> aren't doing what we in fact are trying to do.
>>
>> I was very careful not to change the RDF semantics, just the RDF  
>> syntax!
> 
> But in fact I think it does, slightly but visibly. See above.

It is true that this is defining the semantics of a particular datatype,
so yes, in that sense, I guess.  If that particular datatype gets pushed
further down the stack then the changes become somehow different in
kind, but *I'm* not going there.

> Pat
> 
>> I'm not claiming that this is not a change to the RDF syntax.

peter

Received on Wednesday, 27 May 2009 20:06:41 UTC