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

Re: [rdfcore-in-exile] Agenda for 2003-08-22 RDFCore telecon (1hr)

From: Jan Grant <Jan.Grant@bristol.ac.uk>
Date: Fri, 22 Aug 2003 14:03:34 +0100 (BST)
To: Dan Brickley <danbri@w3.org>
Cc: w3c-rdfcore-wg@w3.org, rdfcore-in-exile <rdfcore-in-exile@vapours.rdfweb.org>
Message-ID: <Pine.GSO.4.44.0308221351230.20270-100000@mail.ilrt.bris.ac.uk>

On Fri, 22 Aug 2003, Dan Brickley wrote:

> 12: Treatment of XSD types
>
>   thread spun off http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Aug/0231.html
>
> 	[[
> 	Hopefully for Pat to just confirm that I didn't imagine it when I
> 	thought I heard him say that this is now the treatment of XSD types: ie,
> 	that their denotation is a pair of (typename, value).
> 	]] --Jan
>
> 	[[
> 	xsd:integer is still a subclass of xsd:decimal (which may or may not be
> 	true with intentional semantics, regardless of the datatype L2V
> 	definition); or rather, the value space of one is a subset of the value
> 	space of the other (in which case nothing needs doing), or:
>
> 	xsd:integer's value space is not a subset of the value space of
> 	xsd:decimal after all, in which case I add another "What?!?" to the
> 	list, but that's a problem to raise with the xml schema people.
> 	]] -- JanG
>
> 	[[
> 	Yup; when Pat said, "none of the XSD datatypes intersect", he meant,
> 	with the value space for XML Literal, not each other. Sorry if I gave
> 	anyone heartaches over their cornflakes.
> 	]]
> 	JanG, http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Aug/0241.html
>
> Is this resolved / closed / understood now? Any affect on specs?

Actually, from the sound of PatH's followup, this might not be resolved.
Anyway, currently we have the test case:

http://www.w3.org/2000/10/rdf-tests/rdfcore/datatypes/Manifest.rdf#semantic-equivalence-between-datatypes

which says that

[[
eg:foo eg:bar "10"^^xsd:integer .
]]
rdfs+dt(xsd:integer, xsd:decimal) - entails
[[
eg:foo eg:bar "10.0"^^xsd:decimal .
]]

The test case is useful in that it illustrates that two members of
different datatypes may indeed denote the same value. It also expresses
our best understanding at the time of the intention of the XSD spec.
Finally, in support of this test case, as I recall WebOnt passed a
resolution to the effect that (amongst other things) xsd:integer was a
subclass of xsd:decimal (wrt value spaces). I don't know if that
resolution is out-of-date.

However:

- the test case actually tests another spec
- while it sounds like XMLSchema are prepping words which will probably
(due to equality/identity distinction) preserve the truth of this test
case by a gnat's whisker,
- ... the truth of this test case is not "obvious" since the XSD WG, if
not the spec itself, seem to be in two minds about it.

Thus there are three options:

1. Preserve the test case as is. In that case, we should probably
communicate to the XML Schema WG asking them to consider it as
identifying a strong use case should they come to revise their decisions
wrt the value sapces of XSD primitive types;

2. Remove it on the grounds that (a) it's not our problem, (b) the truth
of it depends on another WG's decisions

3. Label the test case as being non-normative, whilst approved, since
(a) it illustrates a valid point about the value spaces of datatyped
literals, regardless of the XSD details, (b) we think this is how XSD
primitive types should work in RDF, and again ask the XML Schema WG to
bear it in mind.

In that case the test case document would include some words about this
test case to the effect that the XSD types are used purely to ground in
concrete terms the illustrative test case.

We already have implementations (Jos?) that pass this test case.



-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
That which does not kill us goes straight to our thighs.
Received on Saturday, 23 August 2003 09:33:40 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:59:41 EDT