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