Data Model

From Mapping DH

This page provides an overview of our data model as we are in the process of implementing it. All scope notes (brief definitions), example items, mappings to other vocabularies, prose descriptions of data models, and links to entity schemas, are presented on the class, subclass and property pages themselves, rather than this information being duplicated here. (For further considerations and notes on the data modeling, see the section at the bottom of this page.)

Major classes of items

Major classes of items are those types of entities that are the main focus of this data collection effort. For all of these classes of items, the implicit focus is on Digital Humanities.

Unit (dependent)

Description, schema, instances. Subclasses:

Institution (independent)

Description, schema, instances. Subclasses:

Event

Event series: description, schema, instances.

Event: description, schema, instances. Subclasses:

Study programme

Description, schema, instances. Subclasses:

Publication

Description, schema, instances. Subclasses:

Individual classes

(No top-level class.)

Contextual item classes

Contextual classes are vocabularies to describe certain aspects of the major item classes; they can be derived from existing closed lists (such as countries or cities) or can be controlled vocabularies structuring a domain (such as fields of work or publication models).

Property classes

Properties can also be grouped into classes, for convenience's sake, but they are not modeled as superproperties. Note that properties do not, in our implementation, imply or include their inverse; rather, inverse properties are defined separately.

Meta-classes

Notes

The following are some notes, for documentation and reference, of some of the particularities of the data model that may not be immediately recognizable from the individual class and property definitions.

  • Items are localized not individuality (with their exact coordinate location), but always via the city they are located in. This relationship can be direct (as for institutions), or indirect (as for units that are part of institutions, or academics who are employed by institutions). However, there are some edge-cases that have no clear solution yet.
  • Properties are generally not bidirectional, but separate properties exist for each distinct directionality of a relationship. For example, for the treasurer of an association, there are two statements: `academic, is treasurer, association` as well as `association, has treasurer, academic`.
  • Scope notes are complemented, wherever feasible and useful, by identifying Wikidata entities or CIDOC CRM classes that are identical or equivalent, to help describe the meaning of each class or property.
  • While the usage constraints at the class-level are intended to be inherited by the subclasses, this inheritance is currently not implemented at the technical level.
  • Items as well as properties fall into groups. This is implemented in two ways: If the set of properties of the two classes are substantially distinct, the items are marked as instances of distinct subclasses. If not, all items are assigned the same class, but the 'type' mechanism is used. For an overview, see: list of all classes and subclasses.
  • Property constraints (like subject type or value type constraints / range or domain constraints) are a functionality that is currently not available on Wikibase.cloud. For this reason, such constraints are not implemented at this time.
  • Entity Schemas are used to describe the data model of classes in a machine-readable way using the ShEx language. This can be used to validate all instances of a given class / subclass. (This mechanism is used for selected classes at this time, for minimal requirements only, and the schema of a class is used for all instances of its subclasses.)
Retrieved from "https://mapping-dh.wikibase.cloud/w/index.php?title=Data_Model&oldid=12346"