- From: Axel Polleres <axel.polleres@deri.org>
- Date: Tue, 09 Dec 2008 14:09:54 +0100
- 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 UTC