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

RE: [XRI] TAG recommendation

From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
Date: Mon, 21 Jul 2008 10:13:47 +0000
To: "Schleiff, Marty" <marty.schleiff@boeing.com>, John Bradley <john.bradley@wingaa.com>
CC: "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <233101CD2D78D64E8C6691E90030E5C816BA093F80@GVW1120EXC.americas.hpqcorp.net>

Hello Marty,

> -----Original Message-----
> From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
> Sent: 19 July 2008 16:57
> To: Williams, Stuart (HP Labs, Bristol); John Bradley
> Cc: www-tag@w3.org
> Subject: RE: [XRI] TAG recommendation
>
> Hi Stuart (& All),
>
> Stuart said:
> > If the answer, which I think you give above, is that you always
> > get back a representation of an XRDS document, then despite
> > the intent the identifier does not infact refer to the spec it was
> > intended to reference.
>
> Using that same logic (with which I disagree), a PURL would
> not in fact refer to a resource that needs a persistent
> identifier; rather, a PURL would refer to the returned HTTP redirect.

Nope... eg. <http://purl.org/dc/elements/1.1/title> refers to a relation between, typically, works of some kind and their titles. It does not refer to the 302 redirection response (erroneous, in that it should be a 303 see other. 302 suggest that the resource has 'moved' temporarally to an other location - whereas 303 typically refers you to something distinct but related to what you asked for). The wget trace below (below the signature line), follows a chain of redirections and grounds out with a 200 OK respoonse on a retrieval of <http://dublincore.org/2008/01/14/dcelements.rdf> which 'happens' (as intended) to say something useful (at least to RDF processors) about <http://purl.org/dc/elements/1.1/title> amongst other things.

In this whole process no webarch:representation of <http://purl.org/dc/elements/1.1/title> is provided. Instead redirection is used to reach a distinct (RDF) description (ie. metadata) with its own distinct URI.

> I don't know much about PURLs, but I think of them as
> "abstract" identifiers because there's a layer of abstraction
> between the identifier and the named resource.
>
> Similar to PURL, XRIs are "abstract" identifiers. XRI
> resolution NEVER directly returns the named resource; rather,
> resolution returns an XRDS describing how to interact with
> the named resource.

Ok... so if someone does an http GET operatation on (allow me my ficticious XRI - correct it or improve it to be more in line with XRI intent):

        http://xri.net/@oasis*specs*os*xri($v2.0)*resolution

        (or, allowing an XRI scheme, xri://@oasis*specs*os*xri($v2.0)*resolution
         which modulo IRI->URI conversion can be placed on a HTTP request line).

What direct[*] HTTP response should I expect?

1) An http 3xx redirection (preferably 303 IMO) to an XRDS resource with a distinct URI?
2) An http 200 response with an [html|pdf|.doc] representation of the specification?
3) An Http 200 response with an application/xrds+xml representation (without a Content-Location: header)?
4) An Http 200 response with an application/xrds+xml representation (with a Content-Location: header and a reference to a distinct resource)?

[*] ie. the response to the given request, rather than the final response after the client has followed a one or more 3xx redirections.

Does the answer differ between the different forms of XRI resolution (that would be 'bad')?

IMO...:

*If* the identifier is an identifier for the metadata (rather than an identifier for the subject of the metadata), 1, 3 and 4 are ok.
*If* (as intended in this scenario) the identifier is an identifier for a praticular specification, 1 and 2 are ok and 3 and 4 would be very wrong.

> When resolving a PURL, if the software is smart enough, it
> can automatically process the returned redirect to retrieve
> the named resource.

What it then retrieves a representation of is named by the target URI in the Location header: which in the something distinct from the orignal referee.

> When resolving an XRI, if the software is
> smart enough, it can automatically process the returned XRDS
> to retrieve the named resource. And, if the software is smart
> enough, it can automatically process the returned XRDS to
> interact with the named resource in other ways defined by the
> service points in the XRDS.
>
> BTW, I hope to leave for a week of vacation (as soon as we
> can finish packing). So please don't misinterpret a lack of
> email from me as a of lack of interest.
>
> Marty.Schleiff@boeing.com; CISSP
> Associate Technical Fellow - Cyber Identity Specialist
> Information Security - Technical Controls
> (206) 679-5933

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

  $ wget --debug http://purl.org/dc/elements/1.1/title
  DEBUG output created by Wget 1.11.3 on cygwin.

  --2008-07-21 10:22:42--  http://purl.org/dc/elements/1.1/title
  ---request begin---
  GET http://purl.org/dc/elements/1.1/title HTTP/1.0
  User-Agent: Wget/1.11.3
  Accept: */*
  Host: purl.org

  ---request end---
  Proxy request sent, awaiting response...
  ---response begin---
  HTTP/1.1 302 Found
  Date: Mon, 21 Jul 2008 09:23:22 GMT
  Server: Apache/1.3.29
  Location: http://dublincore.org/2008/01/14/dcelements.rdf#title
  Content-Type: text/html; charset=iso-8859-1
  Connection: close

  ---response end---
  302 Found
  Location: http://dublincore.org/2008/01/14/dcelements.rdf#title [following]
  Closed fd 3
  --2008-07-21 10:22:44--  http://dublincore.org/2008/01/14/dcelements.rdf
  ---request begin---
  GET http://dublincore.org/2008/01/14/dcelements.rdf HTTP/1.0
  User-Agent: Wget/1.11.3
  Accept: */*
  Host: dublincore.org

  ---request end---
  Proxy request sent, awaiting response...
  ---response begin---
  HTTP/1.1 200 OK
  Date: Tue, 15 Jul 2008 14:07:59 GMT
  Server: Apache/1.3.28 (Unix) mod_jk/1.1.0
  Last-Modified: Sun, 13 Jan 2008 21:49:30 GMT
  ETag: "790116-449c-478a876a"
  Accept-Ranges: bytes
  Content-Type: application/rdf+xml
  Content-length: 17564
  Connection: close
  Age: 501321

  ---response end---
  200 OK
  Length: 17564 (17K) [application/rdf+xml]
  Saving to: `dcelements.rdf'

  Closed fd 3
  2008-07-21 10:22:45 (856 KB/s) - `dcelements.rdf' saved [17564/17564]
Received on Monday, 21 July 2008 10:15:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:23 UTC