W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > August 2002

RE: Alternative representation of typed literal nodes in NTriples (and N3)

From: <Patrick.Stickler@nokia.com>
Date: Thu, 22 Aug 2002 23:04:37 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B5FBA9E@trebe006.europe.nokia.com>
To: <Patrick.Stickler@nokia.com>, <w3c-rdfcore-wg@w3.org>

>    untyped non-XML literal  _:a,"25"

Oh, and in case it wasn't clear ;-) that local name does
in fact denote "some" datatype.

I.e., an untyped literal denotes a datatype value
that has that particular lexical representation, only we 
don't know from the literal node itself which datatype is

Given global datatyping, via rdfs:range, the
particular datatype may be determined.

Thus, one could say


   ?p rdfs:range ?d .
   ?d rdf:type rdfs:Datatype .
   ?s ?p _:a,"LLL" .


   _:a daml:equivalentTo ?d .

Interestingly, even if the datatype is not a local
name, but a URIref, the above rule still is usable,
and datatype clashes can be treated as invalid
equivalence assertions for incompatable datatypes.

Thus the inference

    ?p rdfs:range xsd:integer .
    ?s ?p xsd:string,"LLL" .
   xsd:string daml:equivalentTo xsd:integer .

is a valid inference, per the semantics of rdfs:range,
but reflects a datatype clash between the global and
local datatypes, since xsd:integer is in fact not
equivalent to xsd:string.


Since the generation of the local datatype name
for untyped literals (i.e. _:a) is done by the parser
(usually) and will be unique for every untyped literal,
triples stores can pretend that all nodes are tidy by
label, and do merging without having to be concerned
about the type of node.

The untidyness of untyped literals is thus captured in the
unique local name.

Received on Thursday, 22 August 2002 16:04:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:59 UTC