[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xdi] about addresses, synonyms and equivalence (was: Re:Agenda: XDI TC Telecon Thursday 1-2:30PM PT 2011-03-24)
Another thought to consider regarding synonyms... Given =abc/$/=!1234, is =abc always resolution equivalent to =!1234, or is this resolution equivalent scoped to the context of the requester? Example: Let's say I have two personas, =eng and =bill. The current method reveals the i-number via =bill/$/!1234 when the =bill graph is queried. If the requester has the permissions to see =bill and =eng from the same data authority, but not the link between them, then there's a problem when =eng/$/!1234 is seen, because !1234/$$/=eng is implied and from that =bill/$/=eng, if resolution equivalence is a symmetric relation. To get around that personas can't be synonyms they have to be sub-contexts (i.e., narrowing of the meaning of the specific individual). That means =eng/$/=!5678 and =bill/$/=!1234. So then is =eng/$/=bill if you can see the whole graph? I wouldn't think so. The point I'm trying to make is logical equivalence vs resolution equivalence: should resolution equivalence really be a symmetric relation and defined similar to owl:sameAs, or an asymmetric relation and defined similar to skos:narrows? I think the skos:narrows approach actually could give us nearly as much semantic expressibility, perhaps more if we repurposed a second GCS to indicate narrowing/broadening(when inverted) vs equivalence ? To me '=' would fall into that well, despite my dislike of the repurposing technique it'll work - if we explain it often and early, I think. =bill/=/=!1234 -> =bill is synonym of of =!1234 =eng/=/=!5678 -> =eng is synonym of =!5678 Hidden, unless explicitly revealed via link contract... =!1234/$/=!90 -> =!1234 is a facet of =!90 (the actual person) =!5678/$/=!90 -> =!5678 is a facet of =!90 Also makes more sense to me, as my persona as =bill implies more than my persona as an engineer but =bill might be my personal not professional life, which means =eng implies more than =bill as well, so there has to be an over-arching identity gem that encompasses, but is not equal to, all these facets. Kind regards, Bill ________________________________________ From: Giovanni Bartolomeo [giovanni.bartolomeo@uniroma2.it] Sent: Tuesday, March 29, 2011 7:59 AM To: xdi@lists.oasis-open.org Subject: [xdi] about addresses, synonyms and equivalence (was: Re: Agenda: XDI TC Telecon Thursday 1-2:30PM PT 2011-03-24) Dear Drummond, let me answer your questions, with some clarifications. Let's start first from pointing out terminology: "logical equivalent" is probably not exactly what you describe, which we agreed to call instead "resolution equivalence", i.e. two addresses resolve to the SAME node (logical equivalence is a broader concept we discussed in the past, but for this discussion it is not essential, so I'll skip this part :) Coming back to the scenario, =abc and =!1234 are synonyms. As such, they are two addresses pointing at the SAME node in the graph. Analogies: two IP addresses assigned to the same host in a network or two variables pointing at the same java object in java programming. As such, they both should be resolved to the SAME node, even if they are syntactically not the same. So when you ask > So the problem is: which is it? Which of these two addresses should the XDI > software expect to find? Both of them? Does that means Is every subcontext > and/or property of every node in the graph that has a synonym logically > equivalent to having that same subcontext and /orproperty on every other > synonymous node in the graph? my answer is that in the graph there is just one node pointed by two (or more) arcs (say =abc and =!1234), not two different nodes pointed by two different arcs. Just one node for two or more addresses (called synonyms), no redundancy. The issue, instead, is how to resolve two addresses to the same node. Semantically, resolution equivalence is given by owl:sameAs, so a browser knowing that one XRI address is the same as another will interpret the two XRIs as synonyms (in its internal data structure - a partial view of the global graph - the browser will build just one single node for the two addresses). If it does not know this, it will not assume they are synonyms and treat them differently - but it cannot assume they don't are unless explicitly stated (a principle called the "open world" assumption) Now, since XRIs are by definition abstract identifiers, to perform resolution they should be bound to a concrete resolution context. If WWW is the case, the resolution mechanism is through HTTP and the resolution context, I propose, could be based on Named Graphs (I'll come back on this with a concrete proposal in next weeks) I do not totally agree with you when you say: > The reasons in both cases is that the term "synonym" (and rdf:sameAs) > implied full logical equivalence -- essentially a merger of the graph trees > for both nodes. This is a beautiful concept, but very hard to implement (as > RDF folks have found out). clarified that what is described is "resolution equivalence", which is, as you describe, merging nodes from different trees to build the global graph, it is useful to point out that this mechanism is the very foundation of Linked Data: without merging there is no linking, so we cannot get rid of this. What we can do better than Linked Data (hopefully) is to clarify (at least some of) the many different usages of resolution equivalence (owl:sameAs) - as it has been pointed out in the paper by Halpin, Herman and Hayes (http://www.w3.org/2009/12/rdf-ws/papers/ws21) and internally discussed during many of our phcs. Best Regards, Giovanni Def. Quota "Drummond Reed" <drummond.reed@xdi.org>: > > The use case is that you have two nodes in the graph with two XRIs, and you > want to say that each is a synonym for the other. Let's say the first one is > =abc and the second is =!1234. > > If each of them is a synonym for the other -- so they are completely > logically equivalent -- then XDI software has no way of knowing which of the > two addresses should be used to continue traversing the graph below either > of these context nodes. For example, say you have =abc+age. If both =abc and > =!1234 are synonyms for each other, i.e. > > =abc/$/=!1234 > =!1234/$/=abc > > Then when XDI software sees the address =abc+age, it should be equivalent to > =!1234+age. > > So the problem is: which is it? Which of these two addresses should the XDI > software expect to find? Both of them? Does that means Is every subcontext > and/or property of every node in the graph that has a synonym logically > equivalent to having that same subcontext and /orproperty on every other > synonymous node in the graph? > > That problem proved to be intractable in XRI 2.0 resolution -- it was very > difficult for software to build such a globally redundant graph and keep it > logically consistent. > > The solution is canonical addressing. In canonical addressing, every context > node in the graph has exactly one primary address, and zero-or-more > secondary addresses. The path from a secondary address to a primary address > is expressed using a relational arc with the XRI $ (mnemonic: primary = 1 = > $). The path from a primary address to a secondary address is expressed > using a relational arc with the XRI $$ (mnemonic: secondary = 2 = $$). > > If you apply this rule to our use case, the relationship of =abc and =!1234 > is now: > > =abc/$/=!1234 <-- =abc has the primary address =!1234 > =!1234/$$/=abc <-- =!1234 has a secondary address =abc > > Now, if XDI software sees the XDI address =abc+age, it can traverse the > graph to the =abc node, see the $ relational arc (of which by definition > there can be only one), and know that it MUST follow that arc before > continuing traversal of any subsegment or segment beyond =abc. > > So now the answer to "where is =abc+age?" is, "since =abc maps to =!1234, > =abc+age maps to =!1234+age, and =!1234+age is the only place you'll find > that info in the graph". > > Lastly, a note about terminology. Because of the directionality of the > mapping between primary and secondary addresses, I believe: > > 1. It is inaccurate to continue to use the term "synonym" to describe > either a primary address or a secondary address. > 2. It is no longer exactly the same semantics as rdf:sameAs. > > The reasons in both cases is that the term "synonym" (and rdf:sameAs) > implied full logical equivalence -- essentially a merger of the graph trees > for both nodes. This is a beautiful concept, but very hard to implement (as > RDF folks have found out). > > So my recommendation is that we simply drop the term "synonym" at this point > and only use the terms "primary address" and "secondary address" per the > rules defined above. > > Hope this helps, > > =Drummond > > > On Mon, Mar 28, 2011 at 1:19 PM, Giovanni Bartolomeo < > giovanni.bartolomeo@uniroma2.it> wrote: > >> Dear Drummond and All, >> >> I have one question about the primary/secondary synonym mechanism you >> introduced. >> >> You said: "The main problem it solves is adding directionality and >> precedence to synonyms [...] to resolve the question of where further >> resolution of the XDI graph should continue after a synonym is encountered". >> >> But, as we stated that two synonyms point at the same node, once we have >> the synonym, then we have the node. If the synonym is an XRI cross ref to an >> http address, for example, then the http resolution will be used, and the >> node will be found. Same as for any other resolution protocol different than >> http which that XRI could be bound to. >> >> So why do we need the primary/secondary synonym mechanism? And what do you >> mean exactly by "further resolution"? >> >> Best Regards, >> Giovanni >> >> >> Def. Quota "Drummond Reed" <drummond.reed@xdi.org>: >> >> >> Following are the minutes of the unofficial telecon of the XDI TC at: >>> >>> Date: Thursday, 24 March 2011 USA >>> Time: 1:00PM - 2:30PM Pacific Time (21:00-22:30 UTC) >>> >>> ATTENDING >>> >>> Bill Barnhill >>> Joseph Boyle >>> Michael Schwartz >>> Drummond Reed >>> Giovanni Bartolomeo >>> >>> >>> THE IDEARPAD LINK FOR TODAY IS: >>> http://xdi.idearpad.org/26 >>> >>> >>> 1) REVISED XDI GRAPH PATTERN DOCUMENT >>> >>> Drummond upload a new version with two key revisions: >>> >>> - A new primary/secondary addressing pattern to solve the key issue with >>> the synonym pattern that we discussed last week. >>> >>> >>> - One key revision to the versioning pattern suggested by Bill. >>> >>> >>> Drummond explained the primary/secondary address proposal. The main >>> problem >>> it solves is adding directionality and precedence to synonyms. By using >>> relational arcs identified with $ to identify the relation of a secondary >>> address to a primary address, we provide the semantics necessary to >>> resolve >>> the question of where further resolution of the XDI graph should continue >>> after a synonym is encountered. The rule is: >>> >>> >>> - If a context node has a $ relational arc (and it can have exactly zero >>> or one $ arc), then it is a secondary address, and resolution should >>> continue at the object of that arc, which is a primary address. >>> >>> >>> - If a context node has one or more $$ relational arcs, they are >>> secondary addresses for the context node, and resolution of the graph >>> should >>> continue from the original primary address. >>> >>> >>> Bill said we should add a comment about the meaning of the two top graph >>> segments on the "Primary and Secondary Addresses page" that specifies that >>> these segments are "addresses of the root context of the graph". >>> >>> # DRUMMOND will make this revision. >>> >>> We also went over the revision to the versioning pattern. Drummond pointed >>> out that the pattern, which is simply to treat the current version in the >>> version tree as a reference (instead of making a duplicate copy of the >>> data), is the same across all the versioning examples. >>> >>> Mike asked about and we went over the differences between the simple >>> property graph, the complex property graph, the simple subject graph, and >>> the complex subject graph. >>> >>> >>> 2) IMPLEMENTATION PROJECTS >>> >>> Mike reported that OpenXDI is proceeding full steam. Gluu has just hired >>> another key programmer to work on the project who will be a dedicated >>> resource. OpenXDI calls will continue to be held on Fridays at 10AM PT. >>> >>> The goal of OpenXDI is to produce both client code and a server, including >>> a >>> way to quickly set up a cloud server. The project will also support XRI >>> resolution. >>> >>> The server will be in Java, and the client will use the Python API. Mike >>> would like to build the equivalent of LDAP search. >>> >>> He has also commissioned a logo for the short name of the project, "OX". >>> >>> Bill gave an update that he is finalizing plans on what he will be doing. >>> He >>> has been looking over the Locker Project, Jeremie Miller's new open source >>> effort to build a personal data locker. Currently it has connectors and >>> apps. Apps will be coming from third-party developers. Connectors are ways >>> to be tapping personal data and bringing them into the store. Connectors >>> currently exist for most social networks. >>> >>> Bill said the Locker Project has its own file system. >>> >>> Joseph is also playing with the Locker Project code. He and Bill discussed >>> creating an XDI app for Locker that could access and manipulate the Locker >>> data as an XDI graph. >>> >>> We discussed the philosophy of first pulling everything into JSON and then >>> subsequently worrying about semantics. That may be in fact be nicely >>> complementary to XDI since we are tackling the latter problem. >>> >>> >>> 3) XDI STATEMENTS FOR EACH GRAPH PATTERN EXAMPLE >>> >>> We need to produce a collection of XDI statements representing each of >>> the >>> graphs in the XDI Graph Patterns collection. This needs to happen soon so >>> it >>> can be pulled into the XDI Graph Model document. >>> >>> Drummond asked for volunteers to help him with this. Bill volunteered >>> since >>> he's doing it anyway. Mike volunteered one of the OX developers. >>> >>> We also discussed whether a flat list of XDI graph statements might not >>> itself be a very simple and efficient XDI serialization format (e.g., in >>> comparision to the JSON format) because it so easy to compress, and it is >>> already "pre-indexed". We agreed to discuss this further after we have >>> produced the XDI statement lists for each of the XDI Graph Pattern >>> examples. >>> >>> >>> 4) XDI MESSAGING PATTERN >>> >>> We agreed to discuss this pattern next week. >>> >>> >>> 5) NEXT CALL >>> >>> The next call is next week at the regular time. >>> >>> >>> ------------ >>> ONGOING ISSUES LIST >>> >>> Each of these is a candidate for the agenda for future calls. >>> >>> * TRANSACTIONAL INTEGRITY FOR XDI >>> >>> Since versioning, as one example, involves multiple transactions that must >>> be commited as a group, we will need to address transactional integrity. >>> Specifically, we need to define how this will be handled at the protocol >>> level, vs. the implementation level. >>> >>> * PROPOSED CONSTRUCTS/OPERATORS FOR XDI >>> >>> Discuss the following wiki page originally posted by Giovanni: >>> >>> http://wiki.oasis-open.org/xdi/XdiNewFoundation >>> >>> * DICTIONARY STRUCTURE >>> >>> Mike would like an example of the PDX dictionary as soon as we can do it. >>> >>> * EQUIVALENCE SEMANTICS >>> >>> Close on whether we need an additional $ word that is the equivalent >>> of Higgins Personal Data Model (PDM) semantics of h:correlation, >>> which is not as strong as $is. >>> >>> http://lists.oasis-open.org/archives/xdi/201006/msg00036.html >>> >>> * COOL URIS >>> >>> Continue previous discussion about the use of standard RDF URIs in XDI: >>> >>> http://lists.oasis-open.org/archives/xdi/201006/msg00023.html >>> >>> >> >> >> ---------------------------------------------------------------- >> Invito da parte dell'Ateneo: >> Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del >> tuo aiuto. Dona il 5 x mille all'Universita' di Roma Tor Vergata >> codice fiscale: 80213750583 http://5x1000.uniroma2.it >> >> > ---------------------------------------------------------------- Invito da parte dell'Ateneo: Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del tuo aiuto. Dona il 5 x mille all'Universita' di Roma Tor Vergata codice fiscale: 80213750583 http://5x1000.uniroma2.it ----- Fine messaggio inoltrato. ----- ---------------------------------------------------------------- Invito da parte dell'Ateneo: Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del tuo aiuto. Dona il 5 x mille all'Universita' di Roma Tor Vergata codice fiscale: 80213750583 http://5x1000.uniroma2.it --------------------------------------------------------------------- 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]