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

Hey, look, if nobody else is bothered by these issues, then I'll just  
shut up and live with whatever gets written. I'm sure the world in  
general will find a way to live with it. But I predict that there will  
be problems and confusions. Just don't say I didn't warn y'all.

Pat

-----------

On May 27, 2009, at 3:05 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 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
>
>
>

------------------------------------------------------------
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 May 2009 21:02:01 UTC