W3C home > Mailing lists > Public > public-owl-wg@w3.org > July 2008

Re: ISSUE-126 (Revisit Datatypes): A proposal for resolution

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Tue, 1 Jul 2008 13:10:37 -0400
Message-Id: <2FE0654F-5988-4D02-94B6-028EA8B91EE4@gmail.com>
Cc: "'Michael Smith'" <msmith@clarkparsia.com>, "'OWL Working Group WG'" <public-owl-wg@w3.org>
To: "Boris Motik" <boris.motik@comlab.ox.ac.uk>


On Jul 1, 2008, at 12:43 PM, Boris Motik wrote:

> Hello,
>
> I wouldn't redefine the structural equivalence: the definition  
> should be in line with all the other definitions and it should at  
> least allow the tools to make this distinction.
>
> Rather, I think this is a problem of implementations and of a query  
> language. The definition of the query language should say something  
> like "one of the literals is returned". I don't think, however,  
> this is in the scope of this working group. I also don't think we  
> should worry too much about this at the level of the spec. As I  
> said, we never disqualify such implementations in the first place,  
> so people are allowed to choose to implement whatever seems  
> reasonable for their target application.

The point is that with the version of equivalence that I give they  
are *more* free, while still having the ability to preserve leading  
0s, etc. if they want to. Right now if an implementation chose to  
canonicalize then could not claim to maintain structural equivalence  
at all.

As for "I don't think we should worry too much about this at the  
level of the spec", that made me lol.

We are the kings of worrying about details :)

-Alan

>
> Regards,
>
> 	Boris
>
>> -----Original Message-----
>> From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com]
>> Sent: 01 July 2008 17:25
>> To: Michael Smith
>> Cc: Boris Motik; 'OWL Working Group WG'
>> Subject: Re: ISSUE-126 (Revisit Datatypes): A proposal for resolution
>>
>> On Jul 1, 2008, at 12:22 PM, Michael Smith wrote:
>>
>>> On Tue, 2008-07-01 at 11:13 -0400, Alan Ruttenberg wrote:
>>>
>>>> Michael, could you give an example of what your concern was re:
>>>> internal representation of literals, and how it might play out?
>>>
>>> My primary concern was that we were getting close to spec'ing
>>> implementation details.  I agree with Boris that such details aren't
>>> important.  My point was that tools might not care about structural
>>> changes so we shouldn't assume a particular implementation.
>>>
>>>
>>> However, since you asked, here's a trivial example - if a tool could
>>> implement an internal representation based on value space identity
>>> instead of lexical identity so that "1.0"^^xsd:decimal and
>>> "1"^^xsd:decimal could share the same object / db row / etc.
>>>
>>> For a large ABox with a large number of data property assertions, an
>>> additional requirement to store the lexical value may impose a
>>> significant memory burden.  On the other hand, not storing the
>>> canonical
>>> (i.e., value space) identity (so it is computed on the fly, perhaps
>>> many
>>> times) could make some activities much slower (consider DBMS style
>>> indexing of a datatype for more efficient query).
>>>
>>> That might mean my input data is "02.20"^^xsd:decimal but as a query
>>> result "2.2"^^xsd:decimal  is returned.  I think that in some
>>> applications trading that for reduced memory consumption and  
>>> reasoning
>>> runtime is permissible.
>>
>> I agree that this is a compelling case. I think we should actually
>> consider defining the structural equivalence so that literals are
>> considered equivalent if their type is the same, and their value is
>> the same (or where a canonicalized alternative is allowed), rather
>> than as is now - that the type is the same, and the string
>> representation is the same. I'm hard pressed to see a case where  
>> there
>> current definition is preferable.
>>
>> -Alan
>>
>>>
>>>
>>> --
>>> Mike Smith
>>>
>>> Clark & Parsia
>>>
>
>
Received on Tuesday, 1 July 2008 17:11:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:05 UTC