[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xdi] Proposal for separation of subject/predicate and parent-subject/child-subject semantics
From a $get perspective that answer makes sense, but I believe the distinctions and connections between logically equivalent and resolution equivalent that we discussed a while ago (1 month, 2?) still hold. What I think may be the problem is $get. If the result of $get A is C and the result of $get B is C then A is resolution equivalent to B. This means that $get defines resolution equivalence, not logical equivalence. AFAIK we have not in the TC spec'd an op that defines logical equivalence and I think if we did that might solve this problem. I propose $ask, which returns a boolean result, true iff the XRIs represented by the parameters are all implied by the graph (NOT necessarily resolvable in the graph). So... ($get(A) == C) && ($get(B)==C) <==> A is resolution equivalent to B ($ask(A) == C) && ($ask(B)==C) <==> A is logically equivalent to B, i.e. A implies B and B implies A Both of above <==> A is equivalent (i.e. both logically and resolution) to B Further propose $ask$and which has the same behavior as $ask (? need to think on that ?), and $ask$or which returns true iff AT LEAST ONE of the XRIs is implied by the graph, and $ask$xor for at most one XRI, and $ask$XXX$not which gives the negated behavior for each XXX of and, or, xor. Kind regards, Bill Barnhill Booz Allen Hamilton - Rome, NY 315-330-7386 | firstname.lastname@example.org | email@example.com ________________________________________ From: firstname.lastname@example.org [email@example.com] On Behalf Of Markus Sabadello [firstname.lastname@example.org] Sent: Thursday, April 22, 2010 4:54 AM To: Drummond Reed Cc: Giovanni Bartolomeo; OASIS - XDI TC; Barnhill, William [USA] Subject: Re: [xdi] Proposal for separation of subject/predicate and parent-subject/child-subject semantics Yep that's the answer I expected.. My current implementation would return an empty graph to that XDI message. But I was wondering what Giovanni's answer would be.. Markus On Thu, Apr 22, 2010 at 9:52 AM, Drummond Reed <email@example.com<mailto:firstname.lastname@example.org>> wrote: It's late so I will just put short replies inline. On Wed, Apr 21, 2010 at 9:11 AM, Markus Sabadello <email@example.com<mailto:firstname.lastname@example.org>> wrote: So if I send the following XDI message to an endpoint: =markus $add / =markus +email "email@example.com<mailto:firstname.lastname@example.org>" and then I send this XDI message: =markus $get / =markus+email What will be the XDI response? Markus Markus, my answer is that the answer to the query (your second message) would be no such subject exists (in other words, the response would be null). In order to get a response to the second query, you would have to first made this operation: =markus $add / =markus+email ... where ... is whatever the contents of the subject =markus+email is. Giovanni, I understand what you are saying below, but you may not understand what I am saying. I am saying that +a/+b and +a+b are neither logically equivalent or resolution equivalent. I am only saying that they are semantically linked - in other words, that if you have +a/+b in the graph, it implies that +a+b would be a semantically valid XRI in the graph, and vice versa. However it does NOT imply that +a+b exists, or vice versa. The reason this is semantically consistent -- and I agree with you that of course XDI needs semantic consistency -- is because in the analysis I have been doing of the implications of what it would mean IF +a/+b and +a+b were logically equivalent, I keep finding deeper and deeper problems. I don't have time to go into in more deeply now, but I would summarize that the golden triangle model I posted yesterday reveals the crucial difference between $has, as a predicate that identifies another predicate, and $has$a as a predicate that identifies an object. Because of this, $has and $has$a, as now proposed (vs. some of the discussions of this topic over the last year that you reference below) are not logically equivalent, and thus obviously not resolution equivalent either. Let's definitely make this the subject of tomorrow's XDI TC telecon. Talk to you then, =Drummond On Wed, Apr 21, 2010 at 11:10 AM, Giovanni Bartolomeo <email@example.com<mailto:firstname.lastname@example.org>> wrote: Hello Markus and Drummond, thanks for your replies. I think there is however some confusion which I want to clarify once for all. I'm not saying that +a/+b is resolution equivalent to +a+b. I think we are now all agreeing on this (at least I think :-). Logical equivalence is a different concept. It means that if +a/+b is resolvable then also +a+b must be. Note that they DO NOT resolve to the SAME node (this is instead resolution equivalence). The requirement I'm talking about (if +a/+b is resolvable then also +a+b must be and viceversa) is needed to ensure consistency in my semantic model. For instance, having in a graph =example $has +email will allow to deal with =example+email as the set of emails which =example owns (=example+email), and consequently make assertions on them (pls refer to http://lists.oasis-open.org/archives/xdi/201004/msg00004.html for details on this, btw I can clarify them in next phc). This is also highlighted in point 1) of http://lists.oasis-open.org/archives/xdi/201003/msg00014.html. Note that resolution of certain statements is needed, even if not asserted in the graph, but inferred using a reasoner (again pls refer to my mail for details) in order to implement what we have discussed in http://lists.oasis-open.org/archives/xdi/201001/msg00047.html =bill.barnhill: We can get the graph containing statements about any statement in the graph, and that graph will only exist if and only if the statement is in the graph. put more simply (+a/+b) is resolvable, or R(+a/+b) = True. Generalizing this we see that if R(X) = True then R((X)) = True, meaning and (X) are logically equivalent Drummond: It seems the import of what you are saying is that +a <=> (+a) giovanni: resolution = your statement is true; fault = your statement is false =bill.barnhill: but not +a = (+a) Drummond: Yes! Drummond: A $is statement in an XDI graph establishes what Bill calls "resolution equivalence" where we used symbol <=> to address logical equivalence, and = to address resolution equivalence. Now my point is: either the TC has a different semantic model to propose for XDI (in this case, I would be glad to know more and discuss about it), or the TC wants to discard semantic consistency for XDI. If the latter is the case, then, frankly, I think the TC is underestimate a tremendously powerful feature which could instead change the whole concept of web applications in next few years. Please let me know your opinion about it. Thank you, Giovanni Def. Quota "Markus Sabadello" <email@example.com<mailto:firstname.lastname@example.org>>: What I'm afraid of is that people will never understand resolution equivalence, and that it would be difficult to implement at the storage and messaging levels of an XDI stack. Can't we just have logical equivalence without resolution equivalence? On the logical level a high level application/reasoner/etc can infer lots of stuff based on some $is, $has, $is$a, etc rules we make up, but I'm really a bit scared of having to implement such extra XDI "magic" just for plain XDI storage and messaging.. Markus On Tue, Apr 20, 2010 at 5:21 PM, Giovanni Bartolomeo < email@example.com<mailto:firstname.lastname@example.org>> wrote: Dear Drummond, All, thank you for this proposal - two main thoughts from my side: 1) it is FUNDAMENTAL that if +a/+b is resolvable then also +a+b MUST be, and viceversa. We used the symbol <==> to say this, +a/+b <==> +a+b. Obviously the stored document can only contain one of the two, e.g. the document only contains +a/+b, but +a+b MUST be resolvable as well. This is about the relationship between asserted and inferred statements which I illustrated in the second part of my email http://lists.oasis-open.org/archives/xdi/201004/msg00004.html - we didn't discuss this yet because we ran out of time last week, but it would be good to address this in next phc. 2) About the following statements (in which the symbol <==> is used in a somehow different way than in point 1) +a/$has/+b <==> +a/+b +a/+/+b <==> +a+b +a/$/$b <==> +a$b +a/=/=b <==> +a=b +a/@/@b <==> +a@b +a/*/*b <==> +a*b +a/!/!b <==> +a!b +a/()/(b) <==> +a(b) note that the statements on the left side in their own give origin to metastatements like +a/$has/+, +a/$has/$, +a/$has/() which in turns are logically equivalent to +a+, +a$, +a() whose semantics is totally unknown to me. Kind Regards, Giovanni Def. Quota "Drummond Reed" <email@example.com<mailto:firstname.lastname@example.org>>: Per my action item from Thursday's telecon, following is more about my analysis and proposal for solving the "$has semantics problem" once and for all. *** ANALYSIS *** My first conclusion, on which I think we all agree, is that while +a+b might imply +a/+b and vice versa, that does not mean that: a) they have the same semantics, or b) that they identify the same XDI graph. Indeed, since one is an XDI subject and the other adds an XDI predicate, by definition they cannot identify the same XDI graph. To illustrate in English, most English verbs can be made into nouns by putting them in their infinitive form (“to be”, “to run”, “to shout”). But “run” and “to run”, while clearly linked semantically, do not have the same meaning. They cannot be interchanged with each other. Thus my second conclusion is that none of the three XDI graph examples we were discussing on our telecon two weeks ago were in fact equivalent. They were each different XDI graphs that had similar but not identical semantics. My third conclusion is that this means that we do in fact need clearly distinguished ways of semantically and syntactically of expressing that an XDI subject (e.g., +a) : 1) has a child subject (e.g., +a+b), and 2) has a predicate (e.g., +a/+b). My fourth conclusion was that this is the problem we have been struggling with for the last year: by using $has (with or without variants like $has$a) to express both parent subject/child subject relationships (+a+b) and subject/predicate relationships (+a/+b), we have wrapped ourself in a classic Gordian knot. *** PROPOSAL *** Once the problem was framed this way, it became much easier (for me anyway) to see that a clean solution would be to dedicate the $has predicate to only one semantic – either the parent subject/child subject relationship or the subject/predicate relationship. Of those two options, I strongly prefer dedicating the $has verb to expressing the subject/predicate relationship (+a/+b), since this is the simpler and more intuitive to understand, and mirrors the semantics of the $a predicate, which expresses predicate/object relationships. If $has is dedicated to that expression, then we simply need a different predicate (or set of predicates) to express parent subject/child subject relationships. For that, an obvious answer is to use XRI delimiters as predicates. This is intuitive since it is syntactically required to have a delimiter between XRI subsegments, and each of the six XRI delimiters (not counting parentheses for cross-references) has its own XRI-defined "semantics", e.g., * means reassignable identifier, ! means persistent identifiers, etc. So to summarize using +a and +b notation: +a/$has/+b <==> +a/+b +a/+/+b <==> +a+b +a/$/$b <==> +a$b +a/=/=b <==> +a=b +a/@/@b <==> +a@b +a/*/*b <==> +a*b +a/!/!b <==> +a!b +a/()/(b) <==> +a(b) Semantically, it would still be true that +a+b/$is$a/+b (and the inverse that +b/$a/+a+b). And while +a+b would imply that +a/+b is valid, and vice versa, the existence of one in an XDI graph would not imply the existence of the other. So, if =example wanted to do a query to determine if +a+b and +a/+b both existed in an XDI graph, it would be: =example $get / +a $has +b + +b I have been trying out this proposal in sample XDI documents for the past week and it seems to work very well. Please consider and experiment with it and post your thoughts. We'll put it on the agenda for next week's telecon. =Drummond --------------------------------------------------------------------- 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 ---------------------------------------------------------------- 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 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]