Jeni's Musings

i guess this is the curse of the specific architectural approach of the semantic web, which assumes that all URIs are HTTP URIs, and you get descriptions about the identified entities by accessing the resource URI itself. on http://dret.typepad.com/dretblog/2009/07/the-last-uri-scheme-youll-ever-need.html i have argued that such an approach might actually be harmful, and i think your case is another example of where this approach shows some unfortunate side-effects. in plain web architecture, URIs are completely opaque, so if you’re afraid that domains might go away (or you just want to be able to handle that case), you use non-HTTP URIs, let’s assume in a very simple case something like tag:jenischool98764321986432874. this of course is not a URI scheme by itself, but you get the idea… by doing this, you decouple resource identity (the URI you’re using to use an entity of interest) from resource access (how do i get any information about this school?). this of course means that your apps must be aware of those URIs and must know how to resolve them, should you want to access the resource itself or get a description of it. but that’s the price you have to pay to be able to deal with unpredictable changes on the DNS level.

to me, this looks like a great example of the semantic web trade-off: by baking HTTP into the foundation, some things can be magically simplified (the httpRange-14 trick), but if that trick does not work anymore because DNS names change, for example, you are starting to pay the price for it.