[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?!?!)
That clears up the global/local issue for me, thanks. Also,
your view in prior email on @example=marty*reputation and
@example=marty+reputation are exactly what I was thinking as well, but I hadn't
nailed down the difference between xxx*reputation and xxx+reputation. Use case I
was looking at was @example=marty+reputation
Bill
-- From: Drummond Reed [mailto:drummond.reed@cordance.net] Sent: Monday, April 30, 2007 11:39 PM To: Barnhill, William; 'Schleiff, Marty'; 'Steven Churchill'; xri@lists.oasis-open.org 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]