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 12:25:26 -0400
Cc: Boris Motik <boris.motik@comlab.ox.ac.uk>, 'OWL Working Group WG' <public-owl-wg@w3.org>
Message-Id: <68E0AC19-AB2B-4972-BF35-2E3DA86CC9D4@gmail.com>
To: Michael Smith <msmith@clarkparsia.com>

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.


> -- 
> Mike Smith
> Clark & Parsia
Received on Tuesday, 1 July 2008 16:26:06 UTC

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