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: Tue, 09 Dec 2008 14:09:54 +0100
Message-ID: <493E6E22.8060305@deri.org>
To: Jos de Bruijn <debruijn@inf.unibz.it>
CC: Chris Welty <cawelty@gmail.com>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Am here with bad connection and without spare battery
... don't know whether I can make it.
However, if you could make a conditional vote, I can implement he 
changes by tomorrow, as soon as I am back in my hotel.

Need to send regrets for today's teleconf.

Axel

Jos de Bruijn wrote:
> I noticed that this change has not yet been implemented.  As we are
> going to vote about publication of the document, could you please
> implement this change before the meeting today?
> Thanks
> 
> Best, Jos
> 
> 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."
>>
>> 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."
>>
>>
>> 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 Tuesday, 9 December 2008 13:10:44 GMT

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