The solutions described in the following apply to deployment scenarios in which the RDF data and the HTML data is served separately, such as a standalone RDF/XML document along with an HTML document. The metadata can also be embedded in HTML, using technologies such as RDFa [RDFa Primer], microformats and other documents to which the GRDDL [GRDDL] mechanisms can be applied.

[...]

The first solution is to use “hash URIs” for non-document resources. URIs can contain a fragment, a special part that is separated from the rest of the URI by a hash symbol (“#”).

When a client wants to retrieve a hash URI, then the HTTP protocol requires the fragment part to be stripped off before requesting the URI from the server. This means a URI that includes a hash cannot be retrieved directly, and therefore does not necessarily identify a Web document. But we can use them to identify other, non-document resources, without creating ambiguity.

[...]

The second solution is to use a special HTTP status code, 303 See Other, to give an indication that the requested resource is not a regular Web document. Web architecture tells you that for a thing resource (URI) it is inappropriate to return a 200 because there is, in fact, no suitable representation for those resources. However,

Since 303 is a redirect status code, the server can give the location of a document that represents the resource. If, on the other hand, a request is answered with one of the usual status codes in the 2XX range, like 200 OK, then the client knows that the URI identifies a Web document.

Content-negotiation is then used when retrieving a representation from the document URI using a HTTP request. The server decides (see Section 4.7) to return either HTML or RDF (or more alternative forms) and sets the Content-Location header to the URI where the specific representation can be retrieved. This setup should be used when the RDF and HTML (and possibly more alternative representations) convey the same information in different forms.

[...]

When the RDF and HTML representations of the resource differ substantially, the previous setup should not be used. They are not two versions of the same document, but different documents altogether. Again, the Web server would be configured to answer requests with a 303 status code and a Location HTTP header that provides the URL of a document that represents the resource.

[..]

Which approach is better? It depends. The hash URIs have the advantage of reducing the number of necessary HTTP round-trips, which in turn reduces access latency. A family of URIs can share the same non-hash part. The descriptions of http://www.example.com/about#exampleinc, http://www.example.com/about#alice, and http://www.example.com/about#bob are retrieved with a single request to http://www.example.com/about. However this approach has a downside. A client interested only in #product123 will inadvertently load the data for all other resources as well, because they are in the same file. 303 URIs, on the other hand, are very flexible because the redirection target can be configured separately for each resource. There could be one describing document for each resource, or one large document for all of them, or any combination in between. It is also possible to change the policy later on.

[..]

Conclusion.

Hash URIs should be preferred for rather small and stable sets of resources that evolve together. The ideal case are RDF Schema vocabularies and OWL ontologies, where the terms are often used together, and the number of terms is unlikely to grow out of control in the future.

Hash URIs without content negotiation can be implemented by simply uploading static RDF files to a Web server, without any special server configuration. This makes them popular for quick-and-dirty RDF publication.

URIs of the bob#this form can be used for large sets of data that are, or may grow, beyond the point where it is practical to serve all related resources in a single document. 303 URIs may also be used for such data sets, making neater-looking URIs, but with an impact on run-time performance and server load.