Re: xsi:type test case

First, a big "hooray" on this. It might be less glamorous than some of
the other proposals, but I feel that this offers a huge advantage for
the folks out there doing DB/RDF interface work, query, etc.

On Tue, 6 Aug 2002, Graham Klyne wrote:

>
> At 05:38 PM 8/2/02 +0200, Jeremy Carroll wrote:
>
> >Are the two documents descriptions of the same graph?
> >
> ><rdf:RDF>
> >   <rdf:Description>
> >     <eg:prop xsi:type="xsd:decimal">2.0</eg:prop>
> >   </rdf:Description>
> ></rdf:RDF>
> >
> >
> >
> ><rdf:RDF>
> >   <rdf:Description>
> >     <eg:prop xsi:type="xsd:decimal">2.00</eg:prop>
> >   </rdf:Description>
> ></rdf:RDF>
> >
> >I think I heard yes.
>
> If the literal is intended to be a number, then I think yes.

The answer is yes. However, this raises a question I was trying to
figure out a while ago.

> But a possible issue then would be that RDF engines without knowledge of
> XML schema datatypes would get different answers from engines that do have
> such knowledge.  I don't know if that's a problem.

Depending on how schema datatypes are revised, this might be a problem
anyway. I don't think you can promise anything from an RDF
implementation on datatypes it knows nothing about except some default
behaviour ("I'll use string comparison") in the absence of any other
knowledge.

> >Furthermore is this the same:
> >
> ><rdf:RDF>
> >   <rdf:Description>
> >     <eg:prop xsi:type="xsd:int">2</eg:prop>
> >   </rdf:Description>
> ></rdf:RDF>
> >
> >I suspect it is too?

That's the killer question I couldn't come up with only one answer to,
and I think it's the most important one. Do we produce some
xsd-influenced hierarchy of idealised types C, R, Q, Z, N or do we take
a pragmatic RDBMS-influenced view of having "reals" and "ints" as
separate datatypes that don't intersect?

While I like the former, I've got a suspicion that the latter is a more
realistic approach from an implementation point of view*.

The only thing that makes me feel reasonably happy about the latter view
is that we've got some "tradition" in RDF of making intension/extension
distinctions explicit and in that vein I'd be reasonably persuaded by
"it's an int, dammit, not a bloody real number" when talking about (say)
cardinality, number of parents/fingers/mail addresses, etc.

The other thing that we need to be sure of is the story we tell
regarding all the other scenarios and requirements we collected in the
(close to) first round of all this. We've got (like java) a fixed (? -
can we wedge a type theory on top of literals?) set of primitive types,
so what about 1. enumerations, 2. compound types, and 3. taxonomic
categorisations? I'd be happy with saying, "use a uri-labelled resource"
for 1 and 3, and "express the structure using nodes and arcs" for 2.

jan

* I've got a c. 3.5-year-old implementation that went this way;
implementation language (java) had a lot to do with that, however.

-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
Talk is cheap: free, as in beer. As in Real Ale, not that Budweiser rubbish.

Received on Tuesday, 6 August 2002 15:59:06 UTC