- From: Jeremy Carroll <ping.pong@tin.it>
- Date: Thu, 1 Nov 2001 07:14:48 +0100
- To: <w3c-rdfcore-wg@w3.org>
- Cc: <afs@hplb.hpl.hp.com>
I thought these comments from a colleague (Andy Seaborne) were significant. They give a concrete example of how users of datatypes will have to cope with whatever we decide. The query example is one he currently implements by forcing a string into an integer. Any datatyping solution should leave implementors with a plausible migration path during which they can support both explicitly typed and untyped data. (I am not in the office, nor actively reading the WG mail this week) Jeremy [[[[ Consider a query like: (?b, <price>, ?v) && (?b, <class>, <salesitem>) && ?v < 57 [?v is not necessarily atomic] Having structure to each literal (whether by structured item bNode, by literals as subjects or reified statements) means that each ?v retrieved will need also need the datatype information retrieved. (?b, <price>, ?v) && (?b, <class>, <salesitem>) && [ [ (?v, <datatype>, xsd:float) && ?v < 57 ] || # < is float< [ (?v, <datatype>, xsd:int) && ?v < 57 ] # < is int< ] so there is limited implicit disjunction. It is also dynamic typing and it is unclear to me how constraints can be pushed to, say, an SQL database and still get exact semantics of < in each possible case. With the schema approach, things are different. In this query, the query system knows that its got a set of <salesitem>s so the <price> property has range "float" and it can send the condition "< 57" down to the SQL because it fits SQLs model that columns define the type of literal. Following this style, representing the same values in different forms (eg in a model merge) is an ontology transformation issue. So there is a trade-off in query space between instance schemes and schema/ontology schemes for datatyping. There are two datatyping issues: overall structure and being able to express information about an instance. ]]]]]
Received on Thursday, 1 November 2001 01:36:39 UTC