W3C home > Mailing lists > Public > public-rif-wg@w3.org > December 2008

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

From: Axel Polleres <axel.polleres@deri.org>
Date: Wed, 10 Dec 2008 10:49:49 +0100
Message-ID: <493F90BD.1020104@deri.org>
To: Axel Polleres <axel.polleres@deri.org>
CC: Chris Welty <cawelty@gmail.com>, Jos de Bruijn <debruijn@inf.unibz.it>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Axel Polleres wrote:
> 
> 
>  >> 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.
> 
> That is already said in Section 3, item 5...
> 
>  >> I think the text should be clear then.
> 
> 
> ... so, would the following change from
> 
> "This means that if one or more of the arguments is not in its intended 
> domain, the value of I_external(\sigma)(a1 ... an) can vary from one 
> semantic structure to another."
> 
> to
> 
> "This means that if one or more of the arguments is not in its intended 
> domain, the value of I_external(\sigma)(a1 ... an) is unspecified. That 
> means in particular, it can vary from one *implementation* to another."

done, slightly reworded.
Also changed:

"This indeterminacy in case of an error implies that applications *must* 
not make any assumptions about the values of built-ins in such situations."

to

"This indeterminacy in case of an error implies that applications 
*should* not make any assumptions about the values of built-ins in such 
situations."

Actually, I am not sure about this sentence anymore... isn't it 
confusing. On the one hand we say *implementations* can do what they 
want, on the other hand we say *applications* must/should not make 
assumptions about the values... What is the difference between 
implementation and application?


> be acceptable in Section 3, item 5.?
> As well as changing henceforth in all function and predicate 
> descriptions the recurring sentence
> 
> "the value [...] is left unspecified and can vary from one semantic 
> structure to another. "
> 
> to
> 
> "the value [...] is left unspecified."

done that as well.

> I think that does it.
> 
> Axel
> 
> Chris Welty wrote:
>>
>>
>> -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
> 
> 


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/
Received on Wednesday, 10 December 2008 09:50:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:59 GMT