Cart
[Home] [By Thread] [By Date] [Recent Entries]
> How about for things that you don't have any representations for right > now but plan to in the near future? How about things that you don't That's covered by "intend to be dereferenced". > have any way of representing right now, but you might someday? What are It depends on how you define "representation" and "might" :-) Everything *could* have a representation someday, so that's really not justification for using http: identifiers. IMO, if you feel that representation retrieval (via synchronous HTTP GET) is likely to be an important function of the resource, then it makes sense to use http: identifier. > some things that fall into the category "which you don't intend to be > dereferenced"? -Tim Most people wouldn't want to interact with beaches via http. -- (It's more likely that there would be several http: identifiable sites which talk *about* a particular beach, and it would be better for everyone involved if they did NOT use their http: URI as the identifier for the beach. Consider the following example: A) Site: http://www.tybeebeach.com says "urn:beaches:ga-tybee qualityIs great" B) Site: http://www.tybeega.org says "urn:beaches:ga-tybee qualityIs poor" C) Site: http://www.mypersonalsite.com says "http://www.tybeega.org qualityIs poor" This use of identifiers has two important characteristics: 1) The use of a neutral identifier allows the sites to share the same identifier and permits people to aggregate metadata from many places. For example, a crawler like google could crawl both sites in A and B, and allow people to search for reports on "qualityIs" of the particular beach, without regards to who owns the individual http: sites. 2) Keeping the "web site" different from the "beach" permits people to make assertions about the "web site" as in C. -J
|
