Bill,
1) Yes, an XRI
authority can provide a different XRID for every subsegment for which it is
authoritative. So even if @foo*bar and @fun*bar represent the same target
authority, they can produce different XRIDs. (Note that unless @foo and @fun are
synonyms for the same authority, these XRIDs for *bar would actually be coming
from different authorities.) Another example is @foo*bar and @foo*fun – both are
coming from the same source (describing) authority, and even if both represent
the same target (described) authority, they can produce different XRIDs
describing this target authority.
** Ok, that clears it
up for me, thanks.
2) On this question:
** Does there currently
exist a method for an XRI that links into the continaing document? May not be
desirable even if possible, as if an XRI authority is strictly designed to
signify an extensible and re-assignable name for a network endpoint (aka network
location), then it doesn't signify the data about the resource at that network
location, right? An analogy would be the address of a house: 123 Main. 123 Main
is NOT the house, though some people may say my house is 123 Main. 123 Main is
rather both the name and the location of the house. One of the things I like
about XRI is that I can have different identifiers for name (human readable) and
location (!#s) for the same resource without clashing."
I'm not sure I totally
understand the question, but let me point out this: while XRI enables both
reassignable and persistent identifiers for the same resource, at the XRI level
both of these identifiers are abstract (i.e., "names" by your definition above)
that need to be resolved into a network endpoint ("location" by your definition
above). They are different and non-clashing "names", but still "names" by your
definition.
I don't know if this
answers your question about "Does there currently exist a method for an XRI that
links into the containing document?" Can you explain this question in more
detail?
Consider an XRID with some RDF metadata about the XRID
itself embedded somewhere within the XRID (dc:author for example). If I want an
XRI that can access that data I either need to know beforehand how that data is
stored within the XRI and parse it out when I get the XRID (doable, but
basically hard coded), or I need an XRI authority subsegment or XRI local path +
inline resolution spec, that can reference this embedded data, for example
xri://@foo*bar/(+about). Using the XRI method I don't care whether the data is
embedded, or at some network endpoint,right? So that would seem the best bet,
but is that (1) allowable, (2) possible within current bounds of
specs.
Thanks,
=Bill.Barnhill
From: Barnhill
William [mailto:barnhill_william@bah.com]
Sent: Wednesday, November 02, 2005 4:36
AM
To: Drummond Reed; Wachob,
Gabe; xri@lists.oasis-open.org
Subject: RE: Describing vs Described
problem (was Compromise Conceptualization Towards CD-02)
Drummond,
Ok, thanks. That does help clear it up
a bit, though I think some of the questions still apply..see
inline.
-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent:
Tue 11/1/2005 9:51 PM
To: Barnhill William; 'Wachob, Gabe';
xri@lists.oasis-open.org
Subject: RE: Describing vs Described problem (was
Compromise Conceptualization Towards CD-02)
...
"XRI resolution is
intended to enable dereferencing of an abstract
identifier into: a) one or
more concrete network endpoints (URIs) which
enable access to further
description of or interaction with a resource, or
b) one or more XRI synonyms
for a resource."
** That makes sense, totally agree, and jibes with my
understanding.
While RDF or XDI *could* be used for such
requirements, the goal has been
something much simpler and more lightweight.
So a typical pattern of
interaction would be to use the XRI of a resource to
retrieve an XRID
describing the resource, then use that XRID to obtain the
network endpoint
where further RDF or XDI descriptions can be
accessed.
** That would seem then to answer the question of "Does
xri://@foo*bar represent the resource @foo*bar or does it represent a data
controller (Authority) over @foo*bar's data such that @foo*bar will route
requests for data": It has to represent the data controller, as by itself it
cannot return metadata other than a list of xri references, unless... see
below.
That doesn't mean that an XRID could not be used to carry richer
metadata
(such as embedded RDF or XDI documents), only that it isn't intended
for
that as it's primary purpose.
** Does there currently exist a
method for an XRI that links into the continaing document? May not be desirable
even if possible, as if an XRI authority is strictly designed to signify an
extensible and re-assignable name for a network endpoint (aka network location),
then it doesn't signify the data about the resource at that network location,
right? An analogy would be the address of a house: 123 Main. 123 Main is NOT the
house, though some people may say my house is 123 Main. 123 Main is rather both
the name and the location of the house. One of the things I like about XRI is
that I can have different identifiers for name (human readable) and location
(!#s) for the same resource without clashing.
Which brings up the other
point: Consider if @foo*bar also goes by the name @fun*bar, and the same
authority resolves both. I thought the XRI spec says that the XRID returned is
specific to the authority segment being resolved, not the authority itself. For
example, look at Apache virtual hosts. I can have multiple sites on one IP, and
Apache determines which virtual host descriptor (similar to an XRID in a very
loose sense) to use based on the host name.
I think the XRID equivalent
would be an authority returning a different XRID depending on the authority
segment resolved. I thought that was already in the spec., and if so wouldn't
that also kill the idea of the authority as the resource, rather than the
authority as the pointer to the resource's data? C ptr's also seem a good
analogy.
If you agree, this helps answer a key question about the scope
of XRI
resolution.
** I definitely think I agree, but as you saw above
still have questions. I will be attempting t o make both calls this week, but
may only be able to make the Thursday
one.
=Bill.Barnhill
_____
From: Barnhill
William [mailto:barnhill_william@bah.com]
Sent:
Tuesday, November 01, 2005 4:48 AM
To: Drummond Reed; Wachob, Gabe;
xri@lists.oasis-open.org
Subject: RE: Describing vs Described problem (was
Compromise
Conceptualization Towards CD-02)
Thanks
Drummond.
I realize I'm somewhat of a johnny com-lately here, but
I do have another
question on this.
You said: "it also clearly
REPRESENTS the non-network resource. For example,
my personal XRI,
xri://=drummond.reed, clearly isn't actually ME as a
non-network resource,
but it does clearly REPRESENT me as a person."
Does
xri://=drummond.reed actually represent you as an entity or does it
represent
the entity controlling data about drummond.reed within the =
namespace? If I
resolve xri://drummond.reed I don't get data about
drummond.reed, I get data
about data about drummond.reed, yes?
If I want a document
that describes you as a resource I need to resolve a
path into that data to
get the document about you, or add an authority
segment specific to the data
I'm looking for, right?
Not sure if the convention for email data
is xri://=drummond.reed/(+email)
or xri://=drummond.reed*(+email), or
something else, but either way the
email data is not embedded within the
XRID, is it? You could make a case
for a link to the email data being
in the XRID, but I thought it was not
suppose to be a link as much as data
about the email data, including the
local resolution
method.
If xri://=drummond.reed by itself represents both the
data controller for
drummond's data, and the resource known as drummond.reed,
then you have two
types of data in the same document, and I thought the XRID
was only to
handle resolution data not resource description data, which would
be handled
by RDF or XDI or something else.
Looking at
the XRID schema I see embedding RDF or XDI within is possible,
but
doesn't specifically state an optional 'about' element to contain such
data
so no idea if that is permissible/expected. Would that be a good idea,
or a
bad one? If that's already been covered I apologize and would love a
link to
the thread.
If embedding resource description data within the
XRID is done, how are
individual sub-resources referenced? One mechanism
might be an local
resolution method that treats the path as an XRI encoded
xpath expression
into the current XRID document. I can see where this would
be both useful
and potentially nasty from an implementation standpoint as I'd
think you'd
want to keep XRIDs small and light.
If I'm wrong
on any of this feel free to point it out, as it's the only way
I'll catch
up.
Thanks,
=Bill.Barnhill
_____
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent:
Tue 11/1/2005 3:59 AM
To: Barnhill William; 'Wachob, Gabe';
xri@lists.oasis-open.org
Subject: Describing vs Described problem (was
Compromise Conceptualization
Towards CD-02)
Bill,
You
bring out a very subtle but very important issue here, one which I'll
call
the "describing vs. described authority" problem.
Take the XRI
"@a*b".
To resolve this, the @ authority is asked to describe *a,
and then the @a
authority is asked to describe @a*b.
However
@a is only one potential source of metadata about @a*b. The second
potential
source of this metadata is @a*b itself. In other words, for any
XRI authority
after a community root authority, there are really TWO
resources that can be
asked for metadata about the resource identified by
@a*b:
1)
The describing authority (in this case, @a).
2) The described
authority (in this case, @a*b).
Another way to put it is that the
XRI @a*b allows a resolver to figure out
who it can FIRST ask for metadata
about @a*b, and that's @a. But if @a does
not have sufficient metadata about
@a*b, then the resolver can continue and
ask @a*b for further info about
itself.
The first step - asking @a about *b - is what we have
always called XRI
authority resolution, because you are resolving an XRI
authority subsegment.
The second step - asking @a*b about itself - is what is
proposed to be
called local resolution, because even though you are asking
@a*b for an
XRID, you are not asking it to resolve another authority
subsegment, instead
you are just asking it for more metadata about itself
than @a was able to
give you.
I think this distinction is very
important because it does not involve a
local path, or even an empty local
path as indicated by a trailing slash (as
discussed in my last message to
Gabe). In fact it may be the source of the
semantic confusion we've been
having about this topic.
To help avoid this semantic confusion, I
think it helps to: a) clarify that
except for a community root authority,
there are always at least two
potential sources of metadata (XRIDs) about an
XRI authority. One is the
DESCRIBING authority (e.g., @a). The other is the
DESCRIBED authority itself
(e.g., @a*b). Either might be authoritative for
the particular metadata
being
requested.
=Drummond
_____
From: Barnhill William [mailto:barnhill_william@bah.com]
Sent:
Monday, October 31, 2005 12:36 PM
To: Wachob, Gabe; Drummond Reed;
xri@lists.oasis-open.org
Subject: RE: [xri] Compromise Conceptualization
Towards CD-02
"Here's where we get into trouble - what is meant
by "the authority". If
xri://@foo*bar is an authority, then its not a dog.
Last time I checked,
dogs couldn't answer XRI subsegment resolution requests.
But we can just
sort of ignore that by saying that the result of resolution
describes the
dog and services on the network that act as a proxy for the dog
on the
network. In the new conceptualization, we are saying that resolution
of
@foo*bar gets back both descriptions of the resource and network
services
offered on behalf of (or "relative to"?) that
dog." -Gabe
I've always understood the
authority segment to represent exactly that: the
XRI of the authority over a
resource's data. For example if the American
Kennel Club was an authority on
its dog data, and data about registered dogs
in particular:
xri:@akc*dogs*registered would resolved to a resource
describing the
authority, i.e. an XRID,
xri:@akc*dogs*registered/dog/somedogid would refer
to a specific dog, i.e.
return a document of type Dog. So how do we describe
@akc*dogs*registered?
I'd suggest allowing for one or both of the
following:
. Either extend XRID schema such that RDF and/or
XDI elements can be
embedded with the XRID
. Or standardize a $ word
path s.t. xri:@akc*dogs*registered is the
authority,
xri:@akc*dogs*registered/($about) that returns a metadata
document in a
format specified using the $ format specification scheme, and
XDI as as the
default if no metadata format specified.
I chose /$about rather
than *($about) as *($about) seems to imply that
authority over metadata about
a particular authority A could be delegated to
a authority B and it seemed a
good idea that authority A is always the
authority of it's own metadata, but
I'd be interested to hear which those
with more XRI experience think is
better.
=Bill.Barnhill