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

Hi Eran,

Comments inline below.

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.

No, not really. Like XRD and its template URIs, we have a simple, 
XML-based syntax that encodes what is described and who is describing 
it. POWDER also transports the RDF properties and values so that for a 
given input URI, you can extract the description (as triples). That's 
the job of the POWDER Processor.

In other words, one simple document can be processed to extract 
information about individuals within a collection of resources. In RDF 
terms, the question is "I know the subject, can you give me any 
predicates and objects?"

> 
> We have some use cases in which the subject of the descriptor does not have a URI available.

Sympathy. We had that too and had to find a way to handle it.

> 
> 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.

As you know, this is where we diverge philosophically . Well known 
locations go against the architecture of the web which is about URIs 
that link one thing to another and IMHO are a bad solution to anything 
but I'll refrain from opening that one again ;-) . As well as using the 
two link methods, we have the idea that a POWDER Processor can be a 
front end for a repository of descriptions that may not be linked from 
anywhere.

> 
> 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.

I disagree. HTTP Link (and HTML link) cover it just fine. In my 
experience, it's not the lack of URI concepts that's the problem, it's 
the concept of a root resource that is the stumbling block. What is the 
root resource for http://www.facebook.com/philarcher1 ? Surely not the 
root of facebook.com. (the same applies, of course, to all those 
isp.com/~username/ websites).

> 
> 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).

I don't think you can put it in a string of characters - it's software 
that has to match up a given URI with what's in the XRD document (or 
POWDER or whatever). It can be lightweight software, but nevertheless, 
you need to have some idea of the structure of the resources/services 
you're describing encoded in some way and a method for reading that 
encoding in the context of a specific request.

> 
> 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 ______.

Please no. An exception to the rules on how you treat a URI? No.
> 
> 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.

That's more doable, yes, but I still don't think it's necessary.

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

Would your putative scheme include subdomains? In other words, if I have

abstract://example.com/domain

does that also cover everything on www.example.com ?

And how flexible can it be? How would I say 'anything on example.com 
that ends with .jpg' ? Or that has a path containing 'foo' and 'bar' ?

The working group I'm about to refer to has moved on now but a couple of 
years ago it defined a method of describing domains with the use case of 
cross-domain access control [1] which we used wholesale in the POWDER 
Grouping spec [2]. In short,

abstract://example.com/domain DOES include all subdomains but you can 
also say abstract://*.example.com/domain which is all subdomains of 
example.com but not example.com itself.

When POWDER started we thought that the resource grouping issue would be 
the biggest challenge which is why we tackled it first. Actually, the 
Proposed Rec document is the least changed of any of the specs since it 
was first published. We use set theory to under pin the whole thing and 
we're able to show that it can express any resource group, no matter how 
complex [3].


[1] http://www.w3.org/TR/2007/WD-access-control-20071001/#access0
[2] http://www.w3.org/TR/2009/PR-powder-grouping-20090604/#wild
[3] http://www.w3.org/TR/2009/PR-powder-grouping-20090604/#conj-disj

> 
> Any comments, feedback, or concerns would be greatly appreciated.

Dunno if this helps any.

Phil.

> 
> [1] http://tools.ietf.org/html/draft-hammer-discovery
> 
> 
> 

-- 

Phil Archer
http://philarcher.org/

i-sieve technologies                |      W3C Mobile Web Initiative
Beyond Impressions                  |      www.w3.org/Mobile

Received on Friday, 26 June 2009 09:46:46 UTC