Concerns

The And Pattern (TAP) is aimed at promoting URI's stability and Resource's interoperability in the Web. To promote a resource's interoperability requires to maintain a URI's stability, which is Cool URIs don't change. But we should not only not abandon a URI that we already have but also not to unnecssarily duplicate a URI. For instance, what does the URI - http://www.w3.org/2000/01/rdf-schema#Resource - mean? It seems clear that if you click that URI, you are lead to an RDF document where the meaning of the resource is specified in RDF. But what if the person who clicked that link is an RDF-illiterate? In this latter case, the meaning of the resource is unknown to him. This is the shadow web problem pointed out by Robert McCool in [1].

This is perhaps TAG's intension to create a shadowed semantic web. But I think, if it is, the approach is very wrong. If the Web shall have a shadow, it should be a shadow over the structure of information but not its meaning.

Solution

Use content negotiation to serve various kind of documents regardless if it is "slash" or "hash" -URI. Because once we understand what is document, a lot of issues becomes much clearer though not necessarily easier. This is the issues that we attempted to address in one of our manuscripts.

In the above rdfs:Resource's case, an HTML document should also be provided with an HTML element of the same "Resource" fragment id that shall be used to describe what the rdfs:Resource means. This is the design pattern used in this web site. All ontologies and some specification, such as the URIDL, uses content negotiation to serve various kind of information (document types).

In fact, content negotiation has been used, for instance, in the AJAX, where a server would check if a browser supports JavaScript. If it does so, an XML snipet or JSON etc. would be sent back for some URI. If not, the entire HTML document would be returned.

Advantages

Promote interoperability of various software agents because the URI is shared across multiple kind of documents. Without using content negotiation, an XML, RDF, HTML's URI of the same resource must be different. Hence, agents that specifically designed to consume a specific type of document will be difficult to be interoperable.
Allows the Web to be incrementally developed because the same resource can serve in both XML, HTML, RDF, REST, and SOAP.
Allows the Web to be agily accessed because a resource does not have to serve a content all in one representation.
In addition, it also solves many other kind of issues, such as the metadata of a URI, etc.

Current Support

Unfortuanely, most browsers do not provide functionalities of allowing users to choose arbitrary content type. However, Firefox has a Modify Headers add-on that allows you to do that.

In addition, neither HTML allows you to set the content type. Although the anchor (ie., <a>) element has a type attribute, but its logic is different. It serves as a fall-back mechanism but as a server-specified mechanism. In addition, JavaScript does not allow you to change the Accept header's either. Although XMLHttpRequest Object can do this, it returns a snipet of XHTML code that must be interpreted with the current HTML document. But what I desired is to set the Accept header and then change the location of the browser.

The above state of affairs regarding the HTTP's Accept header, in fact, reflects our lack of understanding of the Web, which I tries to clarify in my manuscipt and here.

Reference

McCool, R. Rethinking the semantic Web. Part I. Internet Computing, IEEE, 9 (6). 88, 86-87. (2005).