[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] RE: Difference between global and local subsegments (What gives them the right?!?!)
Bill, A local-xref is an cross-reference (either
an XRI or a URI) inside parens with a Local Context Symbol (* or !) in front of
it. *(=marty) *(+west) !(@!1000) A global-xref is an XRI authority segment
use as a cross-reference WITHOUT being in parens, and thus not having any * or
! in front of it. Note that all global-xrefs are in fact global XRIs by
themselves; they only become a global-xref when they are NOT the very start of
an XRI authority segment. For example, in XRIs #1 and #2 below, “+reputation”
is a global-xref. However in #3, +reputation is the first segment and +academic
is a global-xref. 1) =drummond+reputation 2) @cordance+reputation 3) +reputation+academic Hope this helps, =Drummond From: Barnhill,
William [mailto:barnhill_william@bah.com] Fair 'nuff, that makes sense and thanks
for clarifying. On one example though, I still can't use that because of the
local vs. global thing, right? @example*(=marty)*reputation Or can I, is *(=marty) a local or a global
xref? And given whether it's local or global, what would a similar example be
of the other one (local vs. global, global vs. local)? -- From: Schleiff,
Marty [mailto:marty.schleiff@boeing.com] The one way you can't use is
"@example=marty*reputation". Instead you could use any of the following,
or anything that does not encroach on the =marty namespace: @example*marty*reputation @example=marty+reputation @example*(=marty)*reputation All of these examples also make it more
clear that it's @example's opinion of the reputation, which is I think
what Bill is asking for. Marty.Schleiff@boeing.com;
CISSP From: Barnhill,
William [mailto:barnhill_william@bah.com] "If anybody other than me says there
exists a resource labeled "=marty*reputation", then they are
encroaching on my namespace. " I'd agree that only you can say whether or
not the resource exists. But anyone can make statements about that resource,
implying that it may exist. For example if you and I have FOAF files I can say
I work with you, which implies you work with me, so I've made a statement about
you as resource. I can go to your FOAF to determine if you agree with me
or not. I'm open to other methods of making
statements about =marty, but feel that statements about marty..ie
@example*marty*reputation are not the same as @example=marty*reputation.
Would perhaps a better way of saying it be @example=Marty+reputation? -- From: Schleiff,
Marty [mailto:marty.schleiff@boeing.com] Hi Bill (& All), I own "=marty", and I'm the ONLY
authority to determine whether or not there is a resource labeled
"=marty*reputation". I am indeed the final and sole arbiter of any
identifier under the "=marty" namespace (with the minor exception
that xrefs under =marty must honor the sole abitership of the authority within
the xref). If anybody other than me says there exists
a resource labeled "=marty*reputation", then they are encroaching on
my namespace. Marty.Schleiff@boeing.com; CISSP
From: Barnhill,
William [mailto:barnhill_william@bah.com] Marty, It seems that @example!(=marty*favorite-whore) is saying that
"According to @example, there exists a resource which can be labeled
the favorite-whore of =marty). Regardless of validity of the statement,
isn't @example allowed to say that? Disregarding slander laws atm, btw. If
you say they aren't then that disallows all business models revolving around
brokered trust, because it would means that =marty is the final and
possibly sole arbiter of =marty*reputation, which doesn't make sense to me.
I'll think about it more though, as this is just an off the cuff response. Bill -- From: Schleiff,
Marty [mailto:marty.schleiff@boeing.com] Hi All, I tweaked the subject line of this
message, because it's a little different aspect of the discussion. Because the
following examples are meant to be offensive, I'll use "=marty"
instead of anyone else's i-name, but please mentally replace "=marty"
with your own i-name and see how it makes you feel. I don't have a mistress, I don't have a
favorite whore, and I've never beat my wife. As the authority for identifiers
under "=marty", I have not defined any of the following:
Therefore, I submit that @example MUST NOT
generate the following XRIs, because it implies that the previous XRIs actually
exist:
@example could indeed generate the
following XRIs, which would just be lies:
I also wonder if resolution provides a way
for an authority to refute the existence of an XRI. For example, when someone resolves"@example=marty*mistress",
perhaps they might also wish to directly resolve "=marty*mistress" to
determine how "@example" reflects/alters/fabricates the
resolution of "=marty*mistress". As owner of "=marty", I'd
like to be able to refute the existence of identifiers under
"=marty". Marty.Schleiff@boeing.com; CISSP
From: Drummond
Reed [mailto:drummond.reed@cordance.net] Steve, Marty, Bill, et al: It’s Sunday night, and after
thinking about Steve’s observation over the last few days, I’ve
come to a greater appreciation of the difference between global and local
subsegments in an XRI authority segment. (Note that by “global subsegment”
I mean the global-literal and global-xref rules on http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1,
and by “local subsegment” I mean the local-literal and local-xref
rules on that page.) First, in XRI 2.0, an XRI authority
segment consisted of only one global subsegment. It could contain any number of
local subsegments inside it (and those could be either local-literals or
local-xrefs), but it could not contain another global subsegment. In the proposed XRI 2.1 syntax, an XRI
authority segment can contain more than one global subsegment. So what Steve noticed is that while the
XRI resolution rules are the same for both 2.0 and 2.1, i.e., that a resolver
just “walks the tree” of top-level subsegments in an XRI authority
segment to resolve it, that tree of subsegments has one important structural
difference: once you hit the first global-xref, every other top-level
subsegment must be a global-xref. In other words, think of the pattern this
way: 1) XRI authority segments in XRI 2.0 (with
the exception of cross-reference root authorities):
GCS-char
local local
local …
/ 2) XRI authority segments in XRI 2.1:
GCS-char
local local local
…
global global global
… / I think this makes it easier to see that
when you “switch over” from resolving local subsegments to
resolving global subsegments, each global subsegment is relative to the
previous one just like each local subsegment is relative to the previous one. Secondly, when you apply that to
Steve’s example – of resolving @ootao*west*steve and
@ootao+west*steve, it’s true that the first one parses into four
top-level subsegments…
@
ootao
*west
*steve …and the second one into
three…
@
ootao
+west*steve However, if the policy of @ootao is that
*west and +west are synonyms, then @ootao*west can delegate to *steve and the
same delegation can be recognized for @ootao+west*steve. Here’s the flow: @ootao*west*steve 1) Resolver queries @ for ootao 2) @ responds for ootao 3) Resolver queries @ootao for *west 4) @ootao responds for @ootao*west 5) Resolver queries @ootao*west for *steve 6) @ootao*west responds for
@ootao*west*steve @ootao+west*steve 1) Resolver queries @ for ootao 2) @ responds for ootao 3) Resolver queries @ootao for +west*steve 4) @ootao queries @ootao+west for *steve 5) @ootao+west responds for
@ootao+west*steve 6) @ootao responds @ootao+west*steve Notice that it takes the same number of
steps, for the same number of delegations, however @ootao is responsible for
answering the +west*steve response, vs. the original client resolver being responsible
for resolving it. This ability to control who will provide
the resolution response is, I believe, one of those key guidelines Marty is
looking for (and which I am indeed tasked to elucidate) as to whether an XRI
author should use local subsegments or global subsegments. =Drummond (Note: I’m headed off
early tomorrow morning for the Higgins f2f meeting in Austin, so I’ll be
offline until mid-afternoon tomorrow.) From: Steven Churchill
[mailto:steven.churchill@xdi.org] > I know that Steve and I lost the
"direct concatenization" vs. "compact syntax" vote, but I'd
just > like to point out that under compact
syntax "@ootao+west" normalizes to
"@ootao*(+west)". > And if "@ootao*west"
and "@ootao+west" are declared as synonyms, then you could logically > deduce that
"@ootao*west*steve" and "@ootao*(+west)*steve" are
synonyms. I agree. I’d just like to point out
that the way that the two would be “declared as synonyms” is that
“*(+west)” would be added as a local synonym to
“*west”. ~ Steve From: Schleiff, Marty
[mailto:marty.schleiff@boeing.com] Hi Bill & Steve (& All), I think Steve meant that EVEN IF
"@ootao*west" and "@ootao+west" are declared as synonyms,
then "@ootao*west*steve" and "@ootao+west*steve" are not
synonyms (unless they are explicitly declared as synonyms). I know that Steve and I lost the
"direct concatenization" vs. "compact syntax" vote, but I'd
just like to point out that under compact syntax
"@ootao+west" normalizes to
"@ootao*(+west)". And if "@ootao*west" and
"@ootao+west" are declared as synonyms, then you could logically
deduce that "@ootao*west*steve" and "@ootao*(+west)*steve"
are synonyms. Marty.Schleiff@boeing.com; CISSP
From: Barnhill,
William [mailto:barnhill_william@bah.com] Hi all, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]