Re: what is a plain literal?

Hi, Garret!

Garret Wilson wrote:
> P.S. Yes, were I to propose changes to RDF, I would propose adding a 
> language tag to typed literals of datatype xsd:string; and doing away 
> with plain literals.

I once had the same idea, and here is what I learned:

The answer is that language tags for typed literals do not make much 
sense, because they would only be useful for /strings/, not for other 
types like numbers, booleans, or even custom types. One could counter 
that then, there should only be language tags for xsd:string, and not 
for any other type. Note, however, that from the RDF perspective, there 
is nothing special about xsd:string. RDF does not know at all that the 
typed literal "xxx"^^xsd:string is meant to be a string. The only things 
RDF knows about this literal are that

     * the whole expression actually /is/ some typed literal (RDF knows 
this because the expression has the format "..."^^<URI>)

     * the URI 'xsd:string' denotes some type (but RDF does not know 
which type),

     * and that the string "xxx" is (hopefully) a unique representation 
for a datavalue of this type.

Concrete types, even the xsd types, are outside the specification of 
RDF. This means, that a language tag, which exists for strings only, 
cannot be defined within RDF in a meaningful way.

Please check my argumentation against the spec in

     http://www.w3.org/TR/rdf-primer/#typedliterals


Garret Wilson wrote:
 > Next question: how do plain literals differ semantically from typed
 > literals with a datatype URI of xsd:string? Yes, I know that they are
 > "different" in the URI abstract syntax, but that's begging the
 > question---what does that *mean*.

I think I can see a semantical difference between plain and typed 
literals, though it is a subtle one.

First, let me explain it for non-string literals, because the difference 
is easier to see there. Consider the plain literal "42" and the typed 
literal "42"^^xsd:integer. The plain literal denotes itself, i.e. it 
denotes the string "42". The typed literal instead denotes the number 
42. If the semantics of typed literals would also demand to denote 
themself, what would this mean? Not perfectly clear on this, but at 
least the following seems correct in my eyes: The typed literal above 
consists of at least two informations:

     * the string "42"

     * the type INTEGER, denoted by xsd:integer

So, if "42"^^xsd:integer would denote itself, it's interpretation would 
at least have to somehow (how?) contain these two informations. This is 
obviously NOT the case.

I now carry these considerations over to the case of typed /string/ 
literals: Suppose that the typed literal "xxx"^^xsd:string would denote 
itself. Than the interpretation of this typed literal would at least 
have to consist of two informations: The string "xxx" AND the type 
information (it is a STRING). But the typed literal actually denotes 
/only/ the string "xxx".

What does this mean? I would say that the semantics of plain literals 
and typed string literals are /different/: The semantics for plain 
literals are given by the semantic interpretation function I_plain(.), 
which maps each plain literal (seen as a syntactic expression) to the 
string expressed by this plain literal (which happens to be itself). On 
the other hand, the semantics for typed string literals are given by the 
semantic interpretation function I_typed(.), which maps each typed 
string literal (again, seen as a syntactic expression) to the string, 
which builds the left hand side of the complete typed literal. We see: 
While the interpretation function I_plain(.) equals the identity 
function restricted to the set of all strings, the interpretation 
function I_typed(.) is NOT the identity function for this set; in fact, 
the domains of I_plain(.) and I_typed(.) even happen to be disjoint. So, 
the interpretation functions for plain literals and typed string 
literals are different. Thus, their semantics are different.


Cheers,
Michael

Received on Friday, 10 August 2007 19:58:09 UTC