[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)
Dear Bill, good questions which could open a long discussion. Anyway please find some first quick thoughts below... Best Regards, Giovanni > 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? To me they are synonyms, see below why I believe this. > > 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. This is the case if we state that !1234 and =bill are synonyms and that =eng and !1234 are synonyms. In my view, =bill, =eng, !1234 (is that correct or =!1234 is the correct form?) are all XRI addresses which are synonyms, i.e. that resolve to the *same* *node* in the global graph. [I deliberately leave open the matter of what is a node and which identifier/address it is assigned - to me it depends on the binding context (likely http) just as a XRI depends on the binding context to turn into a concrete identifier, but this is another topic. When the binding is chosen you can then resolve the XRIs. If they *resolve* to the same http address, e.g., they are "resolution equivalent". As before stated, synonyms must always resolve to the same node and thus to the same http addresses and therefore I call them "resolution equivalent"]. > 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. > I agree that synonyms are not at all a way to model different personas. About how to model personas in XDI there is a thread started here http://lists.oasis-open.org/archives/xdi/201011/msg00024.html and not yet closed. Please see also my replies at http://lists.oasis-open.org/archives/xdi/201011/msg00030.html and http://lists.oasis-open.org/archives/xdi/201011/msg00031.html. These clearly show that personas are not treated as synonyms. > 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 ? Both mechanisms are useful, but in different situations. I've tried to explain before how synonyms (owl:sameAs) and "resolution equivalence" are bound together. Narrowing and broadening are something which I wouldn't call "equivalence" (lacking of the transitive property which is instead in any equivalence relationship), but, yes, they could be useful concepts to include. As regarding symbols, $= could be a choice for synonymity, provided we need one (we could simply leave a xref to owl:sameAs instead...) > 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 > > > ---------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]