Re: URI for abstract concepts (domain, host, origin, site, etc.)

Hi Eran:
Trying to understand your proposal.
By 'abstract' do you mean URIs for which a representation cannot be 
retrieved?
So, perhaps, a chair?

My assumption was that for such resources you want to retrieve the 
metadata. 
To do that you do a GET which returns a 'Not Found' as well as a Link 
Header.

Of course, if you know syntactically that the resource does not have a 
representation
you can save one access and go directly for the metadata.

Is that where you are going?

All the best, Ashok


Eran Hammer-Lahav wrote:
> LRDD [1] defines a way to link a descriptor (metadata, information about, etc.) to a resource. It keeps the document format of the descriptor out of scope, leaving it up to existing formats (XRDS, XRD, POWDER, Metalink, etc.) and new format to address.
>
> Most of these descriptor formats include an element which indicates what the document is about - the subject of the descriptor. XRD includes the <Subject> element for this purpose with xs:anyURI as its type. I believe POWDER uses RDF's 'about' attribute in a similar way IIRC.
>
> We have some use cases in which the subject of the descriptor does not have a URI available.
>
> LRDD uses a well-known-location document (/host-meta, soon to be replaced with /.well-known/host-meta) to store information about the abstract host resource (the combination of domain name and port number, potentially also including protocol). Over the past few years, ad-hoc protocols have been abusing the root resource URI to mean something beyond just the root resource of a domain - basically as a placeholder for information about the entire domain or host.
>
> The lack of URI for such concepts is preventing descriptor formats from being used here because there is no valid URI available to insert into the subject container. While no representation is expected for such abstract concepts, within the context of descriptors, being able to reference them is critical.
>
> The use case at hand is using XRD as the document format for host-meta. Host-meta describes attributes of the host which by itself does not currently have a URI. We need to figure out what to put in the host-meta document's <Subject> element which has direct impact on the trust profile and signature (but is outside the scope of this discussion).
>
> So far I could only come up with two options:
>
> 1. Make a special case exception that when the subject is http://______/.well-known/host-meta, it is treated differently than any other URI in that it means the XRD is not about that URI (the host-meta document itself), but about the abstract host resource located at ______.
>
> 2. Define a new kind of URI that can be used for abstract entities such as "host" or "domain", but which is not an http URI because that will bring us right back to #1.
>
> I would like to ask for feedback on the idea of proposing a new URI scheme or a new URN namespace for this purpose, something like 'abstract'.
> It will look something like this (please focus on the idea, not the syntax of the examples):
>
> urn:abstract:domain:example.com
> urn:abstract:host:example.com:8080
> urn:abstract:origin:example.com:8080:http
>
> or
>
> abstract://example.com/domain
> abstract://example.com:8080/host
> abstract://example.com:8080:http/origin
>
> Any comments, feedback, or concerns would be greatly appreciated.
>
> EHL
>
> [1] http://tools.ietf.org/html/draft-hammer-discovery
>
>
>
>

Received on Sunday, 28 June 2009 01:08:42 UTC