Re: [xdi] on global cross references and the link contract use case

[Nick Nicholas <opoudjis@optushome.com.au>]

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.