Re: ISSUE-80: Meta builtins

Axel Polleres wrote:
> I do not formally object but have reservations against 3) because:
> i) pred:literal-equal/pred:literal-not-equal are then no longer
> "parametrizable" for any dialect, but always depend on the certain
> datatypes of BLD only, i.e. their definition would not extend to new
> datatypes and particular I am unsure about what that means for the
> definition of literal-not-equal (admittedly, didn't think about it in
> detail yet)

I don't see a problem. pred:literal-(not-)equal must be undefined for
anything outside the value spaces of the known datatypes. Extensions can
define how currently undefined bits are defined. Analogous to
isLiteralOfType.

For the record: I strongly prefer option 1) and would object to option
2) unless someone can make a compelling case for having this redundancy,
and can explain why literal-equal should be defined in terms of
identity, rather than literal equality, as defined by XML schema.


Best, Jos

> 
> 
> 
> Chris Welty wrote:
>>
>> Issue-80 was prompted by DaveR's attempt at using RIF-Core to specify
>> the rules in OWL-RL.  He suggested it would be much easier, and also
>> promote datatype extensibility, if the builtins were more general.  We
>> resolved to have a two-argument pred:isLiteralOfType (and its
>> negation), and are currently considering literal equality, which is
>> more complicated.
>>
>> Basically we need a pred:literal-not-equal, or at the very least a
>> not= for each datatype.  It seems to make sense to have a
>> pred:literal-equal as well (for symmetry, if nothing else), but what
>> does it do? Is it redundant with RIF's = predicate?  Does it do
>> numeric comparison?  Is it simply lexical?
>>
>> At the moment pred:literal-equal is defined to be subsumed by RIF's
>> =.  It does not do xs:numeric-equal, which includes type promotion. 
>> Thus we would need to keep that, unless this predicate were changed. 
>> RIF= for datatype checks identity in the value space.
>>
>> Jos believed he read somewhere that it is possible for a datatype to
>> have multiple values in their value spaces that are identical. 
>> Probably this is from dateTime, which is pretty hard to understand - I
>> wasn't able to nail it down precisely (the spec says datetimes are
>> compared based on their timeline values).  Thus if RIF= already
>> provides value space identity, pred:literal-equal could provide the
>> datatype specific equality that F&O specifies for e.g. numerics,
>> date-times, etc.
>>
>> Note:  [XS2] says "Equality" in this Recommendation is defined to be
>> "identity" (i.e., values that are identical in the ˇvalue spaceˇ are
>> equal and vice versa). Identity must be used for the few operations
>> that are defined in this Recommendation. Applications using any of the
>> datatypes defined in this Recommendation may use different definitions
>> of equality for computational purposes; [IEEE 754-1985]-based
>> computation systems are examples. Nothing in this Recommendation
>> should be construed as requiring that such applications use identity
>> as their equality relationship when computing.
>>
>> Solutions:
>>
>> 1) Drop pred:literal-equal
>> 2) Leave pred:literal-equal as is (redundant with RIF =)
>> 3) Redefine pred:literal-equal to perform all the datatype specific
>> equality tests including numeric, and remove those datatype specific
>> tests from DTB.
>>
>> -Chris
>>
>> [Xs2] http://www.w3.org/TR/xmlschema-2/
>>
> 
> 

-- 
+43 1 58801 18470        debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
Many would be cowards if they had courage
enough.
  - Thomas Fuller

Received on Monday, 2 March 2009 16:05:03 UTC