Guidelines

---

Note: the guidelines are currently under discussion, please use the issue tracker to make comments.

---

The guidelines are developed as a question catalogue in order to keep it compatible with other ontologies. The questions will state several options and we are indicating which decision was taken for the DBpedia Ontology and why. Other pages in this wiki show how the guidelines are transformed into ontology tests and run over the ontology after each change.

Language

• TODO document how the questions are styled
• Must produces errors, Should warnings
• follow should can must may according to specs

Guideline catalogue

External vocabularies

• Q: Which external vocabularies are allowed in DBpedia?
  • A: list of ontologies

RDFS, OWL, SKOS, DC, PROV, GEORSS, WGS84, FOAF

• Q: Are all properties allowed from these Vocabs or only specific ones?
  • A: Specific property list for each ontology

FOAF -> depiction, isPrimaryTopicOf, homepage

---

Class structure

• Q: Should all classes have instances?
  • Yes or No

should it for intent DBpedia design?

• Q: Are top-level classes fixed?
  • A: No or a list of classes

Activity, Agent, Concept, CommunicationSystem, Condition, Event, PhysicalThing, Place, TimePeriod

• Are there classes that cannot have subclasses?
  • A: No or a list of classes

Person -> add Professions where? under which condition?

• Monohierarchical tree vs. Polyhierarchy (Must classes have only one superclass?)
  • Yes for tree, no for acyclic graph

Yes

• Q: Should the ontology enforce a naming convention, i.e., camel toe case with upper-case for classes and lower-case for properties names?
  • Yes or no

Yes

• Q: Should it avoid class cycles in the ontology?

Yes

• Q: Must the sibling classes be pair-wise disjoint?

  • Yes or no

• Q: Can a class has only one direct subclass? (there may be a modeling problem or the ontology is not complete)

No

• Q: Can a class has more than a dozen subclasses? (additional intermediate categories may be necessary)

No

---

Property structure

• Monohierarchical tree vs. Polyhierarchy (Must properties have only one superproperty?)
  • yes for tree, no for acyclic graph

Yes

• If rdfs:domain and range exist, properties must not have complex values, i.e. only one class from dbo:namespace?
  • yes for simple domain/range, no for complex

Yes

• Properties should/must have at least one rdfs:domain and rdfs:range (no missing values)?
  • should or must

Should

---

Label and comment policy and multilinguality

• Should/must each class and property have at least one English label and comment?
  • should or must

Must

• Should several rdfs:label for the same language be allowed or should skos:prefLabel/altLabel be used for alternatives ?
  • several or SKOS

SKOS

• Which property is used to give a human readable definition (definitory property)?
  • name of property

rdfs:comment

• Should definitory properties in several language be in sync with the English one? (Assuming English is the normative and others are translations).
  • yes or no

Yes

• Which property is used for extended documentation on classes/properties?
  • name of property

dcterms:description

• What is the structure of the values of the definitory property?

TODO free text explanation

• What is the structure of the values of the extended documentation?

TODO markdown with the following content

Query driven validation

[Competency questions][1]

Write down those "basic" queries for which the ontology should provide answers.

A query Q over ontology O requires a class C, then the vocabulary of O must always has C.

[1]: Noy NF, McGuinness DL. Ontology development 101: A guide to creating your first ontology.