- From: Jos De_Roo <jos.deroo.jd@belgium.agfa.com>
- Date: Thu, 21 Nov 2002 14:31:09 +0100
- To: "Brian McBride <bwm" <bwm@hplb.hpl.hp.com>
- Cc: "RDFCore Working Group" <w3c-rdfcore-wg@w3.org>, w3c-rdfcore-wg-request@w3.org
[...]
> If the test case is of the form
>
> <a> <b> "10"^^xsd:integer .
>
> datatype entails (xsd)
>
> <a> <b> "010"^^xsd:integer .
>
> and bearing in mind the we expect these to be machine checkable, do this
> suggest that a datatype aware RDF processor must generate the infinity of
> different representations of the number 10. I might be wrong here - Jos
> seems to have done it without this problem.
right, this is the traditional forward/backward chaining stuff
we do the latter and so start from the entailed graph and try
to find evidence for it in the premised graphs, which is quite
obvious here as the term "010"^^xsd:integer unifies with the
term "10"^^xsd:integer
> If we couch the test in the form:
>
> <a> <b> "10"^^xsd:integer .
> <c> <d> "010"^^xsd:integer .
>
> datatype entails (xsd)
>
> <a> <b> _:v.
> <c> <d> _:v.
>
> then there is no suggestion that the process has to generate the infinity
> of values, only that it needs to be able tell when two lexical forms it
is
> given denote the same value.
that is of course working as well
-- ,
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/
PS I think I was completely wrong to have been suggesting
examples such as "1E1"^^xsd:decimal as I now see that
"1E1" is not an allowed xsd:decimal lexical representation
[[
decimal has a lexical representation consisting of a
finite-length sequence of decimal digits (#x30-#x39)
separated by a period as a decimal indicator.
]]
-- http://www.w3.org/TR/xmlschema-2/#decimal
Received on Thursday, 21 November 2002 08:32:52 UTC