Revision as of 14:45, 10 January 2011 by WikiSysop (Created page with "=== Guidelines === (open to negotiation & common sense, of course) * Examples ** Examples should be given in RDF+XML. ** RDF+XML examples should not use nested resources, excep...")
(open to negotiation & common sense, of course)
- 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.
<strike>tags to indicate examples of bad patterns which are not intended to be copied, but rather to serve as warnings.
- 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.