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

On Apr 03, 2004, at 04:08, ext Rob Shearer wrote:

>
> 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.
>

This of course leads to the question of whether a DAWG conformant
knowledge store is an OWL reasoner, and thus, to what extent the OWL
specs have anything to say about DAWG conformant behavior.

But I think we should certainly reuse anything/everthing we can from
OWL and other relevant specs.

> 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.

I would expect support as well for xsd:dateTime at the very least,
for a DAWG conformant solution.

The other proposed datatypes, while having merit, are not as critical
insofar as most of the use cases I've seen.


> 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.

Right.

Patrick


>
>> -----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
>>
>>
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Monday, 5 April 2004 05:02:41 UTC