- From: Eran Hammer-Lahav <eran@hueniverse.com>
- Date: Fri, 26 Jun 2009 09:03:11 -0700
- To: Pat Hayes <phayes@ihmc.us>
- CC: Dan Connolly <connolly@w3.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "www-tag@w3.org" <www-tag@w3.org>, URI <uri@w3.org>
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@w3.org [mailto:www-tag-request@w3.org] On Behalf > Of Pat Hayes > Sent: Friday, June 26, 2009 8:47 AM > To: Eran Hammer-Lahav > Cc: Dan Connolly; apps-discuss@ietf.org; www-tag@w3.org; 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@w3.org] > >> 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 (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 > > > > >
Received on Friday, 26 June 2009 16:03:57 UTC