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

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

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

Thus, one could say

IF

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

THEN

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

IF
    ?p rdfs:range xsd:integer .
    ?s ?p xsd:string,"LLL" .
THEN
   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.

etc.

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.

Patrick

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