RE: Type of (the denotation of) a plain literal

> -----Original Message-----
> From: ext Graham Klyne [mailto:GK@NineByNine.org]
> Sent: 15 January, 2003 20:42
> To: RDF core WG
> Subject: Type of (the denotation of) a plain literal
> 
> 
> 
> I'm trying to answer a question that's come up in the CC/PP 
> working group.
> 
> Can a plain literal be regarded as an instance of xsd:string?

Whether it is or not, it should not be stated in the 
RDF specs, as that creates an unnecessary dependency
upon the XML Schema specs (who knows, the definition
of xsd:string could change in some subtle way that would
impact the RDF specs).

In conjunction with the Note or whatever document that
has already been discussed regarding issues arising
from an RDF Datatyping interpretation/use of XML Schema
datatypes, this could also be addressed, and if agreed
that applications can safely equate plain literals sans
language tag as an xsd:string, fine, but we should not
address it now in the LCC docs.

That said...

> I think it's fairly clear that a plain literal with a 
> language tag is not 
> an xsd:string,

Agreed.

> but less so in the case of a plain literal without a 
> language tag.
> 
> Here are my test cases:
> 
> (1)  Is the following satisfiable?
> 
>     ex:prop rdfs:range xsd:string .
>     ex:subj ex:prop "abc" .

No. An rdfs:range assertion specifying a datatype "excludes"
all plain literal values, because the semantics of those
plain literals is fixed and there is no implicit datatyping
in RDF.

I would *LOVE* if the above entailed

      ex:subj ex:prop "abc"^^xsd:string .

but it doesn't, and can't.

> (2)  Is the following satisfiable?
> 
>     ex:prop rdfs:range xsd:string .
>     ex:subj ex:prop "abc"@en .

No. But for the same reasons as above, in addition to
the semantic significance of the language tag.

> My answers are:
> 
> (1) I'm not sure, but I lean toward "no" on the current wording.
> ...
> (2) No (because the two-component value ("abc","en") is not a 
> value in 
> xsd:string -- i.e. is not a finite sequence of characters.

Right. I think we are generally in agreement on this.

> In summary, I think the combination of abstract syntax and 
> formal semantics 
> needs tightening up here:  either (a) the abstract syntax 
> should be more 
> precise about what it is that contains three components, or 
> (b) the formal 
> semantics should be more explicit about how the components 
> relate to what 
> is denoted by a literal.
> 
> This may all seem rather arcane, but there's a real issue here:  Art 
> Barstow has a proposal for UAProf/CCPP in which xsd:string is 
> used as the 
> range of an property.  Could the value of this property 
> possibly be a plain 
> literal?

I've talked at length with Art about the impact of datatyping on
UAProf, and the bottom line is that (a) all values should be
datatyped, (b) all properties should have datatatype ranges.

What you're really asking is "can we do untidy, implicit datatyping"
and the answer is a big loud NO (regretably).

While I'm not making lots of noise now about this, I expect that
we'll hear some when we publish the LCC specs... After all, the
whole rest of the world does property/frame based implicit typing
of values. That we don't provide for that is pretty odd (to say
it *very* politely ;-)

Cheers,

Patrick

Received on Thursday, 16 January 2003 04:50:31 UTC