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

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 25 Jun 2009 11:57:48 -0700

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

---

From: Timur Shemsedinov <[email-masked]>
Date: Thu, 25 Jun 2009 23:46:18 +0300

Hello,

On Thu, Jun 25, 2009 at 9:57 PM, Eran Hammer-Lahav <[email-masked]>wrote:

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

I think URN is not applicable for those URIs, because all those URIs
includes complete information for resource location, so you should use URLs
(but not http urls).

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

"abstract" schema name is not a good idea, because level of such abstraction
is unclear. "abstract" is too abstract word
Better use "host" for listed purposed, like in example:

If wou wont to identify/locate domain <http://example.com/domain>s use *
host:example.com*
If wou wont to identify/locate service on port use *host:example.com:8080*
If wou wont to identify/locate exact http on port 8080 use *
http://example.com:8080*
If wou wont to identify/locate host by ip use *host:208.77.188.166
*
note that you can not use "://" if URL is not designed to locate resource
associated with path as in http

~Timur

---

From: Dan Connolly <[email-masked]>
Date: Thu, 25 Jun 2009 18:00:34 -0400

Eran Hammer-Lahav wrote:
[...]
> 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/

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 25 Jun 2009 15:56:02 -0700

> From: Dan Connolly [mailto:[email-masked]]
> Sent: Thursday, June 25, 2009 3:01 PM

> According to that, the 1st would be:

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

>    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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 25 Jun 2009 16:36:31 -0700

> -----Original Message-----
> From: Xiaoshu Wang [mailto:[email-masked]]
> 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 25 Jun 2009 19:14:07 -0700

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

> From: John Cowan [mailto:[email-masked]]
> Sent: Thursday, June 25, 2009 6:03 PM
> To: Eran Hammer-Lahav
> Cc: Xiaoshu Wang; [email-masked]; [email-masked]; 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                 [email-masked]

---

From: Dan Connolly <[email-masked]>
Date: Thu, 25 Jun 2009 22:52:12 -0400

Eran Hammer-Lahav wrote:
> 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).
> 

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.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 25 Jun 2009 20:18:12 -0700

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

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 25 Jun 2009 20:19:55 -0700

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

> Sent: Thursday, June 25, 2009 8:04 PM
> To: Eran Hammer-Lahav
> Cc: John Cowan; [email-masked]; [email-masked]; URI
> > 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      [email-masked]
> "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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 26 Jun 2009 15:46:02 +0900

> 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:[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Jun 2009 10:00:51 -0400

On Thu, Jun 25, 2009 at 08:18:12PM -0700, 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. 

Whatever that concept is, it is not what "host" means in the networks
we actually have today.  There is a long history to the notion of a
host and its name, and it is nowise limited to whatever happens to be
listening at a particular DNS name on a port.  

I don't really understand what the problem is you're trying to solve
is.  It sounds to me like you want a description of an SRV or NAPTR
record, in which case you ought trivially to be able to use the
approach mentioned up-thread with an SRV or NAPTR DNS record, no?

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 26 Jun 2009 08:32:08 -0700

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

> From: "Martin J. Dürst" [mailto:[email-masked]]
> Sent: Thursday, June 25, 2009 11:46 PM
> To: Eran Hammer-Lahav
> Cc: Dan Connolly; [email-masked]; [email-masked]; URI
> 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.
> >
> > 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.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 26 Jun 2009 09:00:00 -0700

I define host the same way 2616 does, which is a combination of a domain and port. Since it is defined in the context of the HTTP protocol, it includes an implied protocol as well.

The problem I am trying to solve is very simple. I have a mechanism to describe resources using their URI as identifier. I use this mechanism to describe web pages, services, and other resources. I also want to use it to describe an entire host - I need to describe rules that apply to the entire set of resources which are part of a given host, as defined by RFC 2616.

But without having a URI (*any* URI) that means 'the host at example.com port 80 using HTTP', I can't use this mechanism because it only knows how to operate on URIs.

I can pick anything I want to stick in there as long as it is a valid URI.

So the question is, how to express 'the host at example.com port 80 using HTTP' in a URI? It looks like we need to create something new (from a new URI scheme to a new namespace in an existing URI scheme). I'm asking for ideas.

EHL

> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, June 26, 2009 7:01 AM
> To: [email-masked]
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 26 Jun 2009 09:03:11 -0700

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

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Pat Hayes
> Sent: Friday, June 26, 2009 8:47 AM
> To: Eran Hammer-Lahav
> On Jun 25, 2009, at 10:18 PM, Eran Hammer-Lahav wrote:
> 
> > 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
> 
> >
> 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.
> >
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> 
> 
> 
> 
>

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Jun 2009 12:05:44 -0400

> My definition of host comes from RFC 2616.

RFC 2616 contains a definition of a Host request-header field.  It
acually includes the words "Internet host" as part of the definition,
from my cursory glance just now, so I suspect you don't quite have the
right definition of "the concept of a host" here.  I urge you to look
at RFCs 822, 907, 1122, 1123, 1221, 1349, 2181, to start.  1034 and
1035 wouldn't be a bad idea, either.  There's quite enough confusion
in the discussion of hosts and domain names around the IETF already
without someone hauling in port numbers to the topic.
 
> What I am looking for is a way to express a web concept for the
> purpose of describing its attributes as a URI. 

Again, I have no idea what these "web concepts" of which you speak
are.  I'm not even sure that concepts have attributes, but let's solve
one terminological problem at a time.

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

So what do you think the correct ideas of host and domain are, to
start with?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 26 Jun 2009 09:14:55 -0700

> Sent: Friday, June 26, 2009 9:06 AM

> So what do you think the correct ideas of host and domain are, to

Fair enough.

I am using only RFC 3986 terminology here from section 3 [1].

I want to express the combination of: host, port, and scheme.
I need to express it formatted as a valid URI.
I don't want to express it using an http URI because that requires creating URI exceptions.

Thank!

EHL

[1] http://tools.ietf.org/html/rfc3986#section-3

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Jun 2009 12:16:47 -0400

On Fri, Jun 26, 2009 at 09:00:00AM -0700, Eran Hammer-Lahav wrote:

> I define host the same way 2616 does, which is a combination of a
> domain and port. Since it is defined in the context of the HTTP
> protocol, it includes an implied protocol as well.
> 
> The problem I am trying to solve is very simple. I have a mechanism
> to describe resources using their URI as identifier. I use this
> mechanism to describe web pages, services, and other resources. I
> also want to use it to describe an entire host - I need to describe
> rules that apply to the entire set of resources which are part of a
> given host, as defined by RFC 2616.

I'm sorry, but you're right off the rails here. 

Suppose that I accept that 2616 includes a (re)definition of "host"
that combines a domain (or, I suppose what you mean is a FQDN) and a
port.  Then the rules that apply to that entire set of resources
available at that FQDN:port combination is just what the protocol
allows.  Alternatively, if you're saying that there are operator
policies that you want to express about that FQDN:port combination, it
seems to me that you could use the SRV suggestion I already made
upthread.

A  

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Jun 2009 12:34:27 -0400

> I am using only RFC 3986 terminology here from section 3 [1].

That section does not use host the way you have so far discussed.  In
particular, as you note, "host" is used separately from port, so the
concept of host _does not_ include the port number, whatever else it
includes.

"Host" is later boiled down to IP literal in square brackets, a dotted
quad, or "registered name".  This is an excellent example of the
long-standing confusion among even experienced IETF experts between a
fully-qualified domain name and a host name.  Host names are not all
FQDNs, and the confusion that has been caused by this historical
overloading is exactly the kind of thing that causes discussions like
the one you and I are having.  I urge you to go and read the RFCs I
already mentioned.  I'm not saying that's sufficient for teasing out
the differences we're talking about (I get confused about these things
all the time), but it sure is necessary.

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 26 Jun 2009 09:37:34 -0700

You already convinced me. This is why I switched to define my problem in clear terms from a single RFC (3986). So now that I redefined my problem, got ideas?

EHL

> From: Andrew Sullivan [mailto:[email-masked]]
> Sent: Friday, June 26, 2009 9:34 AM
> To: Eran Hammer-Lahav
> Cc: [email-masked]

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 26 Jun 2009 09:54:22 -0700

# They aren't being treated differently. The normal syntax for naming  
# something in RDF is a URI reference with a fragid attached. The use of  
# a fragID cancels any assumptions that the URIreference denotes  
something connected with the HTTP protocol. 

How does it do that? 

# This is how RDF manages to  
# refer to galaxies, chemical elements, people, etc.. 

Sounds like this is only in the context of RDF.

Larry
--
http://larry.masinter.net

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 28 Jun 2009 17:04:04 +0900

On 2009/06/27 3:36, Xiaoshu Wang wrote:

> Thus,
>
> "http://danbri.org/foaf.rdf#danbri" denotes a person.
> "http://danbri.org/foaf.rdf#(application/rdf+xml)danbri" denotes an RDF
> node.
> "http://danbri.org/foaf.rdf#(application/xhtml+xml)danbri" denotes an
> HTML element ided "danbri

I don't understand this. Why wouldn't I just use
    http://danbri.org/foo.html#danbri
or anything similar for HTML fragments? (I'm assuming that foaf.rdf 
returns an application/rdf+xml documend, and foo.html returns an 
application/xhtml+xml document; the extensions may be meaningless to the 
protocol but help to keep things apart for humans and computers.)

Also, I don't see much of a need to denote an RDF node per se. I'm sure 
there are special applications one can come up with where reasoning 
about RDF nodes per se is helpful/necessary/whatever, but for such 
cases, there are other techniques available already. A single special 
property and blank nodes would do the job.

Regards,   Martin.

> When a URI owner uses content negotiation, they should make the content
> of each representation consistent. Of course, there could be
> inconsistencies if a user is not careful. But it is no different from
> the case when someonelse makes an inconsistent statement about
> "http://danbri.org/foaf.rdf#danbri". Inconsistent resources (whether it
> is caused by the same root-URI owner or not) will simply not be used
> (i.e., linked) by others, hence eventually die of isolation.
> This is the same old story from the httpRange-14. Once we straighten
> that out, all other problems are very easy to answer.
>
> Xiaoshu
>
>
>
>

---

From: "Larry Masinter" <[email-masked]>
Date: Sun, 28 Jun 2009 10:53:31 -0700

I'm thinking about revising
 http://larry.masinter.net/duri.html

to:
(1) to get rid of "duri" and just stick with "tdb"
  (because there isn't much use for duri at all)
(2) make it a URI scheme rather than a URN namespace
(3) make the date optional, for cases where the time of
  binding resource to representation (and of interpretation
  of that representation to an 'abstract concept')

So the simplest form would be

tdb:http://larry.masinter.net

which would neatly allow using descriptions of
abstract concepts to identify the abstract concept.
(Syntactically, the date can be left out without
ambiguity.)

Would this be helpful, at least for illustrative purposes?

I think there are other means for distinguishing
between the representation of a  description and 
the thing described, but this would at least
add a well-known method that isn't tied to
any particular protocol, linking method, resolution
method, etc.

tdb:data:,the%20host%20larry.masinter.net

might be a simple inline way of talking about the
'host' named 'larry.masinter.net'.

Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Rees
Sent: Sunday, June 28, 2009 9:43 AM
To: [email-masked]
Cc: Eran Hammer-Lahav; [email-masked]; [email-masked]; URI
Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.)

On Sat, Jun 27, 2009 at 9:07 PM, ashok
malhotra<[email-masked]> wrote:
> 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.

Quibble: In the case of a chair, you can't get metadata, since a chair
isn't data.
http://www.google.com/search?q=define:metadata

This is why it's nice that Eran calls the description resource a
"description resource" instead of a "metadata resource". LRDD is a
compatible alternative to linked-data 303 nose-following, one that
(like 303, as David Booth has pointed out) behaves uniformly without
caring whether the resource is "data"-like or not - it means you don't
have to ask or answer that question. I advocate using his terminology.

Perhaps an alternative to a new URI scheme for hosts would be loop
detection inside of LRDD? I think that's close to what you're saying.

-Jonathan

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 28 Jun 2009 11:09:53 -0700

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.

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

EHL

> From: ashok malhotra [mailto:[email-masked]]
> Sent: Saturday, June 27, 2009 6:08 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; [email-masked]; URI
> 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.
> >
> > 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).
> >
> > 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'.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 28 Jun 2009 22:24:26 -0700

> Sent: Sunday, June 28, 2009 7:34 PM

> (1) You develop your XSD document format, in whatever form you think is
> the most suitable.  And you deploy that definition in the Web, say
> http://xsd.type.com, which in essence makes it a media-type.
> (2) Then, you client content-negotiate the XSD content with that URI
> with the desired resource.
> 
> It is as easy as it gets.  All communication problem can (and I think
> should be solved in this way).  I said can because, as Butler Lampson
> has famously said: "All problems in computer science can be solved by
> another level of indirection".  Content negotiation is just a level of
> "indirection".  The problem is abstracted into a URI and then
> negotiated
> over that URI.

I disagree [1], and have no interest in having this discussion with you *again* [2].

EHL

[1] http://www.hueniverse.com/hueniverse/2009/03/discovery-and-content-negotiation.html
[2] http://lists.w3.org/Archives/Public/www-tag/2009Mar/0034.html

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 29 Jun 2009 16:35:34 +0900

On 2009/06/29 0:02, Xiaoshu Wang wrote:
> Martin J. Dürst wrote:
>> application/xhtml+xml document; the extensions may be meaningless to
>> the protocol but help to keep things apart for humans and computers.)

> Well, then it just doesn't work for extending the referential range of
> URI to denote things beyond engineering entities. If you take a URI
> (fragment or not) to denote document (or its sub-structure), then the
> Web is not much useful to our daily use. If you take a URI to denote
> other things, like a human or person, then you cannot describe a
> document structure. And there is one URI, then you have to make a
> decision which one it denotes, right?

Yes, each URI better denotes only one thing. But that doesn't mean that 
all URIs (with fragment identifiers) denote subdocuments, and it doesn't 
mean that all URIs (with fragment identifiers) denote 'other things'. It 
means that each individual URI denotes either one or the other, and that 
you find out which one (if you need to) by getting more information 
about it.

>> Also, I don't see much of a need to denote an RDF node per se. I'm
>> sure there are special applications one can come up with where
>> reasoning about RDF nodes per se is helpful/necessary/whatever, but
>> for such cases, there are other techniques available already. A single
>> special property and blank nodes would do the job.
> Sure, we can use special property and blank nodes, but don't we need to
> know a URI does first before applying a property to that right?

People who 'apply properties' to URIs (which I assume you mean to add 
properties about an URI) will know an URI from other information or 
because they created the URI and decided what they want to use it for. 
People who see an URI for the first time have to find out what it stands 
for either from context or from dereferencing (or probably from both).

Regards,   Martin.

---

From: John Cowan <[email-masked]>
Date: Thu, 25 Jun 2009 21:03:26 -0400

Eran Hammer-Lahav scripsit:

> Without passing judgment on your proposal, it is clearly not something

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                 [email-masked]

---

From: John Cowan <[email-masked]>
Date: Thu, 25 Jun 2009 23:03:37 -0400

---

From: Phil Archer <[email-masked]>
Date: Fri, 26 Jun 2009 10:45:57 +0100

Hi Eran,

Comments inline below.

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

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…

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

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

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.

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

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.

> abstract://example.com:8080:http/origin

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

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.

-- 

Phil Archer
http://philarcher.org/

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

---

From: Pat Hayes <[email-masked]>
Date: Fri, 26 Jun 2009 10:46:47 -0500

Pat Hayes

> And simply include in the protocol that the http://abstract.example.net/host/

---

From: Pat Hayes <[email-masked]>
Date: Fri, 26 Jun 2009 11:16:42 -0500

On Jun 26, 2009, at 11:03 AM, Eran Hammer-Lahav wrote:

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

They aren't being treated differently. The normal syntax for naming  
something in RDF is a URI reference with a fragid attached. The use of  
a fragID cancels any assumptions that the URIreference denotes  
something connected with the HTTP protocol. This is how RDF manages to  
refer to galaxies, chemical elements, people, etc.. Of course the bare  
root URI connects to (and likely refers to) an http-located  
information resource, but that need not interfere with the referents  
of the URI references constructed from it.

Pat

---

From: Dan Brickley <[email-masked]>
Date: Fri, 26 Jun 2009 19:27:26 +0200

> Sounds like this is only in the context of RDF.

Yes and no.

Here's the "Yes": the idea is that if content is served as 
application/rdf+xml then the meaning of #foo is delegated to the 
relevant spec (http://www.w3.org/2001/sw/RDFCore/mediatype-registration 
? humm that's expired). The RDF mediatype doc says

"""Section 4.1 of the URI specification [6] notes that the semantics
    of a fragment identifier (part of a URI after a "#") is a property of
    the data resulting from a retrieval action, and that the format and
    interpretation of fragment identifiers is dependent on the media type
    of the retrieval result.

    However, in RDF, the thing identified by a URI with fragment
    identifier does not bear any particular relationship to the thing
    identified by the URI alone.  This differs from some readings of the
    URI specification [6], so attention is recommended when creating new
    RDF terms which use fragment identifiers."""

Here the "No": A URI that points to an RDF document constructed in this 
fashion, is (according to those persuaded this story works) supposed to 
be a URI for whatever galaxy, chemical element, person etc. the RDF is 
structured to represent.

In this way, http://danbri.org/foaf.rdf#danbri is a URI for me. Not just 
for RDF applications, but for any applications that care about the idea 
of URIs being URIs *for* things. The media-type registration that makes 
this so RDF-specific (RDF/XML-specific even) but the URI is supposed to 
be a URI for me, full stop, rather than "a URI for me, in RDF applications".

At this point people normally bring up the possibility of clashes across 
content-negotiated representations served at the same URI. The usual 
answer offered by return is "if that hurts, don't do it".

Dan

---

From: Pat Hayes <[email-masked]>
Date: Fri, 26 Jun 2009 16:02:44 -0500

> something connected with the HTTP protocol.

http-range-14, as I understand it.

> Sounds like this is only in the context of RDF.

Well, true, fragids have a different meaning in HTML. But this rule  
seems to work smoothly throughout the SWeb formalisms, which are all  
the referential uses of URIrefs on the Web.

Pat

---

From: Erik Wilde <[email-masked]>
Date: Sat, 27 Jun 2009 16:25:55 +0200

hello.

Xiaoshu Wang wrote:
> There should not be.  I have trying this many times.  A URI, fragmented 
> or not, denotes one thing and its returned representations another.  The 
> former is the content of the later.  The remedy is to define a URI 
> syntax for representation.
> A syntax that I have proposed is to insert a (mime-type) after the # sign.
> Thus,

interesting. would that be specific for http-identified resources? if 
not, how would that be supposed to work with URI schemes that do not 
share HTTP's capabilities for transferring content metadata, and 
performing content negotiation? a simple example might be FTP, which is 
similar in nature to HTTP (access to hierarchically organized resources) 
but has no concept of media types.

another thing i am wondering about: aren't fragment identifiers as they 
are currently defined client-side only and specific to the media type 
anyway? that might indicate you are talking not about extending the URI 
syntax, but that of HTTP URI fragment identifiers? there were other 
approaches of doing this (with other goals), one of the issues was how 
to create some framework for fragment identifiers that would be 
uniformly applied to all fragment identifier syntaxes. that one never 
got anywhere, and the window of opportunity is probably closed by now. 
but there the idea was that instead of labeling fragments with the media 
type to which they should be applied (which seems to be what you're 
suggesting), they should follow some base syntax, and thus could be 
designed to be less brittle across media types. HTTP's idea of content 
negotiation (and thus dynamic media type assignment at access time) and 
URI fragment identifiers and their media type specificity always was one 
of the areas where web architecture certainly could need a bit of 
improvment.

cheers,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        [email-masked]  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

---

From: Erik Wilde <[email-masked]>
Date: Sat, 27 Jun 2009 23:09:59 +0200

hello.

> I don't think a URI scheme has to do anything with transportation 
> protocol.

the URI scheme specifies the protocol that has to be used the resource. 
how can that have nothing to do with the protocol?

> No matter what URI you use, after de-reference, you get a 
> *representation*, which is a different thing from the *resource* that 
> the URI denotes.  And a representation must have a content type, 
> regardless how you retrieved it.

that's HTTP and HTTPS, but probably not many other protocols. if you use 
mailto: or tel: or fax: or sms:, then there are other modes of 
interaction with the identified resource, and for those interactions 
there is no concept of a media type. and even for ftp:, there is no 
media type info; you can guess, but there is no protocol mechanism that 
supports it. so it really seems to me you're focusing on HTTP URIs which 
is fine; i just wanted to find out.

cheers,

---

From: ashok malhotra <[email-masked]>
Date: Sat, 27 Jun 2009 18:07:48 -0700

Hi Eran:

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.

All the best, Ashok

---

From: ashok malhotra <[email-masked]>
Date: Sun, 28 Jun 2009 10:30:13 -0700

See inline
All the best, Ashok

> http://www.google.com/search?q=define:metadata
[AM]  Picky, picky :-)
> have to ask or answer that question. I advocate using his terminology.
[AM] Yes, description resource is better,
> detection inside of LRDD? I think that's close to what you're saying.
[AM] I wrote the note mainly to make sure I understood Eran's usecase,
Your suggestion has merit.  Let's see what he says.

---

From: Phil Archer <[email-masked]>
Date: Mon, 29 Jun 2009 09:30:16 +0100

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

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.

-- 

Phil Archer
http://philarcher.org/