Re: [DTB/Abridged syntax] ISSUE on -equals and -not-equals predicates?

-Chris (sent from my iPhone)

On Dec 4, 2008, at 4:08 PM, Jos de Bruijn <debruijn@inf.unibz.it> wrote:

>
>
> Axel Polleres wrote:
>> Jos de Bruijn wrote:
>>>
>>> Axel Polleres wrote:
>>>> Jos de Bruijn wrote:
>>>>> Axel Polleres wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I introduced, as for the other datatypes (along with an editors  
>>>>>> note),
>>>>>> -equals and -not-equals predicates for the rdf:XMLLiteral  
>>>>>> datatype.
>>>>>>
>>>>>> There is an obvious overlap between the -equals predicates and  
>>>>>> '=',
>>>>>> i.e.
>>>>>> the '=' built-ins are superfluous, it seems, for dialects that  
>>>>>> support
>>>>>> equality.
>>>>>>
>>>>>> That is not the case for the not-equals predicates, though:
>>>>>>
>>>>>> All the -not-equals predicates, i.e.  pred:numeric-not-equal,
>>>>>> pred:string-not-equal, pred:dateTime-not-equal, pred:date-not- 
>>>>>> equal,
>>>>>> pred:time-not-equal, pred:duration-not-equal,
>>>>>> pred:XMLLiteral-not-equal,
>>>>>> pred:text-not-equal
>>>>>>
>>>>>> are defined on the same domains as their positive counterpart  
>>>>>> with
>>>>>> reversed truth-values.
>>>>>>
>>>>>> That has the consequence though, that they are not possibly
>>>>>> emulated by
>>>>>> negation as failure, i.e. it is in general not true to say that  
>>>>>> the
>>>>>>
>>>>>> -not-equals version is true, whenever the -equals version is  
>>>>>> NOT true.
>>>>>>
>>>>>>
>>>>>> An example:
>>>>>>
>>>>>> _a:-  External (pred:numberic-equals("blabla", 1) )
>>>>>> _b:-  External (pred:numberic-not-equals("blabla", 1) )
>>>>>>
>>>>>> entails neither _a nor _b, however
>>>>> Both rules contain errors, and since errors mean arbitrary truth
>>>>> values,
>>>>> you don't know whether _a or _b are entailed, and in practice I  
>>>>> suspect
>>>>> applications will terminate with some error message.
>>>> No, that is not what the semantics says... it says that the truth- 
>>>> value
>>>> may vary from interpretation to interpretation and that means it  
>>>> is not
>>>> true in all interprestations which means it is not entailed.
>>>
>>> No. We leave it up to the user, which means the user can choose to  
>>> make
>>> it true in every interpretation.

This was my understanding. ( I think I proposed it) but I agree the  
following could be understood as saying something else:

>>>
>>
>> I assume that this is your reading of
>>
>> "If the argument value is outside of the intended domain or outside  
>> the
>> partial conversions defined in [XPath-Functions], the value of the
>> function is left unspecified and can vary from one semantic  
>> structure to
>> another."
>>
>> interesting opinion.
>
> It is what we agreed upon at F2Fx (I believe in Paris).
>

>> my reading does not imply what you say. Maybe this
>> needs clarification then?
>
> Probably we need to get rid of the text about "varying between
> interpretations". Also, one should add that the truth value of
> predicates whose arguments are outside the domain of the external
> relation is unspecified.
> I think the text should be clear then.
>

Agreed.

>
> Best, Jos
>
>>
>> Axel
>>
>>
>>> Best, Jos
>>>
>>>> We do not have errors in RIF, that was decided long ago.
>>>>
>>>>>> _a:-  "blabla" = 1
>>>>>> _b:-  naf ( "blabla" = 1 )
>>>>>>
>>>>>> would entail _b.
>>>>>>
>>>>>> So, 2 questions:
>>>>>>
>>>>>> 1) Do we want this behavior or do we want the negation as failure
>>>>>> behavior of inequality?
>>>>> We want this behavior, since this is the only reasonable way
>>>>> to define these built-in predicates.
>>>>>
>>>>>> 2) Do we want the redundancy of equals predicates?
>>>>> Yes, for dialects that do not supported equality.
>>>> Same opinion here in both points...
>>>>
>>>>> Best, Jos
>>>>>
>>>>>> I think we need these things clarified, to be able to determine  
>>>>>> how
>>>>>> '=' and "!=" shortcuts in an abridged syntax should be defined.
>>>> ... which means that '!=' in an abridged syntax would be defined  
>>>> as:
>>>>
>>>> numeric-not-equal or string-not-equal or text-not-equal or
>>>> date-time-not-equal or date-not-equal or time-not-equal or
>>>> duration-not-equal or XMLLiteral-not-equal
>>>>
>>>> and '=' would be defined as equality in dialects that support it  
>>>> and
>>>>
>>>> numeric-equal or string-equal or text-equal or date-time-equal or
>>>> date-equal or time-equal or duration-equal or XMLLiteral-equal
>>>>
>>>> in others... Would that the agreed reading for = and != in an  
>>>> abridged
>>>> syntax?
>>>>
>>>> Axel
>>>>
>>>>>> Axel
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
>
> -- 
>                         debruijn@inf.unibz.it
>
> Jos de Bruijn,        http://www.debruijn.net/
> ----------------------------------------------
> Many would be cowards if they had courage
> enough.
>  - Thomas Fuller

Received on Thursday, 4 December 2008 21:53:11 UTC