My overall comment: Yes! I believe a URI resolution ontology could
significantly help address these problems, while still permitting URIs
to be based on the http scheme, thus facilitating bootstrapping and
minimizing barriers to adoption.
I am very doubtful about the practicality of such an ontology. First,
consider the size. RDF is all about URI. If an RDF document has n
statement, there will be 3n URIs. If k statements are needed to
describe the resolution of one URI, the solution unnecessarily increased
the KB k-fold. Image the load for an RDF engine, the impact will be
even bigger. In theory, this seems O.K. but in practice, I have serious
doubt.
Unless, perhaps, you can describe the composition of URI - as a string.
But, RDF is used to describe resource, which is identified a string.
The meaning of these string should be specified "outside" of the
system. Just like URI specification is not a sub-specification of RDF.
Even if you can succeed in doing so, though I am not clear how it can,
the system ended up may be too complicated to be used.
Sometime, we need to strike a balance between a "complete" and a
"reasonable" solution. Especially, in software engineer field, we see
the constant battle. EJB vs. POJO and "specification" vs.
"convention". Most of the time, most of the practical and reasonable
solution wins out.
In terms of URI's stability, I think what is important will always be
taken care of. And so what is broken is not important and just let it
be. As for our brain, forgetting isn't necessarily a bad thing. Broken
URIs will not necessarily a bad thing for the health of web either. For
me, it is more appropriate to discuss the problem in a social, but not
technical, context.
Xiaoshu
