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