| 50 | | 1. It must be clearly stated what the intended referent of |
| 51 | | each URI is supposed to be, i.e. that the URI denotes some particular |
| 52 | | record from some particular database. |
| 53 | | 2. Information about the URI and its referent, including such a |
| 54 | | statement, must be made available, and in order to leverage existing |
| 55 | | protocol stacks, it must be obtainable via HTTP. (We'll call such |
| 56 | | information "URI documentation".) |
| 57 | | 3. URI documentation must be provided in RDF. |
| 58 | | 4. Provision of URI documentation must be an ongoing concern. The |
| 59 | | ability to provide it may have to outlive the original database or the |
| 60 | | database's creator. |
| 61 | | 5. The provider of the URI documentation must be responsive to |
| 62 | | community needs, such as the need to have mistakes fixed in a timely |
| 63 | | manner. |
| 64 | | 6. URI documentation must be open so that it can be replicated and reused. |
| | 50 | * It must be clearly stated what the intended referent of each URI is supposed to be, i.e. that the URI denotes some particular record from some particular database. |
| | 51 | * Information about the URI and its referent, including such a statement, must be made available, and in order to leverage existing protocol stacks, it must be obtainable via HTTP. (We'll call such information "URI documentation".) |
| | 52 | * URI documentation must be provided in RDF. |
| | 53 | * Provision of URI documentation must be an ongoing concern. The ability to provide it may have to outlive the original database or the database's creator. |
| | 54 | * The provider of the URI documentation must be responsive to community needs, such as the need to have mistakes fixed in a timely manner. |
| | 55 | * URI documentation must be open so that it can be replicated and reused. |
