OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xdi] Inference and equivalence defintion/notation (and $has)


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
 

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

 

 

           

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]