HCLSIG BioRDF Subgroup/Tasks/URI Best Practices/Recommendations/RacineSharing

From W3C Wiki
Jump to: navigation, search

[[/../../Recommendations|URI Note main page]]

Racine Sharing

This refers to the issue of minting multiple # URIs having the same "racine", e.g.

http://example.com/animals#pig
http://example.com/animals#cow
http://example.com/animals#caecilian

(The racine is the URI obtained by truncating the # URI starting with the #. In the above, the racine is http://example.com/animals.)

Do we tolerate (MAY), discourage, or strongly discourage this practice?

Status quo

Racine sharing is widely practiced. It seems to be the favored by W3C team. Occasionally thousands of URIs share a common racine.

In favor

Convenience (fewer documents to publish) and performance (fewer documents to retrieve) are sometimes cited as reasons. See [[/../DraftTalk]] toward the bottom.

Opposed

The server is robbed of differential control of the definition document. [sounds as if this might matter, but how would it?]

The document retrieved from the racine URI SHOULD define all of the URIs. If you have large numbers of them, that document is going to be huge.

Putting more than one definitions in one file makes it impossible (using currently available notations) to say where the definition of one term ends and the next begins.

One of probably dozens of essays on the #: "Fragged" essay by Bill de hÓra. This is nominally opposed to # URIs entirely, but I couldn't find much in it that would argue against having a unique # URI per racine. (Thanks the tip, Bijan!)

(anything else?)