Here is an example of the kind of boilerplate it is useful to include in all RDF documents.
<rdf:Description rdf:about="http://example.org/mydataset.rdf"> <dcterms:title>Example Organisation Kitten Inventory</dcterms:title> <oo:corrections rdf:resource="mailto:email@example.com" /> <dct:license rdf:resource="http://creativecommons.org/publicdomain/zero/1.0/" /> <dcterms:modified>2010-01-12</dcterms:modified> <oo:bestBefore>2010-07-12</oo:bestBefore> </rdf:Description>
In N3 and RDF+XML you /can/ refer to the current document as a zero-length-string-URI. eg. "" or <>. This is not recommended. If possible refer to the document it's authoritative URL. That way if it gets saved to disk and reloaded it doesn't then end up with it's URI/URL being its new filename.
<rdf:Description rdf:about=""> </rdf:Description>
<rdf:Description rdf:about="...URL-of-RDF-Document..."> ... </rdf:Description>
License & Rightsholder
At the very least you need to include a license. Without a license, your RDF is not Open Data.
Express the license using DCTerms:
<dct:license rdf:resource="...LICENCE-URI..." />
You may also add "dct:publisher" and "dct:rightsHolder" to link to the URIs of the publishing and rights-holding organisations (will often be the same, but not always). It is recommended that you also use an rdfs:label to give these organisation URIs a human readable label.
Not all licenses are suitable for use with data. The following are (nb. I am not a lawyer...)
More information on open licenses is available at http://www.opendefinition.org/licenses/
The following are the recommended URIs to use for RDF data.
If the RDF triples in a document are also available from a SPARQL endpoint then you can add the following relation to the boilerplate.
<void:sparqlEndpoint rdf:resource="...URL-of-SPARQL-Endpoint..." />
It is recommended that you include an rdfs:comment describing the corrections policy and process. Without this people will have no way to help you correct errors.
<rdfs:comment>Corrections to this data should be sent to firstname.lastname@example.org. Corrections may take up to a month to be reflected in the live data.</rdfs:comment>
Some data will go out of date at a known date/time (eg. 2012 bus time table), however others are open ended and the authors intend to update them regularly. However, in practice, sometimes this won't happen.
If possible, you should provide a dataset with a last modified date, plus 'best before' or 'do not use after' date. Sometimes you may wish to preseve old copies of datasets (such as your company phonebook) but certainly don't want tools mistaking it for currently useful information.
A bestBefore date in the past indicates that the creator of this data recommends that people be warned that it is out of date when making decisions using it, like a year-old phone book.
A doNotUseAfter date indicates that the creator of the data recommends that it is not used except as a historical record.