Cookbook Guidelines

Guidelines

(open to negotiation & common sense, of course)

• Examples
  • Examples should be given in RDF+XML.
  • RDF+XML examples should not use nested resources, except for bnodes.
  • Resources should always be <rdf:Description>. Express types using <rdf:type> not the shortcut XML way.
  • Use <strike> tags to indicate examples of bad patterns which are not intended to be copied, but rather to serve as warnings.
• Recipes
  • Some schemas have pairs of inverse predicates. Each recipe should pick one or the other and use only that throughout.
  • Try and use the predicates used by other OpenOrg recipes, where it makes sense to do so.
  • Use "dct:" as the prefix for "DC-Terms". Don't use dc-elements at all.
  • For namespaces, use the prefix from http://prefix.cc/
  • Define a general recipe and then give extensions for use in specific types of organisation (eg. Universities, Publishers, charities)
  • (idea) Include recommended CONSTRUCT statements to use when importing the basic data into SPARQL to add the inverse predicates, etc.
  • If in doubt, leave it out. We want to keep these as simple as possible. Write a simple core suitable for all cases, then recommend extensions. Extensions are better than variations.
  • One way only. Do not suggest variations, just give a clear instruction to follow.
    • Anyone can add additional predicates & classes to their data, the recipes should keep it to one useful approach.
    • Variations cause people more work, not less. Pick a sensible one, allow people to use others in addition.

To gain write-access to this wiki, contact cjg@ecs.soton.ac.uk with your idea.