RE: Literals: language and xml (was: Comments on new datatyping document, part 1)

> > My view is that the abstract syntax will say something like:
> >
> > A Literal Node is labelled with one of:
> > (a) - A datatype value
>
> It cannot be labeled by a datatype value. It can only be
> labeled with a URIref denoting the datatype and a lexical
> form -- which together denote a datatype value.
>
> URIref nodes are not labeled with the resources they
> denote, neither are typed literal nodes.
>
> There are no native datatype values in the RDF graph,
> only labeled nodes which denote datatype values.
>
> Perhaps we are in agreement on this,

No, I don't think we are.
The abstract syntax is not a serialization.
It is quite possible to use integers in it.
My understanding is that the node you would label with
<xsd:int>"10" is in fact labelled with the integer 10.

> and it's just a matter
> of getting the wording right (though I think you are suggesting
> something different).
>
> > (b) - An rdf string literal
>
> It may be useful to say "a non-explicitly typed string literal".
>
> > (c) - An rdf xml literal
>
> I would rephrase the above list as
>
> (a) an explicitly typed string literal    (<xsd:string>, "xyz")
> (b) a non-explicitly typed string literal (_:a, "xyz")

This presupposes that it is waiting to be typed.

> (c) an XML literal                        (xml"xyz")
>
> and if XML literals can be typed (and I don't see
> why they couldn't):

That is a Part II issue.

> >
> > (Label is <xsd:string>"val")
>
> OK.

Perhaps I should be more explicit.
The label is the Unicode string "val" understood as a member of the
xsd:string value space.


>
> (d)
> <rdf:Description>
>    <eg:prop rdf:datatype="&ex;someComplexType"
> rdf:parseType="Literal">val</eg:prop>
> </rdf:Description>
>
> (Label is <ex:someComplexType>xml"val")

Part II

>
> >
> > Adding an xml:lang we get:
> > (a)
> > <rdf:Description xml:lang="en">
> >   <eg:prop rdf:datatype="&xsd;string">val<eg:prop>
> > </rdf:Description>
> >
> > (Label is "val"
> > It has to be an xsd:string, and so the language tag must be lost)
>
> No. If the primary mechanism for specifying language for literal
> content is xml:lang, then that information must not be lost from
> the literal node.
>
> The label here should be <xsd:string>"val"-en


No. My understanding is that on a datatyped literal the label is taken from
the value space of the datatype. The value space of xsd:string is Unicode
strings; thus <xsd:string>"val"-en is not in that value space.

>
> We *have* to have a mechanism for attributing language qualification
> to literals.

We have. XML Schema datatypes does not provide a mechanism for using lang
codes with datatype values and explicit suggest using xml which we support.
I have earlier sent the references.

>
> Since literals can't be subjects, I see no other mechanism than
> to attach it to the literal node label itself, as was decided
> at the Bristol f2f.
>
> Here, just because there is a datatype specified, does not
> mean the language is not considered valid. I may wish to
> say *both* that the property value is a string, *and* that
> the string contains e.g. Finnish content.
>
> No, the semantics of xsd:string does not care about the language
> qualification and the xml:lang value does not affect the L2V
> mapping, but applications will likely want to have that information.
>
> > (b)
> >
> > <rdf:Description xml:lang="en">
> >   <eg:prop>val<eg:prop>
> > </rdf:Description>
> >
> > Label is "val"-en
>
> Or rather _:x"val"-en
>
> > (c)
> > <rdf:Description xml:lang="en">
> >   <eg:prop rdf:parseType="Literal">val<eg:prop>
> > </rdf:Description>
> >
> > Label is xml"val"-en
>
> OK.
>
> > The only choice is whether we allow:
> >
> > <rdf:Description xml:lang="en">
> >   <eg:prop rdf:parseType="Literal"
> rdf:datatype="&xsd;string>val<eg:prop>
> > </rdf:Description>
>
> In which case, we'd have
>
>    <xsd:string>xml"val"-en
>
> Fine.

No, it's not. xml"val"-en is not a string.

I think we probably need to move to test cases.

Jeremy

Received on Wednesday, 11 September 2002 07:33:03 UTC