[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?!?!)
Drummond,
Quit bastardizing my =marty namespace. There is no
*reputation under =marty. If you win this argument I think I may ask 2idi for a
refund on =marty, because they obviously didn't deliver a namespace for me to
control. If the notion of xref allows this, then my knee-jerk reaction is that I
don't like xrefs, and it's time for me to start looking for another approach to
global naming, because it sure as flip isn't XRI.
Marty.Schleiff@boeing.com;
CISSP From: Drummond Reed [mailto:drummond.reed@cordance.net] Sent: Monday, April 30, 2007 8:32 PM To: Schleiff, Marty; 'Barnhill, William'; 'Steven Churchill'; xri@lists.oasis-open.org Subject: RE: [xri] RE: Difference between global and local subsegments (What gives them the right?!?!) While I agree with the
structural points Marty makes here, per my last message I’m not sure I agree
with the final conclusion because it implies that XRI resolution asserts more
than it does. Let me put it this way.
When you resolve =marty, you get back an XRDS from the = registry for the
registrant who registered the typeless-literal “marty”. If you trust that this
registrant is THE Marty Schleiff from Boeing that you know, then you can trust
that these are his service endpoints and other metadata.
If you next queried
=marty for *reputation, you would be getting back an XRDS from =marty with his
metadata describing the resource that HE calls by the local reassignable
identifier “reputation”. Note that this may be different than querying =marty
for +reputation, because when you query =marty for +reputation, you are asking
him for metadata describing “the resource globally identified by public
consensus using the reassignable identifier
‘reputation’”. In either case, you are
getting the answer directly from =marty, and that’s where the trust relationship
lies. Now, move all this in the context of @example. Per my last message, if you
query @example for =marty, you are trusting @example to give you it metadata
describing =marty. This may be different than the metadata you get back from the
= registry for “marty”. Correpondingly, if you
query @example for =marty*reputation, you MIGHT get back the same XRDS as if you
asked =marty to resolve *reputation directly, but you also might not. You are
simply getting back the metadata that @example decides to give you for the
resource represented by =marty*reputation. You have to decide if you trust
@example for this info. However I agree with
Marty that @example should provide an answer to =marty*reputation only if =marty
has a resource =marty*reputation. If @example wants to make their own assertion
about the reputation of =marty, @example should use
@example=marty+reputation. =Drummond
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]