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

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

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

------------------------------------------------------------
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:17:25 UTC