Main Page

From OpenOrg
Revision as of 14:32, 10 January 2011 by WikiSysop (talk | contribs)
Jump to: navigation, search

Open Data Patterns for Organisations

Open Org is an informal group wanting to create and collect good practice for organistaions wanting to create Open and Linked Data.

This wiki will be used to collect patterns and tools, and also to improve those patterns if they are found to be flawed. The default data will be assumed to be RDF, but variations are fine if that's sensible.

Open Data Patterns for Open Orgs

Cookbook

These pages should describe one or more patterns, along with tools which create and consume these patterns. Most patterns will just be a description of a sensible way to use existing classes & predicates.

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.

Recipes

Proposed

  • Boilerplate recommended data to include in any RDF document provided by your organisation.
  • Organisational Structure
  • Event Programmes
    • http://programme.ecs.soton.ac.uk - has been used by SemHE, Web Science Trust & Ventnor Fringe (all produced by Christopher Gutteridge). Site provides source for a tool to process the format into HTML and iCal.
  • Points of Sale or Service - including coffee shops, photocopy points, carparks etc.

Desired

Types of pattern:

  • Desired - someone would like there to be a pattern but nobody has proposed one yet
  • Proposed - a straw man for discussion
  • Established - must satisfy ALL of the conditions
    • at least one organistion provides open data in this pattern
    • at least one free tool produces this pattern
    • at least one free tool understands this pattern
  • Mature - must satisfy ALL of the conditions
    • at least three organistions provides open data in this pattern (sites run by the same group don't count)
    • at least one free tool produces this pattern
    • at least one free tool understands this pattern

Also you can mark things as a suspected or established Antipattern - This pattern has been tried and caused unexpected problems. Established means more than one group tried it and agrees it was a bad solution.



MediaWiki has been successfully installed.

Consult the User's Guide for information on using the wiki software.

Getting started