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

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?

>
>
> [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 ?

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

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.

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

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.

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 May 2009 17:37:47 UTC