[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)
|
Bill, You've captured an key element of the XRI resolution
discussion here, i.e., the question "Where does XRI resolution end and generalized
resource description start?" Based on all the conversations/proposal to
date, I'd offer the following answer: "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." 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 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. If you agree, this helps answer a key
question about the scope of XRI resolution. =Drummond From: Barnhill William
[mailto:barnhill_william@bah.com] 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: 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]