W3C home > Mailing lists > Public > www-tag@w3.org > September 2008

RE: [XRI] Back to XRI

From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
Date: Fri, 12 Sep 2008 11:33:25 +0000
To: John Bradley <john.bradley@wingaa.com>, "Booth, David (HP Software - Boston)" <dbooth@hp.com>
CC: "elharo@metalab.unc.edu" <elharo@metalab.unc.edu>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <233101CD2D78D64E8C6691E90030E5C81B6C2D0C7B@GVW1120EXC.americas.hpqcorp.net>
Hello John,

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of John Bradley
> Sent: 11 September 2008 20:54
> To: Booth, David (HP Software - Boston)
> Cc: elharo@metalab.unc.edu; www-tag@w3.org
> Subject: Re: [XRI] Back to XRI
> 
> Thanks David, 
> 
> Certainly we want any http: subscheme to be completely 
> backwards compatible with existing agents.
> 
> In the case of a XRI like =jbradley where the XRI is a 
> "identifier for an abstract object",  me in this case.  
> (Though thinking of myself as abstract still strikes me as a bit odd.)
> 
> The question of what is returned when cast as a http: URI 
> becomes interesting.
> 
> In conversation with TAG members using Link headers to point 
> at the URI for the XRDS meta-data seems reasonable.
> We currently use a 302 redirect to point at some appropriate 
> html representation for compatibility reasons.  In my case a 
> contact page.
> 
> Stuart Williams has pointed out that using a 303 redirect 
> would make it clear that the resource 
> http://xri.net/=jbradley itself is "an identifier for an 
> abstract object" and not a resource that has temporarily moved.

Not quite... you not conclude that it *is* an identifier for an abstract
object, it may be but you cannot conclude that from the 303. 

What you can conclude (IMO), is:

- that there is no claim (in the response) that the resource has been moved
to a new location (that's different from 301/302)
- that you have not been returned a representation of the requested resource
(for undisclosed reasons)
- that following the redirect (to something else) may yield relevant
information *about* whatever http://xri.net/=jbradley refers to.
- (probably) that the authority for http://xri.net/=jbradley in some sense
warrants there redirection as useful/relevant to the original request.

The Link header approach (with GET or HEAD) is a mechanism that would work
similarly for both 'abstract' and 'concrete' resources in that it provides a
mechanism where a metadata reference can be provided alongside a
representation in 200 response (indeed multiple references could be so
provided).

[snip the next bit if you want to stayout of the philosopical tarpit.]

In the venacular of the TAG and the httpRange perma-thread 'abstract' and
'concrete' correspond roughly to what have been called 'non-information' and
'information' resources (but even muttering that risks another turn of the
wheel) - things that have mass (such as yourself) likely being
'non-information' resources (or 'abstract' as you say - and as you say that
seems odd). In fact in respect of the 'oddness' it would be interesting to
get some idea of bounds on where you think the boundaries are between
abstractness and concreteness (though I suspect we will be no more
successful with that than distinguishing information resources from
non-information resources in a definitve way.

>From my pov... you are definitely *not* abstract, but there are many facets
to you some of which maybe (eg. your life, or life history)- though I might
wonder about say Shakespeare who has a similar concrete existence - no
longer does - 'my notion of Shakespeare' is certainly abstract - but if you
and I are referring to Shakespeare are we referring to a concrete thing or
an abstract thing or... might we just not know or in many cases not care to
make a distinction?

[If you really want to start making your head hurt there's an interesting
dialog about 3d/4d conceptualisation of the world recorded at [1] and then
its probably off to metaphysics 101... and probably a very long pause...].

[1] http://www.adampease.org/Articulate/dialog-3d-4d.html
 
> The XRI TC originally selected the 302 redirect for 
> compatibility with pre http 1.1 browsers. 
> Changing to 303 redirects may brake some clients but it 
> unlikely to be a significant issue.
> 
> I understand that some people will feel that using redirects 
> is inefficient,  however it seems the only way to communicate 
> the desired qualities of the identifier in http:

What 303 does as opposed to 301/302 is make no assertion of relocation of
the reference resource. It simply says "See other".

Whilst on the one hand that is a very weak claim, bearly more than a hint
that there *may* be useful related information elsewhere, it can be used to
useful effect.

HTTP Link: headers with a more distinguished rel value could be used to make
a stronger claim (by virtue of what is entailed in the specification of a
given rel value eg. rel=http://xri.net/relations/xrds-metatdata could be
specified to be an assertion by the relevant (URI) authority that related
XRDS information *is* or at least *should be* available at the link target.

> This still allows XRI aware applications from directly 
> requesting the XRDS meta-data if they recognize the subscheme.
> 
> I will also mention that some people seem to prefer the term 
> "http: profile" as a way to describe the qualities of a sub scheme.  

Personnally, I just see it as a way that some authority architects the use
of the URI subspace under its authority - be that *.xri.net or *.xri (were
that TLD to be sought).

BTW: I'm sure that I spotted a URI of the form  something like
library.hpl.hp.com.<service>.<otherdomain>.com which seem to suggest a
similar pattern of use. Wish I'd been more careful to not thee particular
URI at the time.

> Regards
> John Bradley

--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12
1HN
Registered No: 690597 England

Received on Friday, 12 September 2008 11:36:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:06 GMT