- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Wed, 11 Sep 2002 13:32:31 +0200
- To: "Patrick Stickler" <patrick.stickler@nokia.com>, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>, "Graham Klyne" <GK@NineByNine.org>
- Cc: "RDF core WG" <w3c-rdfcore-wg@w3.org>
> > 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