RE: Describing vs Described problem (was Compromise Conceptualization Towards CD-02)

["Barnhill William" <barnhill_william@bah.com>]

Title: RE: Describing vs Described problem (was Compromise Conceptualization Towards CD-02)

Not sure what happened to the conference call, but dialed in and it's been a half hour with no one, so signing off. Guessing it got cancelled and not de-scheduled, but no worries. If it's been moved to a different time than 9am-10am PT, please update the OASIS tc calendar.

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Wed 11/2/2005 10:57 AM
To: Barnhill William; xri@lists.oasis-open.org
Subject: RE: Describing vs Described problem (was Compromise Conceptualization Towards CD-02)

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.



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?



=Drummond



  _____ 

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