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


>