[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] A different perspective on * and /
So, if you are trying to express the *relationship* between A and B, we have RDF. An RDF statement is an expression of a relationship between a resource (identified with a URI) and another resource (identified with a URI) or a text string. The relationship itself is identified by a URI. Furthermore, the statement itself can be given an identifier (reified) and then you can talk about the statement in other statements. So you have, really, 3 things to talk about when talking about relationships - subject, object, and the type of relationship. As I say in the previous paragraph, you can give that statement (the expression of the relationship) an identifier. Any identifier - XRI, HTTP URL, UUID, etc. I'm still not seeing how this is related to XRI syntax. Are you asking about how we might take the relationship and *encode* it in XRI? That is, are you asking about the ability for me to encode, in an XRI, the statement: "The/a relationship between A and B of type X"? If you were to go there, then we could do this (where x,a, and b are the URIs for X, A, and B respectively): xri:+relationship/(x)/(a)/(b) And then if you wanted to say "The relationship between A and B of type X in the context of document D": xri:@D/(+relationship/(x)/(a)/(b)) I'm not suggesting this is the best (or even a good) way to do this, just trying to suggest *one* way of doing things. -Gabe __________________________________________________ gwachob@visa.com Chief Systems Architect Technology Strategies and Standards Visa International Phone: +1.650.432.3696 Fax: +1.650.554.6817 > -----Original Message----- > From: Marc Le Maitre [mailto:marc.lemaitre@cordance.net] > Sent: Monday, June 14, 2004 11:20 AM > To: Wachob, Gabe; 'Dave McAlpin'; 'Drummond Reed'; > xri@lists.oasis-open.org > Subject: RE: [xri] A different perspective on * and / > > > Based on your feedback maybe I should have asked the question slightly > differently: > > Q: Is there value (independent of the ability to identify > Resource A and > Resource B) in being able to express the relationship (link might be a > weaker way of saying the same) between A and B so that we are > able, through > the core advantages of XRIs, to address the source of authority and > permission in a data sharing relationship in the same way we > are able to > address the data being shared? > > I don't know the impact on the XRI scheme of enabling such a > capability and > whether it is too major to be addressable in the next > revision we propose. I > just wanted to consider the value before delving into the > "how we might do > it" discussion. > > Marc > > > > -----Original Message----- > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Monday, June 14, 2004 1:46 PM > To: marc.lemaitre@cordance.net; Dave McAlpin; Drummond Reed; > xri@lists.oasis-open.org > Subject: RE: [xri] A different perspective on * and / (long) > > You are asking about reifying the *link*, which is a totally > appropriate and > relevant question. > > I'm not sure this is strictly an XRI issue. It really has to > do with a) what > type of document the link appears in, and b) what do we mean > by a link. > > There are many different types of links. HTML <a href> tags > are one kind. > XLINK elements are another. One could argue that URI > references in RDF are > links. One could argue that XDI contracts are links. And I've > only talked > about XML documents - what about "links" in non-XML formats? > > So I don't know that there is a general answer. At least not without a > general definition of a "link". > > One more thing - if you are talking about the link, then > simply using the > URI that is the *target* of the link (ie the place being > pointed to) is not > really a good idea. Concretely, if I have document A, which > contains link L > pointing to document T, then I don't want to refer to L using > any part of > T's identifier. This is because if T's identifier changes, > L's value perhaps > would change (perhaps not), and I still want to be able to > refer to the > *link*, no matter what it changes to. > > If we limited ourselves to identifying XML elements as links (that is, > assume a "link" correlates to a specific XML element), then > the process of > identifying a "link" is no more complicated than identifying > an XML element, > for which there are at least a couple of ways: ID attributes > (xml:id or > other), XPATH, or some custom attribute... all of which can be used to > construct an XRI (using # fragment notation, for example). > > -Gabe > > __________________________________________________ > gwachob@visa.com > Chief Systems Architect > Technology Strategies and Standards > Visa International > Phone: +1.650.432.3696 Fax: +1.650.554.6817 > > > > -----Original Message----- > > From: Marc Le Maitre [mailto:marc.lemaitre@cordance.net] > > Sent: Monday, June 14, 2004 10:29 AM > > To: 'Dave McAlpin'; Wachob, Gabe; 'Drummond Reed'; > > xri@lists.oasis-open.org > > Subject: RE: [xri] A different perspective on * and / (long) > > > > > > > > Can I ask the question in a slightly different way? > > > > Using and slightly reworking Drummond's words: > > If there were a way of using conventional URIs, to address > > the LINK between > > two web pages (not the URI of Page A or the URI of Page B, > > but the LINK from > > Page A to Page B) would this be of value? > > > > I'd really like to hear the group's thoughts on this question > > and then, > > based on the answer, delve into how such a relationship might > > be manifested > > in XRI syntax. > > > > Marc > > > > > > > > > > > > -----Original Message----- > > From: Dave McAlpin [mailto:Dave.McAlpin@epok.net] > > Sent: Monday, June 14, 2004 12:50 PM > > To: Wachob, Gabe; Drummond Reed; xri@lists.oasis-open.org > > Subject: RE: [xri] A different perspective on * and / (long) > > > > Can you also talk about how this would affect resolution of relative > > references, which currently depends on an unambiguous hierarchical > > structure based on slash? > > > > Dave > > > > > -----Original Message----- > > > From: Wachob, Gabe [mailto:gwachob@visa.com] > > > Sent: Monday, June 14, 2004 9:46 AM > > > To: Drummond Reed; xri@lists.oasis-open.org > > > Subject: RE: [xri] A different perspective on * and / (long) > > > > > > I hadn't realized this was the proposal. > > > > > > How would this affect XRI resolution? What marks the end of the ID > > > Authority? If the two delimiters are *truly* equal, then it > > would seem > > > that the first of either of them would mark the end of the > > authority, > > but > > > that means that * couldn't be used as an authority delegation > > character. > > > > > > If the "/" still marks the end of the authority, then it seems a > > little > > > odd since we're basically saying the two delimiters really aren't > > > equivalent. > > > > > > Explain please ;-) > > > > > > -Gabe > > > > > > > > > __________________________________________________ > > > gwachob@visa.com > > > Chief Systems Architect > > > Technology Strategies and Standards > > > Visa International > > > Phone: +1.650.432.3696 Fax: +1.650.554.6817 > > > > > > > > > > -----Original Message----- > > > > From: Drummond Reed [mailto:drummond.reed@cordance.net] > > > > Sent: Sunday, June 13, 2004 11:22 PM > > > > To: xri@lists.oasis-open.org > > > > Subject: RE: [xri] A different perspective on * and / (long) > > > > > > > > > > > > That's a good one, Gabe - "failing to connect the dots" ;-) > > > > > > > > Anyway, to answer your question, the impact on the BNF is > > > > that star would > > > > now have an equal footing with slash. Either could be used to > > > > delimit a > > > > "segment", and either could be followed by a colon to denote > > > > a persistent > > > > segment (with the absence of a colon as the first character > > > > of the segment > > > > meaning the segment is reassignable). > > > > > > > > This is a significant simplification because "subsegments" go > > > > away. Now > > > > there would be just star segments and slash segments and they > > > > would both > > > > behave identically. The xri-segments production would become: > > > > > > > > xri-segments = [ ":" ] segment-value *( ( "/" / "*" ) [":"] > > > > segment-value ) > > > > segment-value = 1*xri-pchar / xref > > > > > > > > =Drummond > > > > > > > > -----Original Message----- > > > > From: Wachob, Gabe [mailto:gwachob@visa.com] > > > > Sent: Friday, June 11, 2004 10:19 AM > > > > To: Drummond Reed; xri@lists.oasis-open.org > > > > Subject: RE: [xri] A different perspective on * and / (long) > > > > > > > > Drummond- > > > > Somewhere along the line, I'm failing to connect the > > > > dots. While I > > > > understand the idea that peer-links should be representable > > > > in XRIs, and I > > > > understand your proposal of using syntax to do this, I'm not > > > > understanding > > > > how this impacts the */: vs. *:/*. discussion.. > > > > > > > > -Gabe (who never admits to things he thinks > about at 4am ;-) > > > > > > > > > > > > __________________________________________________ > > > > gwachob@visa.com > > > > Chief Systems Architect > > > > Technology Strategies and Standards > > > > Visa International > > > > Phone: +1.650.432.3696 Fax: +1.650.554.6817 > > > > > > > > > > > > > -----Original Message----- > > > > > From: Drummond Reed [mailto:drummond.reed@cordance.net] > > > > > Sent: Friday, June 11, 2004 9:10 AM > > > > > To: xri@lists.oasis-open.org > > > > > Subject: [xri] A different perspective on * and / (long) > > > > > > > > > > > > > > > I realize I am in the minority in the perspective I'm sharing > > > > > on the * vs. : > > > > > issue. In the message below Peter adds his vote along with > > > > Gabe, Mike, > > > > > Loren, and Dave to the preference to use both * and : as > > > > "second-level > > > > > hierarchy characters", whereas I am advocating using just *. > > > > > > > > > > However after a conversation Dave and I had about this late > > > > > yesterday, I > > > > > woke up thinking about it at 4am this morning and came to a > > > > > much deeper > > > > > understanding of why there appears to be such a huge gap > > > > > between these two > > > > > perspectives. Since I couldn't get back to sleep, I'll try to > > > > > explain it > > > > > here. > > > > > > > > > > First, just to make it clear, I agree with everyone that if > > > > > the choice is > > > > > simply between the "readability" of the two examples given > > > > > below, i.e.: > > > > > > > > > > xri:@:3*:4*:5/:6*:7 > > > > > or > > > > > xri:@:3:4:5/:6:7 > > > > > > > > > > ...then of course it appears to be a no-brainer. The latter > > > > > is more compact > > > > > and, as Peter says, "much easier to read". > > > > > > > > > > But therein lies the issue. What is "easier to read" depends > > > > > on what you are > > > > > reading for. What I realized laying in bed at 4am this > > > > > morning is that I am > > > > > reading for something entirely different. But to explain > > > > this requires > > > > > explaining the entire worldview behind this perspective, and > > entire > > > > > worldviews are not easy to explain, so please bear with me > > > > > while I try. > > > > > > > > > > In this second worldview, * would not be considered a > > > > > "secondary hierarchy > > > > > character", but an "alternative hierarchy character" on an > > > > > equal footing > > > > > with slash. > > > > > > > > > > I can just hear Dave screaming right now, "What does Drummond > > > > > mean, 'an > > > > > "alternative hierarchy character" on an equal footing with > > > > > slash'?? How > > > > > could there be such a thing? Slash is THE 2396 hierarchy > > > > character! It > > > > > defines 2396 segments. The only option we have is to define > > > > > subsegments > > > > > within slash segments!" > > > > > > > > > > But this is exactly what I mean about two entirely different > > > > > worldviews. In > > > > > the 2396 worldview the world is purely hierarchical. There is > > > > > only slash > > > > > because there is only hierarchy. > > > > > > > > > > It's pretty ironic, then, that URIs based on 2396 are the > > > > > very basis of the > > > > > World Wide Web, which is the very opposite of hierarchy. It's > > > > > a peer-to-peer > > > > > web. Any page can link to any page. > > > > > > > > > > Laying in bed at 4am, I did the following thought experiment, > > "Using > > > > > conventional URIs, is there any way you can address the LINK > > > > > between two web > > > > > pages?" In other words, not the URI of Page A or the URI of > > > > > Page B, but the > > > > > LINK from Page A to Page B. Literally, the A tag present in > > > > > the HTML of Page > > > > > A that links to Page B. > > > > > > > > > > There is certainly no standard way, at least that I know of. > > > > > So I started > > > > > thinking through how you would do it. If Page A was expressed > > > > > as XHTML, then > > > > > the actual node of the XHTML document that contains the link > > > > > to Page B would > > > > > at least be addressable using an XPath expression under the > > > > > URI of Page A. > > > > > So you could have something like: > > > > > > > > > > http://www.example.com/Page-A#Xpath-to-A-tag-linking-Page-B > > > > > > > > > > Of course, there is no spec for doing this that I am aware > > > > > of. However it > > > > > wouldn't be hard to construct one. Since you know the link is > > > > > in an A tag, > > > > > you'd just need a standard XPath query that says, "Give me > > > > > the A tag whose > > > > > HREF attribute equals the following value" and then supply > > > > > the target URI as > > > > > a paremeter. Say this query was called "Xpath-A-ref". Then > > > > > any site that > > > > > supported this query could resolve a URI that looked like the > > > > > following: > > > > > > > > > > http://www.example.com/Page-A?Xpath-A-ref&HREF="http://www.sit > > > > > e.com/Page-B" > > > > > > > > > > Such an address would actually let you address Page B in the > > > > > context of Page > > > > > A. It lets you construct a path ACROSS pages, not just DOWN > > > > > the DNS tree and > > > > > local file path hierarchy to a specific page. > > > > > > > > > > Why would you want to be able to address across Web pages? If > > > > > you wanted to > > > > > be able to follow the path of who is linked to who. > It lets you > > test > > > > > assertions about relationships between pages. If the address > > > > > above resolves, > > > > > it tells you Page A is linked to Page B. If it doesn't, they > > aren't. > > > > > > > > > > Now, imagine if there was: a) a standard URI syntax character > > > > > that equates > > > > > to the link query operation "?x-path-A-ref" above, and b) a > > > > > standard way in > > > > > URI syntax to nest one URI inside another. Let's say the > > > > > standard link query > > > > > character was * and the nesting syntax was to enclose the > > > > > nested URI in > > > > > parentheses. Then the URI above could be expressed much more > > > > > compactly and > > > > > readably as: > > > > > > > > > > > > http://www.example.com/Page-A*(http://www.site.com/Page-B) > > > > > > > > > > Now let's take one more step. Say that the author of Page A > > > > > had his own name > > > > > for Page B inside the HREF tag that points to > > > > > "http://www.site.com/Page-B". > > > > > Say this name was "Glockenspiel". This is really a relative > > > > > identifier for > > > > > Page B, since it's relative to the Web page > > > > > http://www.example.com/Page-A. > > > > > But in the context of this Web page, it's very likely to be > > > > > unique, since > > > > > the author of Page A is unlikely to create two outgoing links > > > > > to different > > > > > resources on the same Web page and label both the A tags > > > > identically. > > > > > > > > > > In this case there is a second way to address the link > > > > > between Page A and > > > > > Page B using this relative identifier. This would look like: > > > > > > > > > > http://www.example.com/Page-A*(Glockenspiel) > > > > > > > > > > I know this example has been quite extensive, but as you can > > > > > see, the point > > > > > is that in this alternative worldview - this Web-based > > worldview - > > > > > peer-to-peer linking relationships have an equal status with > > > > > hierarchical > > > > > relationships. Neither is "good" or "bad". Neither is > > "primary" or > > > > > "secondary". They are simply equally valid. Like Cartesian > > > > and radian > > > > > coordinate systems, they both let you address any point on a > > > > > plane - it's > > > > > just that each one can be much more appropriate for > > certain tasks. > > > > > > > > > > It follows then that in this worldview, the primary failing > > > > > of 2396 syntax > > > > > is that it does not accommodate the peer-to-peer linking > > > > > worldview. It only > > > > > accommodates the hierarchical worldview. It has no syntax for > > > > > addressing > > > > > link relationships, nor for nesting identifiers for this > > > > > purpose (i.e., > > > > > cross-references). In syntactic terms, it has only /, and > > > > no * nor (). > > > > > > > > > > Those of you who know me know why I am so passionate about > > > > > this subject. To > > > > > get from the Web to the Dataweb, we must be able to express > > > > the links > > > > > between data and the links between data sharing authorities. > > > > > Suddenly it is > > > > > as important (if not more important) to be able to address > > > > > the source of > > > > > authority and permission in a data sharing relationship as it > > > > > is to be able > > > > > to address the data being shared. > > > > > > > > > > For example, look at the following sample XRI: > > > > > > > > > > xri:xri-A/(xri-B)*(/($contract)/this-contract/($v1))*(/(+email > > > > > )/work/($v2)) > > > > > > > > > > (Note that the values "xri-A" and "xri-B" are placeholders > > > > > for the actual > > > > > XRIs for Authority A and Authority B, and "$contract" is the > > > > > proposed XRI > > > > > service dictionary identifier for XDI link contracts.) This > > > > > is from a thread > > > > > about potential XDI contract addressing available at > > > > > http://wiki.idcommons.net/moin.cgi/DataSharing#head-0bd5430345 > > > > > 33c5641c0beacf > > > > > 65be418a7a9c7fc5. > > > > > > > > > > Although this particular example is in the context of XDI > > > > > (and uses only a > > > > > proposed addressing syntax in that context), what I believe > > > > > it illustrates > > > > > is the tremendous importance, in that context, of link > > > > > relationships. For > > > > > example, this XRI expresses that authority A's relationship > > > > > with authority B > > > > > (xri-A/xri-B) is linked to a link contract from authority A > > > > > (/($contract)/this-contract/($v1)) which is linked to a > > > > > specific item of > > > > > data from authority A (/(+email)/work/($v2)). > > > > > > > > > > So, in conclusion: > > > > > > > > > > * In the hierarchical-only worldview, / reigns supreme, and > > > > > therefore the > > > > > distinction between * and : as "secondary hierarchy" > > > > > characters appears > > > > > relatively minor. > > > > > > > > > > * In the combined hierarchy-and-peer-to-peer-link worldviews, > > > > > / and * are > > > > > equally important and equally valid first-level delimiters. / > > > > > is used to > > > > > express for hierarchical relationships between resources and > > > > > * is used to > > > > > express peer-to-peer linking relationships between > > > > resources. In this > > > > > worldview, both "/:" and "*:" would be equally valid, as > > > > > colon would always > > > > > be used as the prefix for a persistent identifier. > > > > > > > > > > I believe this worldview is not unique to XDI. Although XDI > > > > > architecture is > > > > > fundamentally based on the ability to express links between > > > > > resources, and > > > > > it uses XRIs for this purpose, I believe that establishing > > > > > the syntactic > > > > > "equal footing" of * and / for the purpose of enabling the > > > > > expression of > > > > > peer-to-peer linking vs. hierarchical relationships could > > > > > apply to many > > > > > other uses of XRI beyond the scope of XDI. > > > > > > > > > > I hope this explanation helps bridge the gap between these > > > > > two worldviews. > > > > > > > > > > =Drummond > > > > > > > > > > -----Original Message----- > > > > > From: Peter C Davis [mailto:peter.davis@neustar.biz] > > > > > Sent: Friday, June 11, 2004 5:45 AM > > > > > To: Lindelsee, Mike > > > > > Cc: xri@lists.oasis-open.org > > > > > Subject: RE: [xri] RE: Single delegation character > > > > > > > > > > ditto. it is, among other things, much easier to read. > > > > > > > > > > --- peterd > > > > > > > > > > On Thu, 2004-06-10 at 17:56, Lindelsee, Mike wrote: > > > > > > I also prefer the latter for the same reasons that Dave and > > > > > Loren do. > > > > > > > > > > > > Mike > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dave McAlpin [mailto:Dave.McAlpin@epok.net] > > > > > > Sent: Thursday, June 10, 2004 2:26 PM > > > > > > To: Loren West; xri@lists.oasis-open.org > > > > > > Subject: RE: [xri] RE: Single delegation character > > > > > > > > > > > > > > > > > > Good point. Now that we've beaten the delegation issue to > > > > > death, we can > > > > > > come back to the original question about whether we should > > > > > define one or > > > > > > two second level delimiters. > > > > > > > > > > > > The question is whether we prefer > > > > > > > > > > > > xri:@:3*:4*:5/*:6*:7 > > > > > > > > > > > > or > > > > > > > > > > > > xri:@:3:4:5/:6:7 > > > > > > > > > > > > for reasons already stated. My preference is the second, > > > > > i.e. to define > > > > > > two second level separators, star ("*") and colon (":"). > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from > > > > > the roster of the OASIS TC), go to > > > > > http://www.oasis-open.org/apps/org/workgroup/xri/members/leave > > > > > _workgroup.php. > > > > > > > > > > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from > > > > the roster of the OASIS TC), go to > > > http://www.oasis- > > > open.org/apps/org/workgroup/xri/members/leave_workgroup.php. > > > > > > To unsubscribe from this mailing list (and be removed from > > the roster > > of > > > the OASIS TC), go to http://www.oasis- > > > open.org/apps/org/workgroup/xri/members/leave_workgroup.php. > > > > > > To unsubscribe from this mailing list (and be removed from > > the roster of the > > OASIS TC), go to > > http://www.oasis-open.org/apps/org/workgroup/xri/members/leave > > _workgroup.php > > . > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]