Houghton,Andrew wrote:
I think the answer lies in DNS. Even though you have a single DNS name
requests could be redirected to one of multiple servers, called a server
farm. I believe this is how many large sites, like Google, operate. So
even if a single server fails the load balancer sends requests to other
servers. Even OCLC does this.
Certainly one _could_ do lots of things -- although I'm more worried
about an _organization_ as a point of failure, than a particular piece
of hardware. I'm not worried about that with OCLC, but I am worried
about that with some random programmer minting URIs at some random
institution that doesn't neccesarily understand persistence as part of
it's institutional mission. With Mike's vision of lots of people
everywhere minting URIs pointing at their own domains... how likely is
it that hardly any of them are going to do this? Any time soon?
I think too much of this conversation is about people's ideal vision of
how things _could_ work, rather than trying to make things work as best
as we can in the _actual world we live in_, _as well as_ planning for
the future when hopefully things will work even better. You need a
balance between the two.
I also start seeing people in this thread saying "But if you do it that
way it doesn't work for the Semantic Web (tm)." Except they are more
likely to say 'linked data' than 'semantic web', because the latter
phrase seems to have been somewhat discredited.
The linked data vision is cool, and makes many interesting things
possible. As parts of it are built, piece by piece, more interesting
things become possible. dbpedia is awesome. I want to support such uses
by making my work compatible with the linked data vision where possible.
But linked data is NOT the only reason or use case for URI identifiers.
I am also trying to solve particular _right now_ use cases that do not
neccesarily depend on the linked data vision. When I do this, I am
trying to create identifiers (and other schemes) that:
a) Are as likely to keep working indefinitely, in the real world of
organizations with varying levels of understanding, resources, and
missions.
b) Are as likely as possible to be adopted by as many people as possible
for inter-operability. Having an ever-increasing number of possible
different URIs to represent the same thing is something to be avoided if
possible.
c) Are as useful as possible for the linked data vision.
These things need to be balanced. I believe that sometimes an info: URI
is going to be the best balance. Other times an http URI pointing to
purl.org might be. Other times an http URI pointing at some particular
entity might be. (In the latter case, especially when it's an entity
that understands what it's getting into, commits to it, documents it,
and has enough 'power' in the community to encourage other people to use
it). Sometimes we'll be wrong, and we'll discover that.
I am equally frustrated with what I see as the dogmatism of both of
these absolute points of view: That in a particular case, or even in
_all_ cases, 1) it's obvious that an http uri is the only right
solution, or 2) it's obvious that an http uri is an unacceptable solution.
In the cases we're talking about, neither of those things are obvious to
me. We're inventing this stuff as we go. And we need to invent it for
the real world where people don't always do what we think they ought to,
not just for our ideal fantasy linked data world.
Jonathan
