[DTB] ready to go...

BTW, my last mail means that the changes according to the resolution 
from the minutes from yesterday's meeting are done:

"RESOLVED: publish DTB as a next WD after changes listed in 
http://lists.w3.org/Archives/Public/public-rif-wg/2008Dec/0045.html"

Axel Polleres wrote:
> 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 10:08:55 UTC