Methodology conventions

Follow a methodology

Title: Follow a methodology

Identifier MC-R1

Statement:

It is strongly recommended that a clear, explicit methodology is adopted for the content development and lifecycle management of a semantic data specification. Conversely, no data specification shall be developed and managed without following a clear methodology.

Description:

A methodology is a set of methods, processes, and practices that are repeatedly carried out to deliver projects (TOGAF [togaf]). It helps by using a clear set of processes for managing projects that everyone in the organisation understands, reducing risks, and improving the chances of success. A good methodology that fits the context and environment of an organisation can provide clear guidance on what, who, when, and how a project should be done. It also provides a clear path and a systematic strategy to solve the in-field problems.

We do not outline a concrete methodology here but merely point to the benefits of adopting and using one. In the SEMIC context, conceptual model development will benefit greatly from embracing some or a combination of techniques and frameworks in data modelling (e.g. Bottom-Up, Top-Down, Case-Based, Entity-Relationship, Object-Oriented, Star/Snowflake Schema data modelling techniques, etc.), ontology engineering methodologies (e.g. Methontology [fernandez-lopez97], DOGMA [jarrar08], OntoClean [guarino04], TOVE [fox92], DILIGENT [pinto04], NeOn [neon], etc. [sure09]), data management body of knowledge (DAMA-DMBOK [dama-dmbok]) or architecture frameworks and practices (e.g. TOGAF [togaf], Zachman Framework [zachman87], EAP [spewak06], etc.).

Among other benefits of adopting a clear and well-defined methodology are:

  • Clear lifecycle management

  • Connection between model and expressed (business) requirements

  • Implementation consistency

  • Proper business requirements management (specifications, use cases, scenarios, competency questions, etc. are collected, edited, maintained, referred by the concepts)

Scope and goals definition

Title: Scope and goals definition

Identifier MC-R2

Statement:

A semantic data specification shall have clear goals and a well-established scope definition.

Description:

Establishing project scope ensures that the modelling work is focused and executed to expectations. It also helps define where the boundary of the model is and what shall be left out.

The clearer the scope the higher chances of success are.

It shall be possible to determine the scope of a data specification from the use cases for which it is drawn up. [oslo-rules, sec 3.1.4]

Modularisation

Title: Modularisation

Identifier MC-R3

Statement:

If a domain contains a lot of concepts that have to be modelled, then it is recommended to partition it into subdomains and manage them as connected modules. [oslo-rules, sec 3.1.3]

Description:

Divide and conquer method works in many situations, including in the modelling realm. It may not be easy, however, to make a clearcut separation between concepts belonging to one module or another, and such an attempt will certainly bring clarity.

Sometimes, a concept can be used for several domains. Then it shall be placed in a separate module. [oslo-rules, sec 3.1.3]

The need for modularisation typically emerges when the to-be-modelled space grows. As the terms are to be identified by URIs [PC-R2], it is recommended to include in the used URI structure modularisation potential.

Examples:

For example, in the eProcurement ontology(ePO) [epo], there is a core ontology and there are extension modules such as eCatalogue, eOrdering, and eNotice [epo] that further refine and extend a specific part of the core.

For example, Core Location is used across other Core Vocabularies and is established as a CV on its own.