[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]