[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]
"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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]