RE: PS-8: Query with Datatype Value Comparison & Support for Arbitrary Datatypes in Query

The problem of datatype support has been addressed as part of the OWL
effort. Specifically, formal semantics of how reasoners should behave
when presented with datatypes they do not support have been specified.

I think this came up as part of OWL because it was the first time
anybody had specified formal semantics for doing just about anything
with regards to the meaning of RDF or XML beyond verifying its lexical
representation. An RDF query language which allows datatype predicates
would be the second. It makes a lot of sense not to set a precedent of
reinventing these semantics for every semantic processor of XML schema
datatypes.

The existing semantics
(http://www.daml.org/2002/06/webont/owl-ref-proposed#DatatypeSupport)
are:

As a minimum, tools must support datatype reasoning for the XML Schema
datatypes xsd:string and xsd:integer. For unsupported datatypes,
lexically identical literals should be considered equal, whereas
lexically different literals would not be known to be either equal or
unequal. Unrecognized datatypes should be treated in the same way as
unsupported datatypes.

> -----Original Message-----
> From: Patrick Stickler [mailto:patrick.stickler@nokia.com] 
> Sent: 02 April 2004 00:21
> To: ext Janne Saarela
> Cc: public-rdf-dawg@w3.org
> Subject: Re: PS-8: Query with Datatype Value Comparison & 
> Support for Arbitrary Datatypes in Query
> 
> 
> 
> 
> On Apr 02, 2004, at 10:49, ext Janne Saarela wrote:
> 
> >
> >
> > Following yesterday's teleconference I would like to continue
> > discussion on this support for arbitrary datatypes in a query.
> >
> > I suggested that if the support is really for any arbitrary
> > datatype, for a DAWG recommendation compatible RDF query
> > processor we need to lay a set of minimal datatypes it needs
> > to support. This would enable us to lay a minimal set of
> > operators that operate on these datatypes.
> >
> > I suggest the minimal set of datatypes would be a
> > subset of all XML Schema datatypes. I leave it up to
> > further discussion to see which ones are truly necessary.
> 
> I support both of these requirements.
> 
> 1. Any typed literal value which can be expressed in RDF/XML must
>     also be expressible in the DAWG QL in terms of the same datatype
>     URI and lexical form. There are thus no restrictions on the
>     datatypes that one can use to express a query.
> 
> If a given datatype expressed in a query is not recognized/supported,
> the query either fails, since no comparisions can be made, or (my
> preference) a warning/error is issued about the unsupported datatype).
> 
> 2. A core set of datatypes, ideally based on the XML Schema predefined
>     datatypes, will be specified as manditory.
> 
> As for the latter, the list should be as short as possibly. Perhaps 
> only:
> 
> xsd:string
> xsd:decimal, and some/all its derived subtypes
> xsd:date
> xsd:dateTime
> xsd:anyURI
> xsd:base64Binary
> xsd:boolean
> 
> 
> Patrick
> 
> 
> 
> >
> > Janne
> >
> >> A client wishes to discover all resources which are of rdf:type
> >> ex:Person, and have an ex:ageInYears which is between 
> "16"^^ex:count
> >> and "18"^^ex:count, inclusive.
> >> The client is aware of a knowledge source from which such
> >> resources might be discovered.
> >> Following the DAWG recommendation, the client formulates a query
> >> which expresses the desired characteristics to match and submits
> >> the query to the knowledge source.
> >> The knowledge source returns zero or more resource descriptions
> >> describing the matched resources.
> >> -- 
> >> I deliberately used unknown datatypes in this example to illustrate
> >> the need to be able to allow arbitrary datatypes in input queries,
> >> regardless of what datatypes a particular query resolution engine
> >> may be able to handle.
> >> Note that if the client is able to include auxiliary knowledge
> >> which may be relevant to resolution of the query along with
> >> the query itself (e.g. in a single input RDF graph) this 
> would allow
> >> the client to provide information about the terminology used
> >> in the query, such as about the nature of particular datatypes,
> >> their relationship to other datatypes, and even references to
> >> formal definitions of the datatypes which could be used by the
> >> knowledge source to evaluate typed literals and perform 
> comparisons.
> >> E.g. the auxiliary knowledge could indicate an XML Schema which
> >> defines the datatype in question, and if the knowledge source is
> >> able to understand XML Schemas, could load and utilize to deal
> >> with values of that datatype.
> >> -- 
> >> Patrick Stickler
> >> Nokia, Finland
> >> patrick.stickler@nokia.com
> >
> >
> > -- 
> > Janne Saarela <janne.saarela at profium.com>
> > Profium, Lars Sonckin kaari 12, 02600 Espoo, Finland
> >
> >
> 
> --
> 
> Patrick Stickler
> Nokia, Finland
> patrick.stickler@nokia.com
> 
>

Received on Friday, 2 April 2004 20:09:55 UTC