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

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:56 UTC