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

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.

It should't, obviously, but one could read that line about "always  
written" as applying only to RDF written after publication of this REC.

>
>> 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.

I guess that still lets SPARQL work properly, provided nobody asks it  
to do something clever with rdf:text. OK.  But then I think the  
document should actually say this explicitly, ie that this entailment  
is valid only under datatype entailment. Just to forestall any  
possible misunderstandings.

>  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.

But it will be, since it is fine to use rdf:text in RDF just as a URI,  
without typing a literal with it. We have agreed to allow that, and I  
don't think we can possibly stop people doing it, its just too useful.

>
>> 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.  :-)

OK, then lets say so explicitly.

>
>>>>> 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.

Hmm, so the RDF spec changed under his feet, right? I don't like this.  
This really *is* changing all extant RDF.

>
>>> 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.

The above entailment hasn't got that URI in its antecedent, is the  
point. But I see, that if it only applies under rdf:text-entailment,  
then that is 'using' it in a sense. Just not syntactically.

>
>>>> 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.

How so? It says that RDF plain literal syntax is the RDF surface form  
of an RDF datatyped literal. That makes them into typed literals in  
all but syntax, surely.

>
>>>> 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.

Yes, I understand, but what this ignores is the fact that there  
already is a REC standard in place for RDF. Can one REC modify  
another, previous, one? Not in the sense that OWL extends RDF, but  
actually changing the content of the old REC so that it no longer  
applies? I thought this wasn't kosher. Surely this is worse than  
having uncool URIs.

>
> 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.

Why am I reminded of a Warner Brothers road runner cartoon at this  
point?

Pat

>
>> 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 20:59:56 UTC