[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]