[
Lists Home |
Date Index |
Thread Index
]
> 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
|
