OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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]
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

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]