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

Patrick,

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

I think you're misunderstanding my point, which is certainly *not* about 
doing untidy implicit datatyping.  We've done that one to death 
already.  Note that my test cases were about *satisfiability*, not 
*entailment*.

I'm also not asking the RDF core to say whether or not a plain literal is 
in xsd:string.  I'm just asking that the definitions be sufficiently clear 
and based in common underpinnings so that given the definitions of a plain 
literal and xsd:string, we can answer the question.  Application designers 
need to know the consequences when they use a combination of specifications 
together, and I think it's our job to ensure that their questions can be 
answered.

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

I realize that now, so this is no longer an issue for Art's work.  But I 
still think it's a question that should have a clear answer when the RDF 
and XML schema specs are consulted in combination.

#g
--

At 11:50 AM 1/16/03 +0200, Patrick.Stickler@nokia.com wrote:


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

-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Thursday, 16 January 2003 07:28:52 UTC