XRI/XDI - talked with Nick (was: on global cross references and the link contract use case)

["Drummond Reed" <drummond.reed@cordance.net>]

FYI, Nick and I had a very good discussion tonight, after which we both
agreed it DEFINITELY helps at this stage to go to live voice and pictures
(we just typed examples back and forth in Skype). There were a whole bunch
of points that would have taken many rounds of email to share/clarify.

Nick is going to do a new writeup based on his new understanding of some XRI
elements. And I'll post a message about xref delimiters next.

=Drummond 

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Tuesday, December 02, 2008 11:49 AM
> To: 'Nick Nicholas'
> Cc: 'Chasen, Les'; xdi@lists.oasis-open.org; 'OASIS XRI TC'
> Subject: [xri] RE: [xdi] on global cross references and the link contract
> use case
> 
> Nick,
> 
> First, thanks for all the effort you put into this message. Now's indeed
> the
> time for all of us who care about XRI 3.0 syntax to iron out our
> differences, and describing them in writing is one way to do that.
> 
> On a purely procedural note, my 1-on-1 call with Les yesterday reminded me
> that some of these topics are so tough to discuss in email that I think we
> can expect only so much from this medium. Likewise there's only so much we
> can get from the wiki. In the end, there's nothing like F2F to resolve
> differences, but since that's not practical, I expect the only way we're
> going to find our way to consensus for XRI 3.0 Syntax is via some
> dedicated
> telecons on this topic. I will put that on the agenda for this week's
> telecon.
> 
> Secondly, since this is already a long message with a number of key
> points,
> to avoid getting lost in nested threads I'll extract pieces and respond to
> them as separate topics.
> 
> Lastly, I too hate to copy both the XRI and XDI lists on this discussion,
> but I agree we need to do that because it intimately involves both of them
> (the memberships overlap heavily but are still partially disjoint). So I
> suggest we manually prefix the subject lines of threads sent to both lists
> with "XRI/XDI" so folks can filter on that as needed.
> 
> =Drummond
> 
> 
> > -----Original Message-----
> > From: Nick Nicholas [mailto:opoudjis@optushome.com.au]
> > Sent: Tuesday, December 02, 2008 12:20 AM
> > To: Drummond Reed
> > Cc: Chasen, Les; giovanni.bartolomeo@uniroma2.it; xdi@lists.oasis-
> > open.org; OASIS XRI TC
> > Subject: Re: [xdi] on global cross references and the link contract use
> > case
> >
> > At the risk of blowing up Drummond's brain even more :-) --- not to
> > mention alluding to a discussion going on at both the XRI and the XDI
> > lists, here's my response to the GCS, which continues on with Les'
> > confusion :-) , and ends up in a counterproposal to expand the meaning
> > of parentheses, away from cross-reference to syntactic encapsulation
> > in general. It's in dot point, as always happens when I'm very confused.
> >
> > I apologise for posting to both the XRI and XDI lists, but this does
> > end up relating to both.
> >
> > * I don't think the motivations are being explained well enough.
> > (Sorry Drummond.) "XDI needs it" is not enough of a motivation without
> > tangible illustration. And Les is by no means the last person who
> > won't get it. I have a PhD in linguistics, and I'm having difficulty
> > with it. I think the emails Drummond has been posting over the past
> > few weeks need to be worked into a coherent account on the wiki,
> > because the current GCS page isn't enough.
> >
> > * Use-mention (brought up on the XDI list as an explanation of local
> > vs. global scope) is a distraction: these are different contexts of
> > use, not mentions. I end up appealing to the distinction in a
> > different context below.
> >
> > * It's hard to make sense of the distinction between global, relative,
> > and local scope when the XRI 2.0 syntax doesn't mention relative scope
> > (indeed, scope) at all. That too needs to be addressed.
> >
> > * I don't find XRI terribly readable to begin with (even though my
> > native language is now Perl), and I don't think the compactness of the
> > compounded XRI is as compelling a motivation as others might. (That's
> > why, in what I propose below, I put parens back in.)
> >
> > * XDI requires GCS *only* inasmuch as there is a semantic difference
> > between locally and globally scoped entities. The statement "It
> > follows that any change to an XRI represents a change to the
> > underlying XDI RDF statement" is false, if the change to the XRI is
> > merely a matter of syntactic sugar, and semantically transparent
> > (e.g., a bracket indicating syntax grouping, as opposed to cross-
> > referencing). (Again, that's where I'm ultimately going with this.)
> >
> > * Nika queried last month what the distinction might be between =nika
> > +contact and =nika(+contact). Triggered by that, I'd like to propose a
> > different take on parentheses --- that the cross-reference be about
> > syntactic encapsulation, and is *agnostic* about context switching.
> >
> > The thing in parens is treated as reference to an entity while not
> > being internally parsed. If it's a URL, it's from an HTTP and not an
> > XRI context; but the parens encapsulate it without parsing the URL. It
> > follows that if the thing in parens is a URL, it is from a different
> > XDI context then the current context: the current context is not URL.
> >
> > But when Drummond suggests reificiation, as in
> >
> >     =jbradley/+says/(=drummond/$is$a/=jbradley+friend)
> >
> > the parens aren't being used to indicate that what's inside them is
> > from a different context. The context of (=drummond/$is$a/=jbradley
> > +friend) is not any different from the context of +stuff in
> >
> >     =jbradley/+says/+stuff
> >
> > If you put compound XRIs inside parens there, you're only doing so for
> > syntactic encapsulation. If there's a difference between these two:
> >
> >     =jbradley/+says/+stuff
> >     =jbradley/+says/(+stuff)
> >
> > --- that the second "stuff" is in somehow a different context from the
> > first, then we'd end up also having to distinguish between
> >
> >     =jbradley/+says/(=drummond/$is$a/=jbradley+friend)
> >     =jbradley/+says/((=drummond/$is$a/=jbradley+friend))
> >
> > And I don't see how that can work.
> >
> > I would instead say that the thing inside of brackets MAY OR MAY NOT
> > be in the same context as what precedes it, but XRI is agnostic to
> > that. If you *really* want to say it's in a local rather than a global
> > context, you should have put in the "*". The context of what is in the
> > parens is indicated *only* by parsing the identifier it contains. If
> > what is in the brackets is not an XRI, it is necessarily a different
> > context; the http:// is what tells you that. But if what is in the
> > brackets is an XRI, it may be the same context; and the brackets are
> > only operating for syntactic encapsulation.
> >
> > (And how do we know that what's in the bracket is an XRI and not a
> > URL? With the syntax of XRI. And maybe a palatable version of xri://...)
> >
> > So, by this:
> >
> > =a*(http://example.com) : URL locally interpreted in context of =a
> > =a(http://example.com)  : URL globally interpreted in context of =a
> >
> > =a*(=drummond/$is$a/=jbradley+friend) : reified compound XRI locally
> > interpreted in context of =a
> > =a(=drummond/$is$a/=jbradley+friend)  : reified compound XRI globally
> > interpreted in context of =a
> >
> > =a*(+stuff) : simple XRI locally interpreted in context of =a
> > =a(+stuff)  : simple XRI globally interpreted in context of =a
> >
> > What does this buy us?
> >
> > * A *much* more readable delimiter for concatenation than the
> > problematic alphabet soup of =a+stuff, which breaks by the time we get
> > to @ , as other posters have pointed out --- and is not at all to be
> > ignored. (Oh, and =les@microsoft.com is so utterly misleading it
> > should be banned instantly: after all, it means "Microsoft as pertains
> > to Les", and not "Les at Microsoft" --- or "Microsoft as Les construes
> > it".)
> >
> > * The elimination of an association of encapsulation and context-
> > change that I think is untenable, especially when what the parens
> > contain is not a simple XRI. After all, syntactic encapsulation is the
> > main meaning of parens.
> >
> > So I disagree with Drummond about the following:
> >
> > (From earlier email)
> >
> > > In short, XDI RDF statements are extremely precise. For example, +x
> > > and (+x)
> > > are not the same XDI subject. The first is the absolute XDI subject
> > > "+x" in
> > > the current XDI context, and the second is a cross-reference to that
> > > XDI
> > > subject in a different XDI context (not the current XDI context).
> >
> >
> > I don't find "not the current XDI context" useful in semantics. If you
> > know what the context is, you should be indicating it explicitly (e.g.
> > by the http:// ). "(+x)" as this construes it, ignoring any parsing of
> > the string "+x", is "Oh, I'm a different interpretation of +x, but I'm
> > not telling you what". That's not the specificity you're ask for in
> > XDI. And that's not what you're doing when the (+x) is a reification.
> >
> >
> > > Finally, the crux of the answer to "Why does a distinction need to
> > > be able to be made between the two methods?" is that neither
> > > provides the equivalent functionality of the other.
> > >
> > > In the first case, ordered sets cannot provide the same
> > > functionality as cross-references because ordered sets do not allow
> > > syntactic encapsulation of identifiers from other contexts. They do
> > > not let a URI be used in the context of an XRI, for example, or
> > > permit encapsulation of XDI RDF statements as shown above.
> >
> > Agreed.
> >
> >
> > > In the second case, cross-references cannot provide the same
> > > functionality as ordered sets because a cross-reference is
> > > explicitly a reference to an identifier in _different_ context.
> > > That's what makes it a "cross-reference" - it references across two
> > > contexts. For example, in the XRI...
> > >
> > >            @cordance*(mailto:drummond@example.com)
> > >
> > > .the cross-reference (mailto:drummond@example.com) is a reference to
> > > a URI rooted in the mailto: context.
> > >
> > > However in an ordered set, you are not referencing across contexts.
> > > The context is the ordered set itself. For example, in $sig$d, the
> > > context for $d is $sig. That's what makes it an ordered set.
> >
> > My response to that is: a bracket can indicate encapsulation without
> > necessarily being a cross-reference to a different context. It allows
> > cross-reference, and is the only mechanism whereby cross-reference is
> > possible. But I'm not convinced it requires cross-reference, or that
> > =a*(=drummond/$is$a/=jbradley+friend) *is* a cross-reference. It's a
> > "thunk": a mention of the identifier rather than a use (aha!)
> >
> > This broadens the semantics of the parens somewhat, but does not break
> > backward compatibility: all those XRI 2.0 cross-references remain
> > valid. It allows global cross-reference, but with enough syntactic
> > sugar to retain readability. And it eliminates a distinction between
> > =a(+x) and =a+x that I'd find very hard to justify.
> >
> > To deal with the other goals of the GCS proposal:
> >
> > #1: Literal Expression of RDF Statements in XDI. An XRI RDF under this
> > proposal would require XRIs go into parens to be embedded into
> > compound XRIs. That's a change to the XRI, but not a change to the
> > underlying XRI RDF statement, since the bracket is merely indicating
> > syntactic scope --- the XRI does not change referentiality, since the
> > parens are not intrinsically crossreferences:
> >
> > (=drummond)/($is)/(=drummond.reed)
> > ((=drummond)/($is)/(=drummond.reed))/($is)/(+verifiable)
> > (=drummond)/(+owns)/(http://equalsdrummond.net)
> > In fact (to renege on my proposal), since XRI paths are a special
> > case, I have no real problem with the parens being optional within an
> > XRI path segment: the parens are just delimiters now --- and so are
> > the slashes:
> > =drummond/$is/=drummond.reed
> > (=drummond/$is/=drummond.reed)/$is/+verifiable
> > =drummond/+owns/(http://equalsdrummond.net)
> > That last bracket's still required because what's inside the brackets
> > does not follow XRI syntax --- it uses slashes differently, for one;
> > and so is being syntactically encapsulated.
> > #2: XRI Composition: The discussion contrasts between only local and
> > global interpretation of components of compound XRIs. The distinction
> > between relative and global scope, whatever it may be, is not
> > exploited. My proposal does away with it; I'll need to see what that
> > distinction is, if my proposal is wrong here.
> >
> > #3: Consistency with the XRI-as-Relative-URI Proposal
> >
> > See my reneging on #1: I'll admit optionally dropping the parens
> > within slashes, but *only* because both the parens and the slashes are
> > delimiters. Without slashes, the parens should stay.
> >
> > #4: Human-Readability and Comprehension
> >
> > I truly believe @example+international+employment$contract$sig$d is
> > less readable than @example(+international)(+employment)($contract)
> > ($sig)($d) . I also think Nika's reported =nika(+contact) is happening
> > because I'm not the only person to think so.
> >
> >
> > --
> > Life                Dr Nick Nicholas;  Link Affiliates, Melbourne
> > Is a knife                                         skype:opoudjis
> > Whose wife          opoudjis@optushome.com.au
> > Is a scythe                               http://www.opoudjis.net
> > --- Zoe Velonis, Aged 14 1/2.
> >
> >
> >
> 
> 
> 
> ---------------------------------------------------------------------
> 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