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

Eran Hammer-Lahav wrote:
> Let me try explaining my use case again, this time without any overloaded terminology or proposed solutions.
> 
> ---
> 
> XRD is a document format for describing resources. It looks like this:
> 
> <XRD>
> 	<Subject>http://example.com</Subject>
> 	<Type>http://example.org/type/blog</Type>
> 	<Link>
> 		<Rel>author</Rel>
> 		<URI>http://example.com/author</URI>
> 	</URI>
> </XRD>
> 
> Without getting too much into XRD, this short descriptor describes the resource identified by 'http://example.com'. It includes one type indicator (a made up example meant to mean this resource is a blog), and one link to the author's page.
> 
> ---
> 
> I want to use this document format to describe rules that apply to all resources which belong to an HTTP host (as defined by 2616: a domain/address and port combination). The problem is, <Subject> requires a URI and currently there is no way to identify this set of resources (http://domain:port/*) as a valid URI.

As I see it, the problem is that you require type to be a URI. Why? Why 
not encode your rules instead? POWDER does this in a way that could, if 
you so chose, be applied pretty well directly in XRD so that it would 
look like:


<XRD>
	<Subject>
		<includeschemes>http</includeschemes>
		<includehosts>example.com</includehosts>
	</Subject>
	<Type>http://example.org/type/blog</Type>
	<Link>
		<Rel>author</Rel>
		<URI>http://example.com/author</URI>
	</URI>
</XRD>

The approach POWDER takes is to define constraints on URIs. In this 
case, we've constrained the host and the scheme. Any resource on any 
subdomain of example.com, on any port, is now in scope. You reduce the 
scope by adding in further constraints.  You can also provide 
alternatives in white space separated lists so that, for example, if you 
wanted to allow http or https (but not other schemes) then you'd have:

<includeschemes>http https</includeschemes>

and so on.

Your example shows just how similar XRD and POWDER are. They have 
different use cases and serve different audiences and I'm not, for a 
moment, suggesting that one subsumes the other, but for the record, your 
example could be written in POWDER as:

<powder>
   <attribution>
     <issuedby src="http://example.com/author" />
   </attribution>
   <dr>
     <iriset>
       <includeschemes>http</includeschemes>
       <includehosts>example.com</includehosts>
     </iriset>
     <descriptorset>
       <typeof src="http://example.org/type/blog" />
       <dcterms:creator src="http://example.com/author" />
     </descriptorset>
   <dr>
</powder>

This is a declaration by the author that s/he is the author of the blog 
which comprises the entirety of example.com. As you can see, it's done 
entirely in XML and can be processed as such. Semantic folk can also 
process this and extract RDF triples about individual URIs on the 
example.com host and if you run the transformation you can get an OWL 
ontology out of this too - but that's all optional.

> 
> What I don't want to do is use an exception such as 'if the URI begins with X, treat it as a rule and not a valid URI'...

Agreed, that would be awful.

Cheers

Phil.

> 
>> -----Original Message-----
>> From: ashok malhotra [mailto:ashok.malhotra@oracle.com]
>> Sent: Saturday, June 27, 2009 6:08 PM
>> To: Eran Hammer-Lahav
>> Cc: apps-discuss@ietf.org; www-tag@w3.org; URI
>> Subject: 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
>>>
>>>
>>>
>>>
> 
> 

-- 

Phil Archer
http://philarcher.org/

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

Received on Monday, 29 June 2009 08:32:09 UTC