Following text and documents are authored by Francesco Beretta, Vincent Alamercery and Djamel Ferhod, and licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Download the conceptual model diagramm, version 0.2.7 : download conceptual model

General notes on the conceptual model

We use a generic database modelling approach with the aim of keeping the number of tables small and storing some parts of the model in form of data (system types).
Different entities having the same properties can be subsumed into a single entity: the distinction among them will be provided using a different system type for each entity class. E.g. scope notes are produced as instances of the Text property entity and are typed with the system type "scope note".
Some entities, like Namespace or Label are related to many different entities. These entities are therefore to be considered as instantiated subclasses of the generic abstract class of all the entities that belong to a namespace or that are labelled. To avoid having an illegible diagramm, the subclass links to these common entities are not drawn but the list of subclasses is provided inside the parent abstract class. E.g. "Entity with namespace" has following subclasses: Class, Property, Label, etc.. Specific foreign key columns will be provided in the application relational table for expressing the links to each one of the child classes of the general abstract class.

Classes and properties

Two basic classes are at the core of the application: Class and Property. The first one identifies the classes present in any ontology imported into or produced inside this application, the second one their properties.

Each instance of a class or a property MUST belong to at least one namespace: this allows to identify the ontology these classes and properties belong to. An identifier of the class or of the property in the respective namespace is mandatory.

The association of a class or property to the root namespace of an ontology (see below, Namespaces) is not allowed. Each instance must be associated to a specific namespace version, expressing the particular version of the ontology this class or this property belongs to.

The associations isSubclassOf and isSubpropertyOf are reified in order to also be able to associate these taxonomic relationships to a specific namespace. This association is mandatory and as a general rule it is the namespace of the child class or property.

Classes

A class is identified by its identifier in his namespace and by its intention, expressed in a scope note. If the class intention remains essentially the same in the different versions of the ontology, a class can belong to different specific namespaces. However these must be versions of the same root namespace. If the scope note of a class changes from one version to the next one, even if the class identifier remains the same, a new scope note instance will be produced and associated to a new namespace corresponding to the new ontology version. On the other hand, if the identifier and identifying intension of the class itself does not change, no new instance of a class will be produced.

Properties

Properties are identified in the application by their identifier in the namespace, by their intension, and by their domain and range classes. If these three components are unchanged in a new ontology version, an instance of a property can belong also to the new version of the same root namespace. Otherwise, a new instance of property is created to take into account this identity change (notably of the domain or range classes of a property) and added to the new ontology version namespace.

Four quantifiers are provided for the Property entity : Domain instances min quantifier; Domain instances max quantifier; Range instances min quantifier; Range instances max quantifier.

They have the same intension as the CRM property quantifiers: "These declarations are ontological, i.e. they refer to the nature of the real world described and not to our current knowledge. For example, each person has exactly one father..." (CIDOC CRM 6.2, p.xiii). This does not exclude that an information system can provide more instances of the same property, in the sense of alternatives opinions, then those allowed by the quantifiers. Quantifiers are therefore ontological in their substance, whether cardinality is about implementation in an information system.

Property quantifiers are recommended.

Namespaces

This topic is exposed on this page.

Associations

Different kinds of associations between classes, properties and more generally different kinds of entities will be expressed using the generic concept of association. The type of the instances will be expressed using application types.

E.g. the equivalence of two classes will be expressed using an instance of the association entity by typing it with the owl:equivalentClass property; the definition of this property itself will be provided as instance of the property entity. Furthermore, the equivalence of a subclass or subproprety in one ontology with a class type or property type in another ontology will be expressed using associations with an appropriate system type.

Projects

A project instance allows to define matadata (i.e. label(s), definition(s), begin and end date, etc.) about a research project in history or any other project using the dataforhistory.org application.

The values for the Start date and End date of a project SHOULD be provided.

Sub-projects devoted to a specific aspect of the research activity of a team can be documented as child instances of the root project for that team.

A project can manage one or more root namespaces, and all particular namespaces affiliated to them. A root namespace can be associated to and managed by only one project. Permissions to modify data extend to all elements within the project's root namespace and all descendant namespaces. Cf. the namespace topic.

Registered users of the application will be affiliated to at list one project and can be members of different projects. Projects managers will have to define project related permissions for users, i.e. who can modify project related data and to what extent. It is only possible for any registered user of the application to modify data related to the project he/she belongs to, according to the permissions level in the project.

Given the role of namespaces in the application, and their strict association to only one project, users enabled for this project will able to modify all classes, properties, scope notes, etc. belonging to a root namespace associated to the project, and all it's versions. Specific versions authorizsation could also be managed at sub-project level.

Profiles

A profile instance allows to define a collection of classes, properties, scope notes, labels, etc. that will be available in a project or application if the profile is choosen. The association to a profile can also be used to exclude or include specific properties directly belonging to or inherited by a class in this specific collection.

A profile belongs to and can be managed by one and only project. The profile can be a project specific or generic, community driven one. A scope note providing a clear definition of the profile MUST be provided. The values for the Start date and End date of a profile SHOULD be provided. The profile can be adopted and used by different projects.

Issues to be discussed

Does a profile have subprofiles which inherit the profiles classes and properties and one can add or remove some classes and properties?
Multiple inheritance allowed ?
Are there differents types of profiles ?

Class-properties paths: definition ? use cases ? treatment ?
 

Commentaries

Discussions of the platform participants can be added in form of comment entities to most entities of the application and also to most associations. Comments can be answered by other users and the answers again commented.

One comment cannot be associated to another one out of a strict reflexive hierarchy.

Class types, property types

The entities Class type and Property type can be used to share community defined vocabulaires making explicit use cases for classes and properties in projects using them. These types will be specific to historical sub-domains and projects. If needed, this will also allow to map types, i.e. terms in controlled vocabularies, to classes. Conceptual relationships between types will be expressed using the SKOS properties available in the application.

NB: class types and property types are totally independent from each other and are only related to the class or property they type. There's no possibility to associate property types to class types. If there's the need of restricting the use of some property types to some class types, it is mandatory to define subclasses and subproperties instead of types.

.