Cookbook Guidelines

From OpenOrg
Jump to: navigation, search


(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
    • 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 with your idea.