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

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.

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 16:44:56 UTC