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

[Eran Hammer-Lahav]

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

[Dan Connolly]

Eran Hammer-Lahav wrote:
[...]

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

For domains, there's a proposed standard.
See:

Domain Name System Uniform Resource Identifiers (RFC 4501) Josefsson May
2006.
http://www.rfc-editor.org/rfc/rfc4501.txt

According to that, the 1st would be:

   dns:example.com


I can't find any RFCs on hosts, origins, etc.

For abstract things in general, I like just
using dynamic lookup via http:
   http://anysite.you.can.publish.on/mydescription#host-site-whatever




--
Dan Connolly, W3C http://www.w3.org/People/Connolly/

[Eran Hammer-Lahav]

> From: Dan Connolly [mailto:connolly@...]
> Sent: Thursday, June 25, 2009 3:01 PM

> For domains, there's a proposed standard.
> See:
>
> Domain Name System Uniform Resource Identifiers (RFC 4501) Josefsson
> May
> 2006.
> http://www.rfc-editor.org/rfc/rfc4501.txt
>
> According to that, the 1st would be:
>
>    dns:example.com

I am not sure this is useful because it has clear semantic meaning representing a DNS record, not some abstract concept. I can't figure out what a descriptor about dns:example.com actually mean because I don't know what a description of a DNS record means (other than comments).

> I can't find any RFCs on hosts, origins, etc.
>
> For abstract things in general, I like just
> using dynamic lookup via http:
>    http://anysite.you.can.publish.on/mydescription#host-site-whatever

How would a client know that this URI isn't for an actual HTTP resource without creating "well-known-location" URIs (option #1 in my original email)?

EHL

[Xiaoshu Wang]

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

What we need is a special syntax to mean that a URI denotes for itself.  
Just like in natural language, that we use quotation mark to distinguish
between the word "New York City" and New York City.  Once we have that,
then we are free to define any ontology to describe the composition of a
URI, just like anything else.  Proposing anything else is simply an
over-kill, let alone another URN.

Xiaoshu

[Eran Hammer-Lahav]

> -----Original Message-----
> From: Xiaoshu Wang [mailto:wangxiao@...]
> Sent: Thursday, June 25, 2009 4:24 PM

> What we need is a special syntax to mean that a URI denotes for itself.
> Just like in natural language, that we use quotation mark to
> distinguish
> between the word "New York City" and New York City.  Once we have that,
> then we are free to define any ontology to describe the composition of
> a URI, just like anything else.

Without passing judgment on your proposal, it is clearly not something that can be accomplished within a short time frame. I have a very specific need to indicate a document describes "a host" which is a combination of domain, port, and potentially protocol. I just need to say it formatted as a URI.

> Proposing anything else is simply an over-kill, let alone another URN.

If anything, it is your proposal that is an over-kill.

EHL

[Xiaoshu Wang]

Eran Hammer-Lahav wrote:

>> -----Original Message-----
>> From: Xiaoshu Wang [mailto:wangxiao@...]
>> Sent: Thursday, June 25, 2009 4:24 PM
>>    
>
>  
>> What we need is a special syntax to mean that a URI denotes for itself.
>> Just like in natural language, that we use quotation mark to
>> distinguish
>> between the word "New York City" and New York City.  Once we have that,
>> then we are free to define any ontology to describe the composition of
>> a URI, just like anything else.
>>    
>
> Without passing judgment on your proposal, it is clearly not something that can be accomplished within a short time frame. I have a very specific need to indicate a document describes "a host" which is a combination of domain, port, and potentially protocol. I just need to say it formatted as a URI.
>
>  
>> Proposing anything else is simply an over-kill, let alone another URN.
>>    
>
> If anything, it is your proposal that is an over-kill.
>
> EHL
>  

Let a discussion be driven by reason, but not pride.

Xiaoshu

[John Cowan]

Eran Hammer-Lahav scripsit:

> Without passing judgment on your proposal, it is clearly not something
> that can be accomplished within a short time frame. I have a very
> specific need to indicate a document describes "a host" which is a
> combination of domain, port, and potentially protocol. I just need to
> say it formatted as a URI.

A simple approach would be to use a data: URI (see RFC 2397) of the form
"data:application/uri,http://www.ccil.org".  I proposed this for a related
purpose during the Great XML Namespace Debate, but it didn't get traction.

--
Your worships will perhaps be thinking          John Cowan
that it is an easy thing to blow up a dog?      http://www.ccil.org/~cowan
[Or] to write a book?
    --Don Quixote, Introduction                 cowan@...

[Eran Hammer-Lahav]

Not sure how this is going to help. You still end up with an HTTP URI with no clear semantic meaning other than an HTTP resource.

EHL

> -----Original Message-----
> From: John Cowan [mailto:cowan@...]
> Sent: Thursday, June 25, 2009 6:03 PM
> To: Eran Hammer-Lahav
> Cc: Xiaoshu Wang; apps-discuss@...; www-tag@...; URI
> Subject: Re: URI for abstract concepts (domain, host, origin, site,
> etc.)
>
> Eran Hammer-Lahav scripsit:
>
> > Without passing judgment on your proposal, it is clearly not
> something
> > that can be accomplished within a short time frame. I have a very
> > specific need to indicate a document describes "a host" which is a
> > combination of domain, port, and potentially protocol. I just need to
> > say it formatted as a URI.
>
> A simple approach would be to use a data: URI (see RFC 2397) of the
> form
> "data:application/uri,http://www.ccil.org".  I proposed this for a
> related
> purpose during the Great XML Namespace Debate, but it didn't get
> traction.
>
> --
> Your worships will perhaps be thinking          John Cowan
> that it is an easy thing to blow up a dog?
> http://www.ccil.org/~cowan
> [Or] to write a book?
>     --Don Quixote, Introduction                 cowan@...

[Dan Connolly]

Eran Hammer-Lahav wrote:

>> From: Dan Connolly [mailto:connolly@...]
>> Sent: Thursday, June 25, 2009 3:01 PM
>
>> For domains, there's a proposed standard.
>> See:
>>
>> Domain Name System Uniform Resource Identifiers (RFC 4501) Josefsson
>> May
>> 2006.
>> http://www.rfc-editor.org/rfc/rfc4501.txt
>>
>> According to that, the 1st would be:
>>
>>    dns:example.com
>
> I am not sure this is useful because it has clear semantic meaning representing a DNS record, not some abstract concept.

Oops; OK. I didn't notice the subtlety.

> I can't figure out what a descriptor about dns:example.com actually mean because I don't know what a description of a DNS record means (other than comments).
>
>> I can't find any RFCs on hosts, origins, etc.
>>
>> For abstract things in general, I like just
>> using dynamic lookup via http:
>>    http://anysite.you.can.publish.on/mydescription#host-site-whatever
>
> How would a client know that this URI isn't for an actual HTTP resource without creating "well-known-location" URIs (option #1 in my original email)?

It _is_ for an actual HTTP resource; i.e. something
described/discussed in a document you can get by HTTP. Since
documents can describe/discuss anything, they can describe/discuss
things like origins and such. RDF is particularly suited
for this purpose, but I can imagine other media types
might work too... text/html with RDFa is pretty hip
these days.


--
Dan Connolly, W3C http://www.w3.org/People/Connolly/

[John Cowan]

Eran Hammer-Lahav scripsit:

> Not sure how this is going to help. You still end up with an HTTP URI
> with no clear semantic meaning other than an HTTP resource.

What do you mean by "end up with"?  A data URI is not an HTTP URI.
<http://www.ccil.org> refefers to the home page of ccil.org;
<data:application/uri,http://www.ccil.org> refers to the URI
<http://www.ccil.org>.  They are two different URIs with two different
referents.

--
John Cowan              http://www.ccil.org/~cowan      cowan@...
"After all, would you consider a man without honor wealthy, even if his
Dinar laid end to end would reach from here to the Temple of Toplat?"
"No, I wouldn't", the beggar replied.  "Why is that?" the Master asked.
"A Dinar doesn't go very far these days, Master.        --Kehlog Albran
Besides, the Temple of Toplat is across the street."      The Profit

[Eran Hammer-Lahav]

> From: Dan Connolly [mailto:connolly@...]
> Sent: Thursday, June 25, 2009 7:52 PM

> > How would a client know that this URI isn't for an actual HTTP
> resource without creating "well-known-location" URIs (option #1 in my
> original email)?
>
> It _is_ for an actual HTTP resource; i.e. something
> described/discussed in a document you can get by HTTP. Since
> documents can describe/discuss anything, they can describe/discuss
> things like origins and such. RDF is particularly suited
> for this purpose, but I can imagine other media types
> might work too... text/html with RDFa is pretty hip
> these days.

In my case, the "resource" is the concept of a host, which is the combination of a domain name, port number, and protocol used on that port. I want to be able to describe this host by saying, "this is how you transform any HTTP URI that belongs to this host to the URI of its metadata". There are plenty of ways to express this statement but so far I don't have a good way to express the subject of this statement - the host.

Of course, I can come up with something like this:

http://abstract.example.net/host/example.com:80:http

And simply include in the protocol that the http://abstract.example.net/host/ prefix is a special case exception. But while such solutions (a URI version of a well-known location) might be acceptable for HTTP servers due to the complexity and cost of deploying changes to the infrastructure (such as a new HTTP method), they are less acceptable for URIs which can be easily extended with nothing more than a couple pages of spec...

It is almost as easy to register a new URI scheme or URN namespace as it is for me to buy and maintain a new domain name. But I think in this case, the reserved domain name is a lot more offensive to web architecture than a new URI scheme or some other URI-based solution.

I am also happy to make this as specific as needed for my super special use case and mint a new host: URI scheme.

EHL

[Eran Hammer-Lahav]

You are right. But this only means that a document about <data:application/uri,http://www.ccil.org> is simply a description of the URI itself. This still does not help me relay the concept of a host. I still don't know what to put inside this data URI to convey this.

EHL

> -----Original Message-----
> From: John Cowan [mailto:cowan@...]
> Sent: Thursday, June 25, 2009 8:04 PM
> To: Eran Hammer-Lahav
> Cc: John Cowan; apps-discuss@...; www-tag@...; URI
> Subject: Re: URI for abstract concepts (domain, host, origin, site,
> etc.)
>
> Eran Hammer-Lahav scripsit:
>
> > Not sure how this is going to help. You still end up with an HTTP URI
> > with no clear semantic meaning other than an HTTP resource.
>
> What do you mean by "end up with"?  A data URI is not an HTTP URI.
> <http://www.ccil.org> refefers to the home page of ccil.org;
> <data:application/uri,http://www.ccil.org> refers to the URI
> <http://www.ccil.org>.  They are two different URIs with two different
> referents.
>
> --
> John Cowan              http://www.ccil.org/~cowan      cowan@...
> "After all, would you consider a man without honor wealthy, even if his
> Dinar laid end to end would reach from here to the Temple of Toplat?"
> "No, I wouldn't", the beggar replied.  "Why is that?" the Master asked.
> "A Dinar doesn't go very far these days, Master.        --Kehlog Albran
> Besides, the Temple of Toplat is across the street."      The Profit

["Martin J. Dürst"]

On 2009/06/26 12:18, Eran Hammer-Lahav wrote:

> In my case, the "resource" is the concept of a host, which is the combination of a domain name, port number, and protocol used on that port. I want to be able to describe this host by saying, "this is how you transform any HTTP URI that belongs to this host to the URI of its metadata". There are plenty of ways to express this statement but so far I don't have a good way to express the subject of this statement - the host.
>
> Of course, I can come up with something like this:
>
> http://abstract.example.net/host/example.com:80:http
>
> And simply include in the protocol that the http://abstract.example.net/host/ prefix is a special case exception. But while such solutions (a URI version of a well-known location) might be acceptable for HTTP servers due to the complexity and cost of deploying changes to the infrastructure (such as a new HTTP method), they are less acceptable for URIs which can be easily extended with nothing more than a couple pages of spec...
>
> It is almost as easy to register a new URI scheme or URN namespace as it is for me to buy and maintain a new domain name. But I think in this case, the reserved domain name is a lot more offensive to web architecture than a new URI scheme or some other URI-based solution.
>
> I am also happy to make this as specific as needed for my super special use case and mint a new host: URI scheme.

This seems to indicate that 'host' is just one kind or type of thing.
There are tons and tons of other such things. Apples, oranges,
blueberries, just to start with. The idea that we need a new URI scheme
for every kind of data or thing that we want to talk about seems highly
unscalable. Also, your concept of 'host' may be slightly different from
what somebody else would think a 'host' is or has to be. Again, defining
a 'host:' URI scheme very much looks like a non-starter. I don't exactly
understand what you think your problem is, but I think it's a mistake to
assume that because you have something that you can denote with almost
the same information as available in an HTTP URI (that wouldn't be true
for apples and oranges), it should have a scheme.

Regards,   Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@...

[Larry Masinter-3]

This sounds like a job for .... tdb!
http://larry.masinter.net/duri.html

urn:tdb::data:,the%20host%20www.ccil.org
urn:tdb::data:,the%20site%20www.ccil.org

My guess is that this doesn't meet your requirements, but perhaps you could be more explicit about those?

Larry


-----Original Message-----
From: www-tag-request@... [mailto:www-tag-request@...] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, June 25, 2009 8:20 PM
To: John Cowan
Cc: apps-discuss@...; www-tag@...; URI
Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.)

You are right. But this only means that a document about <data:application/uri,http://www.ccil.org> is simply a description of the URI itself. This still does not help me relay the concept of a host. I still don't know what to put inside this data URI to convey this.

EHL

> -----Original Message-----
> From: John Cowan [mailto:cowan@...]
> Sent: Thursday, June 25, 2009 8:04 PM
> To: Eran Hammer-Lahav
> Cc: John Cowan; apps-discuss@...; www-tag@...; URI
> Subject: Re: URI for abstract concepts (domain, host, origin, site,
> etc.)
>
> Eran Hammer-Lahav scripsit:
>
> > Not sure how this is going to help. You still end up with an HTTP URI
> > with no clear semantic meaning other than an HTTP resource.
>
> What do you mean by "end up with"?  A data URI is not an HTTP URI.
> <http://www.ccil.org> refefers to the home page of ccil.org;
> <data:application/uri,http://www.ccil.org> refers to the URI
> <http://www.ccil.org>.  They are two different URIs with two different
> referents.
>
> --
> John Cowan              http://www.ccil.org/~cowan      cowan@...
> "After all, would you consider a man without honor wealthy, even if his
> Dinar laid end to end would reach from here to the Temple of Toplat?"
> "No, I wouldn't", the beggar replied.  "Why is that?" the Master asked.
> "A Dinar doesn't go very far these days, Master.        --Kehlog Albran
> Besides, the Temple of Toplat is across the street."      The Profit

[Rob Sanderson]

You could use an info URI, which were specifically registered for abstract concepts.

http://www.info-uri.info/

Rob Sanderson

________________________________________
From: uri-request@... [uri-request@...] On Behalf Of Eran Hammer-Lahav [eran@...]
Sent: 26 June 2009 04:18
To: Dan Connolly
Cc: apps-discuss@...; www-tag@...; URI
Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.)

> From: Dan Connolly [mailto:connolly@...]
> Sent: Thursday, June 25, 2009 7:52 PM

> > How would a client know that this URI isn't for an actual HTTP
> resource without creating "well-known-location" URIs (option #1 in my
> original email)?
>
> It _is_ for an actual HTTP resource; i.e. something
> described/discussed in a document you can get by HTTP. Since
> documents can describe/discuss anything, they can describe/discuss
> things like origins and such. RDF is particularly suited
> for this purpose, but I can imagine other media types
> might work too... text/html with RDFa is pretty hip
> these days.

In my case, the "resource" is the concept of a host, which is the combination of a domain name, port number, and protocol used on that port. I want to be able to describe this host by saying, "this is how you transform any HTTP URI that belongs to this host to the URI of its metadata". There are plenty of ways to express this statement but so far I don't have a good way to express the subject of this statement - the host.

Of course, I can come up with something like this:

http://abstract.example.net/host/example.com:80:http

And simply include in the protocol that the http://abstract.example.net/host/ prefix is a special case exception. But while such solutions (a URI version of a well-known location) might be acceptable for HTTP servers due to the complexity and cost of deploying changes to the infrastructure (such as a new HTTP method), they are less acceptable for URIs which can be easily extended with nothing more than a couple pages of spec...

It is almost as easy to register a new URI scheme or URN namespace as it is for me to buy and maintain a new domain name. But I think in this case, the reserved domain name is a lot more offensive to web architecture than a new URI scheme or some other URI-based solution.

I am also happy to make this as specific as needed for my super special use case and mint a new host: URI scheme.

EHL

[Erik Wilde-3]

hello.

i think there is a lot of meat in this discussion from the perspective
of web architecture. to a large extent, this is getting back to the old
question about "when to create new URI schemes".

Larry Masinter wrote:
> urn:tdb::data:,the%20host%20www.ccil.org

this is an interesting approach, and creates completely opaque URIs, not
that much different from data:, i think. in general, the options for
identifying something that is not by its very nature a HTTP-accessible
resource are:

- use http: anyway with some special rules attached (eg, httpRange-14).
- use an opaque scheme such as data: or urn:tdb::
- create a new scheme.

i think there is value to a new scheme if there are specific
interactions with resources of that new type. for example, there is a
lot of value now in tel: URIs because more and more browsers also are
phones, so they can provide users with a useful (and non-HTTP) way of
interacting with the identified resources (HTTP-only browsers could use
skype or provide phone book lookup services, too, btw). anyway, my point
is that tel: now proves its utility because URIs can simply refer to a
phone and by the mere fact of identifying them, there are well-known
methods of interaction. it's really just following a hyperlink, only
that the link takes the user outside of the realm of HTTP.

the reason why i am bringing this old debate up again is that felix,
michael (cc'ed) and i will start a W3C incubation group soon, which will
look at "location and the web". one of my goals there is to explore the
question of a possible location URI scheme (among other things), because
i think that there are many interesting and rich interactions around
resources of the "location" type. i do know there will be pushback (i
proposed it on uri@... a while ago and the main pushback was to go
the "everything should be a HTTP URI" route), but a W3C incubation group
will be the perfect vehicle for discussing the merits of different
approaches of how to make the web location-aware.

and regardless of the location theme, i think the general question of
"when to mint URI schemes" is a very interesting one. my working theory
still is that it should be done if (and maybe only if) there are known
or predicted methods (that's fuzzy, but i cannot think of a better way
of saying it) of how to interact with that specific kind of resource.

cheers,

erik wilde   tel:[phone] - fax:[phone]
        dret@...  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

[Phil Archer-3]

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

[Eran Hammer-Lahav]

My definition of host comes from RFC 2616.

What I am looking for is a way to express a web concept for the purpose of describing its attributes as a URI. It needs to be a URI because the frameworks we use to describe things on the web are all limited to describing resources identified with URI.

The only option I would like to rule out is to use a reserved HTTP URI for this purpose. I am open to pretty much all other options, if they correctly convey the idea of "host", "domain", etc.

EHL

> -----Original Message-----
> From: "Martin J. Dürst" [mailto:duerst@...]
> Sent: Thursday, June 25, 2009 11:46 PM
> To: Eran Hammer-Lahav
> Cc: Dan Connolly; apps-discuss@...; www-tag@...; URI
> Subject: Re: URI for abstract concepts (domain, host, origin, site,
> etc.)
>
> On 2009/06/26 12:18, Eran Hammer-Lahav wrote:
>
> > In my case, the "resource" is the concept of a host, which is the
> combination of a domain name, port number, and protocol used on that
> port. I want to be able to describe this host by saying, "this is how
> you transform any HTTP URI that belongs to this host to the URI of its
> metadata". There are plenty of ways to express this statement but so
> far I don't have a good way to express the subject of this statement -
> the host.
> >
> > Of course, I can come up with something like this:
> >
> > http://abstract.example.net/host/example.com:80:http
> >
> > And simply include in the protocol that the
> http://abstract.example.net/host/ prefix is a special case exception.
> But while such solutions (a URI version of a well-known location) might
> be acceptable for HTTP servers due to the complexity and cost of
> deploying changes to the infrastructure (such as a new HTTP method),
> they are less acceptable for URIs which can be easily extended with
> nothing more than a couple pages of spec...
> >
> > It is almost as easy to register a new URI scheme or URN namespace as
> it is for me to buy and maintain a new domain name. But I think in this
> case, the reserved domain name is a lot more offensive to web
> architecture than a new URI scheme or some other URI-based solution.
> >
> > I am also happy to make this as specific as needed for my super
> special use case and mint a new host: URI scheme.
>
> This seems to indicate that 'host' is just one kind or type of thing.
> There are tons and tons of other such things. Apples, oranges,
> blueberries, just to start with. The idea that we need a new URI scheme
> for every kind of data or thing that we want to talk about seems highly
> unscalable. Also, your concept of 'host' may be slightly different from
> what somebody else would think a 'host' is or has to be. Again,
> defining
> a 'host:' URI scheme very much looks like a non-starter. I don't
> exactly
> understand what you think your problem is, but I think it's a mistake
> to
> assume that because you have something that you can denote with almost
> the same information as available in an HTTP URI (that wouldn't be true
> for apples and oranges), it should have a scheme.
>
> Regards,   Martin.
>
> --
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@...

[Pat Hayes]

On Jun 25, 2009, at 10:18 PM, Eran Hammer-Lahav wrote:

>> From: Dan Connolly [mailto:connolly@...]
>> Sent: Thursday, June 25, 2009 7:52 PM
>
>>> How would a client know that this URI isn't for an actual HTTP
>> resource without creating "well-known-location" URIs (option #1 in my
>> original email)?
>>
>> It _is_ for an actual HTTP resource; i.e. something
>> described/discussed in a document you can get by HTTP. Since
>> documents can describe/discuss anything, they can describe/discuss
>> things like origins and such. RDF is particularly suited
>> for this purpose, but I can imagine other media types
>> might work too... text/html with RDFa is pretty hip
>> these days.
>
> In my case, the "resource" is the concept of a host, which is the  
> combination of a domain name, port number, and protocol used on that  
> port. I want to be able to describe this host by saying, "this is  
> how you transform any HTTP URI that belongs to this host to the URI  
> of its metadata". There are plenty of ways to express this statement  
> but so far I don't have a good way to express the subject of this  
> statement - the host.

To me this sounds like a clear use case for an RDF blank node. You  
want to refer to some (category of) thing that has no current naming  
convention, but which you can describe in terms of its properties.  
That is exactly what RDF bnodes were invented for. The relevant RDF  
graph fragment would look something like this, using triples notation  
for clarity:

_:x rdf:type :HostClassName .
_"x :hasDomainName <nameasastringliteral>^^xsd:string .
_:x :hasPortNumber <portnumber>^^xsd:number .  (Or maybe you want to  
keep it as a string)
_:x :usesProtocol  .... (Not sure how to express this, you might have  
to  use a literal to encode the protocol name or some such, unless  
there is an ontology of protocols out there somewhere.)

to which you then add whatever you want to say about it, with that  
same _:x as subject.

If you (as many people do) dislike bnodes, than just invent a naming  
convention with URI references #ed onto a suitable URI you own: the  
use of # gives you freedom to use your own naming style, and bypasses  
the http-range-14 referential problems arising from the use of a bare  
URI.

Pat Hayes

>
> Of course, I can come up with something like this:
>
> http://abstract.example.net/host/example.com:80:http
>
> And simply include in the protocol that the http://abstract.example.net/host/ 
>  prefix is a special case exception. But while such solutions (a URI  
> version of a well-known location) might be acceptable for HTTP  
> servers due to the complexity and cost of deploying changes to the  
> infrastructure (such as a new HTTP method), they are less acceptable  
> for URIs which can be easily extended with nothing more than a  
> couple pages of spec...
>
> It is almost as easy to register a new URI scheme or URN namespace  
> as it is for me to buy and maintain a new domain name. But I think  
> in this case, the reserved domain name is a lot more offensive to  
> web architecture than a new URI scheme or some other URI-based  
> solution.
>
> I am also happy to make this as specific as needed for my super  
> special use case and mint a new host: URI scheme.
>
> EHL
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Eran Hammer-Lahav]

It still needs to fit into an element that can only accept a URI. If I end up using a URI I own and put the actual host information in the fragment as suggested, I end up with exactly the kind of solution I am trying to avoid which is making exceptions and defining well-known HTTP URIs that are treated differently.

EHL

> -----Original Message-----
> From: www-tag-request@... [mailto:www-tag-request@...] On Behalf
> Of Pat Hayes
> Sent: Friday, June 26, 2009 8:47 AM
> To: Eran Hammer-Lahav
> Cc: Dan Connolly; apps-discuss@...; www-tag@...; URI
> Subject: Re: URI for abstract concepts (domain, host, origin, site,
> etc.)
>
>
> On Jun 25, 2009, at 10:18 PM, Eran Hammer-Lahav wrote:
>
> >> From: Dan Connolly [mailto:connolly@...]
> >> Sent: Thursday, June 25, 2009 7:52 PM
> >
> >>> How would a client know that this URI isn't for an actual HTTP
> >> resource without creating "well-known-location" URIs (option #1 in
> my
> >> original email)?
> >>
> >> It _is_ for an actual HTTP resource; i.e. something
> >> described/discussed in a document you can get by HTTP. Since
> >> documents can describe/discuss anything, they can describe/discuss
> >> things like origins and such. RDF is particularly suited
> >> for this purpose, but I can imagine other media types
> >> might work too... text/html with RDFa is pretty hip
> >> these days.
> >
> > In my case, the "resource" is the concept of a host, which is the
> > combination of a domain name, port number, and protocol used on that
> > port. I want to be able to describe this host by saying, "this is
> > how you transform any HTTP URI that belongs to this host to the URI
> > of its metadata". There are plenty of ways to express this statement
> > but so far I don't have a good way to express the subject of this
> > statement - the host.
>
> To me this sounds like a clear use case for an RDF blank node. You
> want to refer to some (category of) thing that has no current naming
> convention, but which you can describe in terms of its properties.
> That is exactly what RDF bnodes were invented for. The relevant RDF
> graph fragment would look something like this, using triples notation
> for clarity:
>
> _:x rdf:type :HostClassName .
> _"x :hasDomainName <nameasastringliteral>^^xsd:string .
> _:x :hasPortNumber <portnumber>^^xsd:number .  (Or maybe you want to
> keep it as a string)
> _:x :usesProtocol  .... (Not sure how to express this, you might have
> to  use a literal to encode the protocol name or some such, unless
> there is an ontology of protocols out there somewhere.)
>
> to which you then add whatever you want to say about it, with that
> same _:x as subject.
>
> If you (as many people do) dislike bnodes, than just invent a naming
> convention with URI references #ed onto a suitable URI you own: the
> use of # gives you freedom to use your own naming style, and bypasses
> the http-range-14 referential problems arising from the use of a bare
> URI.
>
> Pat Hayes
>
> >
> > Of course, I can come up with something like this:
> >
> > http://abstract.example.net/host/example.com:80:http
> >
> > And simply include in the protocol that the
> http://abstract.example.net/host/
> >  prefix is a special case exception. But while such solutions (a URI
> > version of a well-known location) might be acceptable for HTTP
> > servers due to the complexity and cost of deploying changes to the
> > infrastructure (such as a new HTTP method), they are less acceptable
> > for URIs which can be easily extended with nothing more than a
> > couple pages of spec...
> >
> > It is almost as easy to register a new URI scheme or URN namespace
> > as it is for me to buy and maintain a new domain name. But I think
> > in this case, the reserved domain name is a lot more offensive to
> > web architecture than a new URI scheme or some other URI-based
> > solution.
> >
> > I am also happy to make this as specific as needed for my super
> > special use case and mint a new host: URI scheme.
> >
> > EHL
> >
> >
> >
>
> ------------------------------------------------------------
> IHMC                                     [phone] or [phone]
> 40 South Alcaniz St.           [phone]   office
> Pensacola                            [phone]   fax
> FL 32502                              [phone]   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>