Re: [xri] Resolutions

[John Bradley <jbradley@mac.com>]

Thanks Nick,

Yes it is a slippery topic for the TAG in general.

I have had the most success with them describing it in terms of  
"Cooler XRI"

All XRI bound to http are "Cool URI".   In the proposal they will  
always return 303 redirects to resources and never the resource  
itself.  They will contain link headers in a manner consistent with  
Mark Nottingham's proposals for XRDS-Simple/XRD.
They can use accept headers to choose between a number of possible 303  
redirects for different representations of the "thing" identified by  
the XRI.

The difference between a "Cool URI" and a "Cooler XRI"  is that via  
sub schemes a shared semantic also exists like ARK.

This allows http://xri.net/=Drummond to descibe the same thing as https://xri.net/=Drummond 
.  They are separate URI and can be treated as such by applications.   
However XRI aware semantic web apps can discover the eqivelency by  
examining the meta data or via knowledge of the sub scheme.

We however do need locators for the actual meta data files.  The  
question is are these locators in the https: space as seperate URI  
distinguished by query parameters.

We have been considering http://xri.net/=drummond/?_xrd_r=application/xrds+xml 
  to be a locator that returns a 200 response with a XRDS document.    
I am interested in knowing if you see a problem with that?

John Bradley
=jbradley

On 6-Nov-08, at 11:50 PM, Nick Nicholas wrote:

> Having now caught up on the W3C TAG list discussions:
>
> You know this, but I'll restate the obvious. After reading the  
> emails, particularly http://lists.w3.org/Archives/Public/www-tag/2008Oct/0104.html 
>  and follow up:
>
> People will keep assuming that because http://xri.net/=drummond can  
> resolve to an XRDS, http://xri.net/=drummond is an identifier for an  
> XRDS. Jonathan Rees clearly thought so.
>
> Do not allow this. And do not distinguish between http://xri.net/=drummond 
>  and http://xri.net/=drummond/?_xrd_r=application/xrds+xml , or  
> http://*.xri.net/=drummond and http://thing-described-by.org/xri/=drummond 
>  . =drummond, and http://xri.net/=drummond, both identify Drummond  
> the Abstract Thing (the human being, in fact; Abstract really means  
> Not Necessarily Digital). http://xri.net/... is also a service that  
> gets back a description of Drummond. http://xri.net/=drummond/?_xrd_r=application/xrds+xml 
>  is a more refined service call, to get a particular kind of  
> description.
>
> But Neither Service Call Identifies Drummond. If we say they do,  
> we're back at the mess we started with. That's the inherent problem  
> in using an identifier, URI, which is intrinsically also a service  
> call. All we can do with this is, always return 303s in XRI  
> resolution calls ("what you are getting Is Not Drummond. It's a  
> description of Drummond"). That doesn't change whether we specify  
> XRDS as a parameter or not. And maybe, push the XRDS-Location header  
> more in examples (if not implementations). Because that XRDS- 
> Location URL *is* the identifier for the descriptor.
>
> Pointing to the equivalence of, say, HTTP HEAD http://thing-described-by.org/info:xri:=drummond 
>  and HTTP HEAD http://xri.net/=drummond might not be such a bad  
> thing rhetorically: it makes more clear the distinction between  
> resolution and identification, and that the XRI resolution binding  
> is not a retrieval of a resource named in the URL --- just as thing- 
> described-by.org is clearly not.
>
> Again, I know you know this, but it'll be a lot of work to make sure  
> URL-heads get it too.
>
> ^ 
> ^ 
> ^ 
> ^ 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Dr Nick Nicholas; Link Affiliates,      opoudjis@optushome.com.au
> Melbourne          skype:opoudjis       http://www.opoudjis.net
> "Despite millions of dollars of research, death continues to be this
> nation's number one killer."    --- Henry Gibson, Kentucky Fried  
> Movie.
> __________________________________________________________________________
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php