Best Practices

This page is intended as a collection of best practices and lessons learned with regard to vocabulary development.

Discussion of the proposed practices should happen on the Talk Page (click on the discussion tab above the article).

Modelling

You can spend years on knowledge modelling, tie yourself in knots and get very philosophical. This is isn’t that – it’s a quick guide to rapid prototyping of an RDF Schema, that can be used, and reused. All these steps are iterative.

1. Define your scope, purpose and competency questions. Add them as an annotation on the ontology – so when someone wants to reuse it, they know why you made those design decisions and helps them evaluate whether they want to use it.

Scope is about what goes in, what shouldn’t go in, and the level of detail you want to go into. For a whisky ontology for example, do you really care about the exact location the sherry barrels come from? Are you going to concentrate only on Scotch whisky, or think about Irish whiskeys too?

Purpose: what are you going to use it for? Makes a massive difference about how accurate you need to be.

Competency questions: this is effectively the test set. What queries should your ontology + data be able to answer? At VOCamp we also had some scenario stories which did the same thing. For example, for a Journey ontology, can the ontology represent my journey from Southampton to Karlsruhe by train and tube?

2. Get the knowledge Are you an expert in the domain? Do you really know enough about whisky? If not, where are you going to get your info from? What data are you going to instantiate the ontology with? Can you reuse other people’s ontologies? http://watson.kmi.open.ac.uk/WatsonWUI/ and others can help you locate relevant classes.

3. List the classes (or draw a diagram); choose the properties and decide which take literals as objects and which take URIs – the latter get represented on the diagram as links to other classes. Put arrows on the links, unless you’re definitely sure you need the inverse property as well – mostly, you won’t. Don’t say anything you don’t need (the principle of “minimal ontological commitment”). Classes should be named using terms that are actually used in the domain. For community authoring, particularly when it’s a complicated ontology or a big group of people, it’s better to have done the initial work beforehand, and ask people to comment on one you made earlier.

4. Test it Can the ontology answer your competency questions? Does it meet the scope and purpose? Does it fit your data?

Most of the references out there are for more complex ontology modelling than is needed for RDFS. But to get an idea: http://ksl.stanford.edu/people/dlm/papers/ontology101/ontology101-noy-mcguinness.html

http://www.jfsowa.com/ontology/

http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial.pdf

Publishing

• Best Practice Recipes for Publishing RDF Vocabularies
• Vapour - Validator for Linked Data and Vocabulary Publishers