Datatypes and Query

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