Boilerplate

Namespaces

void rdfs dct oo

Example

Here is an example of the kind of boilerplate it is useful to include in all RDF documents.

<syntaxhighlight lang="xml">

 <rdf:Description rdf:about="http://example.org/mydataset.rdf">
   <dcterms:title>Example Organisation Kitten Inventory</dcterms:title>
   <oo:corrections rdf:resource="mailto:semwebmaster@example.org" />
   <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>

</syntaxhighlight>

Document URI

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.

<syntaxhighlight lang="xml">

 <rdf:Description rdf:about="">
 </rdf:Description>

</syntaxhighlight>

<syntaxhighlight lang="xml">

 <rdf:Description rdf:about="...URL-of-RDF-Document...">
   ...
 </rdf:Description>

</syntaxhighlight>

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: <syntaxhighlight lang="xml">

   <dct:license rdf:resource="...LICENCE-URI..." />

</syntaxhighlight> 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.

• http://www.opendatacommons.org/licenses/pddl/1.0/
• http://www.opendatacommons.org/licenses/odbl/1.0/
• http://www.opendatacommons.org/licenses/by/1.0/
• http://creativecommons.org/publicdomain/zero/1.0/
• http://reference.data.gov.uk/id/open-government-licence

SPARQL Endpoint

If the RDF triples in a document are also available from a SPARQL endpoint then you can add the following relation to the boilerplate. <syntaxhighlight lang="xml">

   <void:sparqlEndpoint rdf:resource="...URL-of-SPARQL-Endpoint..." />

</syntaxhighlight>

Corrections

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.

<syntaxhighlight lang="xml">

   <rdfs:comment>Corrections to this data should be sent to semwebmaster@example.org. 
Corrections may take up to a month to be reflected in the live data.</rdfs:comment>

</syntaxhighlight>

Data lifespan

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.

<syntaxhighlight lang="xml">

  <dcterms:modified>2010-01-12</dcterms:modified>
  <oo:bestBefore>2010-07-12</oo:bestBefore>

</syntaxhighlight>

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.