[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] Inference and equivalence defintion/notation (and $has)
Can we have && for AND maybe (C, C++, Java et al.)? >> You asked about the following >> >> :+a/$has/+b = (+a/+b) = +a+b >> >> Yes, I think so. Though this presents a hefty practicality concern that >> =Bill+email now resolves to the graph of statements about the statement >> (=Bill/+email), rather than a set of statements describing Bill's email. I also fear they represent different concepts. +a/$has/+b = (+a/+b) maybe, but +a/$has/+b != +a+b Kind Regards, Giovanni Def. Quota "Drummond Reed" <drummond.reed@xdi.org>: > Bill, > > Just a quick note to say that of course I agree let's use the terms that are > widely established in the semantic community. I only typed /= last night > because I was too tired to remember the notation (I really shouldn't stay up > that late) and I wanted to follow up on yesterday's conversation quickly. > > I like all of your notation and suggest we adopt it. Doe everyone else > agree? (Let me put it this way - anyone who does not agree, please post, > otherwise let's use Bill's notation.) > > I don't have time right at this moment to answer the questions at the bottom > of your message, but I'll try to get back to it later today, as I think > we've got the foundation now to complete a semantically deeper and stronger > definition of $has and $has$a, and with my improved understanding of the > notation, we might even be able to make good progress on that in email. > > Thanks, > > =Drummond > > On Fri, Jan 15, 2010 at 5:51 AM, Barnhill, William [USA] < > barnhill_william@bah.com> wrote: > >> Hi Drummond, >> >> Your email makes sense but I have a few things I'd like to ehar what you >> think about: >> >> The terms I was using 'logical equivalence', 'implies/implication', '!= for >> not equal' are not terms I created. They're terms in wide adoption within >> semantic community and in the case of !=, the development community. >> Typically what you're calling inference is isually termed implication. I >> haven't encountered the terms you used before, so what do you think about >> using the following terms and notation instead: >> >> >> Implication => (there's no >> need for <= as A <= B is stated as B => A) >> >> Logical equivalence <=> >> >> Alias (ie resolution equivalence) == >> >> Non-equivalence != >> >> And ^ >> >> Or || >> >> Not And (NAND) | >> >> Exclusive Or (XOR) ~| >> >> Nor (Not Or) !| >> >> >> >> The notation for the boolean operations NAND, XOR, and NOR above >> are my own. The std notation is >> >> not easily entered into plain text except as an image. >> >> >> >> You asked about the following >> >> :+a/$has/+b = (+a/+b) = +a+b >> >> Yes, I think so. Though this presents a hefty practicality concern that >> =Bill+email now resolves to the graph of statements about the statement >> (=Bill/+email), rather than a set of statements describing Bill's email. >> >> >> >> :+a/$has/+b /= +a/+b >> >> Yes the right one contains statements about the value of the left one, the >> left statements about the value of the +b property of +a. >> >> >> >> :+a/+b /= +a+b >> >> Yes the left one contains statements about the value of the +b property of >> +a, the right statements about the left one. >> >> >> >> :+a/$has$a/+b = +a/+b >> >> Don't know. I never got the feeling we nailed down $has$a enough for me to >> make this determination. I still do not like $a as an inverse operator, >> would prefer defining inverse $ words for the key concepts like $has, maybe >> $hadby. I think we have to nail $has down real well before we can define the >> inverse of it. >> >> >> >> :+a/$has$a/+b /= (+a/+b) >> >> See above. >> >> >> Kind regards, >> >> Bill Barnhill >> Booz Allen Hamilton - Rome, NY >> 315-330-7386 | william.barnhill.ctr@rl.af.mil | barnhill_william@bah.com >> >> ------------------------------ >> *From:* drummond.reed@gmail.com [drummond.reed@gmail.com] On Behalf Of >> Drummond Reed [drummond.reed@xdi.org] >> *Sent:* Friday, January 15, 2010 5:12 AM >> *To:* OASIS - XDI TC >> *Subject:* [xdi] Inference and equivalence defintion/notation (and $has) >> >> Bill, >> >> >> >> In thinking about your definitions of "logical equivalence" and "resolution >> equivalence" today, I'm wondering if we couldn't just use the terms >> "inference" and "equivalence". In other words, it is easier for me to >> understand the differences between the sentence "XDI statement A infers XDI >> statement B" and the sentence "XDI statement A is equivalent to XDI >> statement B". >> >> >> >> My understanding of inference is that it can be unidirectional (A infers B >> but B does not infer A) or bi-directional (A infers B and B infers A). >> >> >> >> My understanding of equivalence is that it must be bidirectional, i.e., if >> A is equivalent to B then B MUST be equivalent to A. This is the purpose of >> XDI $is statements – they express equivalence between an XDI subject and and >> XDI object. >> >> >> >> If you agree these terms will work, let's use your proposed notation: >> >> >> >> Unidirectional inference <= or => >> >> Bidirectional inference <=> >> >> Equivalence = >> >> Non-equivalence /= >> >> >> >> With that said I can restate the first part of the final conclusion of >> today's telecon (see >> http://lists.oasis-open.org/archives/xdi/201001/msg00046.html for the chat >> transcript) as saying that: >> >> >> >> +a/$has/+b <=> (+a/+b) <=> +a/+b <=> +a+b >> >> >> >> This is true because each infers the other, and all these inferences are >> bidirectional (I think). >> >> >> >> This would also imply that: >> >> >> >> +a <=> (+a) >> >> >> >> Again, this is because each implies the other (I have one small reservation >> about this but I'll save that for another time). >> >> >> >> And part two of our final conclusion of the telecon was that: >> >> >> >> +a /= (+a) >> >> >> >> This is true because as you described resolving (doing a $get) on +a and >> (+a) respectively would not return the same graph. >> >> >> >> Lastly, we can finally get to the definition of $has and $has$a statements. >> What I have been saying (but not expressing with the proper notation) is: >> >> >> >> +a/$has/+b = (+a/+b) = +a+b >> >> >> >> +a/$has/+b /= +a/+b >> >> >> >> +a/+b /= +a+b >> >> >> >> +a/$has$a/+b = +a/+b >> >> >> >> +a/$has$a/+b /= (+a/+b) >> >> >> >> Do you agree? >> >> >> >> =Drummond >> >> >> >> >> >> >> >> >> > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]