W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: D-enatilment and canonicalization

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Fri, 05 Mar 2010 10:07:02 +0000
Message-ID: <4B90D7C6.3070501@talis.com>
To: "Polleres, Axel" <axel.polleres@deri.org>
CC: ivan@w3.org, public-rdf-dawg@w3.org
The SPARQL query really starts where the data is already loaded (FROM 
etc not withstanding) so the data as it is loaded may be prepared in 
some fashion outside the SPARQL spec.

When we discussed this last time, we recognized that systems already did 
work on loading RDF and did not introduce any text to obstruct them.

As to whether it's an "entailment regime", if it is then it's finite and 
different for each system.  It is done when data is loaded not queried 
(think running rules over the data).


For example, TDB canonicalizes integers between -2^55 and +2^55-1 but 
not outside that range (they have their original lexical form stored). 
Decimals have 48 bits of precision and 8 bits of scale and again if 
outside the that range, the normal node storage is used and the lexical 
form is not canonicalised.

Derived integer types are promoted to integer.

(This in TDB is all "currently" and planned to change a little).

	Andy

On 05/03/2010 9:29 AM, Polleres, Axel wrote:
> Thanks andy, my (maybe naïve) question would then be: is behavior 2 warranted "as is" by the current spec, or is "canonical datatype representation" actually another (commonly used already) "entailment regime" that should be defined as such?
>
> Best,
> Axel
>
> ----- Original Message -----
> From: Andy Seaborne<afs@talisplatform.com>
> To: Polleres, Axel
> Cc: ivan@w3.org<ivan@w3.org>; public-rdf-dawg@w3.org<public-rdf-dawg@w3.org>
> Sent: Fri Mar 05 09:06:09 2010
> Subject: D-enatilment and canonicalization
>
>
>
> On 05/03/2010 8:45 AM, Polleres, Axel wrote:
>> In my opinion this is a question concerning all entailments from D-entailment "upwards".
>>
>> ----- Original Message -----
>> From: Ivan Herman<ivan@w3.org>
>> To: Polleres, Axel
>> Cc: Birte Glimm<birte.glimm@comlab.ox.ac.uk>; SPARQL Working Group<public-rdf-dawg@w3.org>
>> Sent: Fri Mar 05 08:08:10 2010
>> Subject: Re: [TF-ENT] Condition C2 modifications
>>
>>
>>
>> On 2010-3-5 24:36 , Axel Polleres wrote:
>>>
>>> No objections, but one additional side question:
>>>
>>> Do we have an issue with systems that use canonical forms of datatype literals internally?
>>>
>>> Say you have:
>>>
>>>    :s :p "1.000"^^xsd:decimal
>>>
>>> is a Datatype-aware system really supposed to return
>>>
>>>    "1.000"^^xsd:decimal
>>>
>>> on { :s :p ?O}
>>>
>>> but not it's internal representation?
>>>
>>>
>>
>> This is a good question, I do not know the answer:-(, but is this an
>> entailment specific question? I would expect that to be a question for
>> SPARQL as a whole...
>>
>> Cheers
>>
>> Ivan
>
> There are 2 cases for value aware systems and there are examples of
> systems in each case:
>
> 1/ Data "1.00"^^xsd:decimal,
>      stores "1.00"^^xsd:decimal,
>      matches "1.0"^^xsd:decimal,
>      matches "1.00"^^xsd:decimal,
>      returns "1.00"^^xsd:decimal
>
> i.e. the original term is stored and returned
>
> 2/ Data "1.00"^^xsd:decimal,
>      stores "1.0"^^xsd:decimal,
>      matches "1.0"^^xsd:decimal
>      matches "1.00"^^xsd:decimal (canonicialization applied)
>      returns "1.0"^^xsd:decimal
>
> i.e. the canonicalized term is stored and returned
>
>
> See also "1"^^xsd:byte and "1"^^xsd:integer
>
> I avoided describing them as D-entailment because that really is a set
> of possibilities depending on the datatypes supported and ranges of
> values within the datatypes.  They don't necessarily force D-consistency.
>
> 	Andy
>
> Examples:
> 1 - Jena memory model
> 2 - Jena TDB
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
Received on Friday, 5 March 2010 10:07:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT