40
3 Marketplace-Level Domain Ontologies
3. Solver (osmo:solver)—MODA Sect. 3.3. The numerical solution of the model—
defined with a strict limitation to considering exactly the variables that occur in
the GEs explicitly (and nothing else).
4. Processor (osmo:processor)—MODA Sect. 3.4. Any computational operation
beyond the above; in particular, this includes and processing activity done
by a simulation code that goes beyond the immediate solution of underlying governing equations, e.g. to produce aggregated output. MODA is—strictly
speaking—limited to postprocessors. Depending on the role in the simulation
workflow, OSMO distinguishes between preprocessor, postprocessor, coupled
(i.e. synchronous) and data processor elements.
For each section, the MODA standard contains a list of text fields, which are
here referred to as section aspects, through which detailed information can be
provided. In OSMO, the detailed description of section individuals by section
aspects and their textual, numerical or object content is closely aligned with the
corresponding textual and numerical entries from MODA; by using the relation
osmo:has_aspect_object_content, it becomes possible to point to content provided
anywhere on the semantic web, including individuals and classes from the VIMMP
marketplace-level domain ontologies. Providing a common semantic basis for workflows, cf. Fig. 3.3, OSMO can be employed to consistently integrate data provenance
descriptions for materials modelling data from diverse sources [27].
Selected concepts from MACRO and OSMO:
• macro:channel: a data infrastructure which, in its evolution as a process, contains
communication events (semioses).
• osmo:condition: a statement concerning values of properties and/or parameters
and/or their relation to each other. Subclasses include mmto:kpi_model.
• osmo:einecs_listed_material: an EC listed material from the European Inventory of
Existing Commercial Chemical Substances (EINECS), which can be identified by
an EC number; analogous: osmo:cas_listed_material, identified by a CAS number.
• macro:io_format: a syntactical convention to which a technical I/O implementation
can adhere.
• osmo:logical_variable: a term that can be exchanged by interaction with logical
resources. Subclasses include osmo:unique_elementary (for scalar variables) and
osmo:optimization_objective.
• osmo:materials_relation: a Materials Relation (MR) as defined by RoMM [17], cf.
MODA entry 2.4 [20].
• macro:model_database: a repository that can act as a model provider.
• osmo:section_aspect: a descriptor of a section (osmo:section), following the
approach from MODA [20].
• osmo:workflow_graph: an LDT workflow graph-based description of a simulation,
or a part of such a graph-based description.
Selected relations from MACRO and OSMO:
3 Marketplace-Level Domain Ontologies
3. Solver (osmo:solver)—MODA Sect. 3.3. The numerical solution of the model—
defined with a strict limitation to considering exactly the variables that occur in
the GEs explicitly (and nothing else).
4. Processor (osmo:processor)—MODA Sect. 3.4. Any computational operation
beyond the above; in particular, this includes and processing activity done
by a simulation code that goes beyond the immediate solution of underlying governing equations, e.g. to produce aggregated output. MODA is—strictly
speaking—limited to postprocessors. Depending on the role in the simulation
workflow, OSMO distinguishes between preprocessor, postprocessor, coupled
(i.e. synchronous) and data processor elements.
For each section, the MODA standard contains a list of text fields, which are
here referred to as section aspects, through which detailed information can be
provided. In OSMO, the detailed description of section individuals by section
aspects and their textual, numerical or object content is closely aligned with the
corresponding textual and numerical entries from MODA; by using the relation
osmo:has_aspect_object_content, it becomes possible to point to content provided
anywhere on the semantic web, including individuals and classes from the VIMMP
marketplace-level domain ontologies. Providing a common semantic basis for workflows, cf. Fig. 3.3, OSMO can be employed to consistently integrate data provenance
descriptions for materials modelling data from diverse sources [27].
Selected concepts from MACRO and OSMO:
• macro:channel: a data infrastructure which, in its evolution as a process, contains
communication events (semioses).
• osmo:condition: a statement concerning values of properties and/or parameters
and/or their relation to each other. Subclasses include mmto:kpi_model.
• osmo:einecs_listed_material: an EC listed material from the European Inventory of
Existing Commercial Chemical Substances (EINECS), which can be identified by
an EC number; analogous: osmo:cas_listed_material, identified by a CAS number.
• macro:io_format: a syntactical convention to which a technical I/O implementation
can adhere.
• osmo:logical_variable: a term that can be exchanged by interaction with logical
resources. Subclasses include osmo:unique_elementary (for scalar variables) and
osmo:optimization_objective.
• osmo:materials_relation: a Materials Relation (MR) as defined by RoMM [17], cf.
MODA entry 2.4 [20].
• macro:model_database: a repository that can act as a model provider.
• osmo:section_aspect: a descriptor of a section (osmo:section), following the
approach from MODA [20].
• osmo:workflow_graph: an LDT workflow graph-based description of a simulation,
or a part of such a graph-based description.
Selected relations from MACRO and OSMO: