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)


Giovanni,

I'm missing something. The whole premise of $has statements is that they produce a new XDI subject which is the concatenation of the $has subject and the $has object.

So why do you say +a/$has/+b != +a+b ?

=Drummond

On Sun, Jan 17, 2010 at 1:52 PM, Giovanni Bartolomeo <giovanni.bartolomeo@uniroma2.it> wrote:
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.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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