HCLSIG BioRDF Subgroup/Tasks/URI Best Practices/Recommendations/RacineSharing
[[/../../Recommendations|URI Note main page]]
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?
Racine sharing is widely practiced. It seems to be the favored by W3C team. Occasionally thousands of URIs share a common racine.
Convenience (fewer documents to publish) and performance (fewer documents to retrieve) are sometimes cited as reasons. See [[/../DraftTalk]] toward the bottom.
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!)