emmo-repo / emmo Goto Github PK

View Code? Open in Web Editor NEW

56.0 14.0 17.0 36.48 MB

Elementary Multiperspective Material Ontology (EMMO)

License: Other

Shell 69.47% Python 30.53%

ontology materials modelling applied-science top-level-ontology

emmo's Introduction

Elementary Multiperspective Material Ontology (EMMO)

Table of content

About EMMO
- Some words about the new name and logo
- Use of EMMO in domain ontologies
EMMO in a Nutshell
Repository Description
How to Use It
- Pre-inferred ontology and documentation
Contacts
Acknowledgement

About EMMO

EMMO is a multidisciplinary effort to develop a standard representational framework (the ontology) for applied sciences. It is based on physics, analytical philosophy and information and communication technologies. It has been instigated by materials science to provide a framework for knowledge capture that is consistent with scientific principles and methodologies. It is released under a Creative Commons CC BY 4.0 license.

Some words about the new name and logo

The name Elementary Multiperspective Material Ontology should be understood as follows:

Elementary means, amongst others, that EMMO is a discrete ontology assuming the existence of a smallest possible 4D world object in space and time. The term Elementary in EMMO refers to objects that cannot be divided further in space. Elementary also emphasizes EMMO being a fundamental, top-level ontology.
Multiperspective highlights a very important aspect of EMMO - that it is possible to describe the world from different perspectives. This makes the ontology both flexible and expressive.
Material (as the opposite of immaterial) emphasises that EMMO is strictly nominalistic, meaning that it assumes that abstracts do not exist. Material also refers to the historical scope of EMMO aiming at the description of materials and thus to cover the needs of physicists and applied scientists.
Ontology, yes EMMO is an ontology. It is based on fundamental philosophical concepts like semiosis, mereology and topology.

A lot can be said about the logo:

The circles refer to Peirce's semiotics with the triadic relation between sign, object and interpretant with the interpreter in the middle.
The symmetry indicates that EMMO supports multiple perspectives.
The E-like signs can be seen from different perspectives (angles), making it possible to read it as E M M ⵔ as well as ∃ (there exists) a Шhole Шorld ⵔntology (with the circle in the middle).
The 3+1 circles emphasises that EMMO is a 4D ontology with three spatial plus one time dimension.
The lines connecting the circles may refer to graph theory and knowledge graphs.
A triangle is a common way to represent a ternary phase diagram showing the close connection to physics.

Use of EMMO in domain ontologies

Currently there are several domain ontologies in development that use EMMO as the top and middle level ontology. Typically they import one of the versions of EMMO listed on https://emmo-repo.github.io/. The following table lists the public EMMO-based domain ontologies that we are aware of. Please create an issue if you have a public domain ontology that you think should be listed here.

Domain ontology	Link
Battery Interface Ontology (BattINFO)	https://github.com/BIG-MAP/BattINFO
General Process Ontology (GPO)	https://github.com/General-Process-Ontology/ontology
Ontology for the Battery Value Chain (BVC)	https://github.com/Battery-Value-Chain-Ontology/ontology
Crystallography	https://github.com/emmo-repo/domain-crystallography
Mechanical Testing	https://github.com/emmo-repo/domain-mechanical-testing
Microstructure domain ontology	https://github.com/emmo-repo/domain-ontology
Datamodel ontology	https://github.com/emmo-repo/datamodel-ontology
Mappings ontology	https://github.com/emmo-repo/domain-mappings
Atomistic and Electronic Modelling	https://github.com/emmo-repo/domain-atomistic
EMMO example domain ontologies	https://github.com/emmo-repo/EMMO/tree/master/domain

EMMO in a Nutshell

The EMMO ontology is structured in shells, expressed by specific ontology fragments, that extends from fundamental concepts to the application domains, following the dependency flow.

Top Level

The EMMO top level is the group of fundamental axioms that constitute the philosophical foundation of the EMMO. Adopting a physicalistic/nominalistic perspective, the EMMO defines real world objects as 4D objects that are always extended in space and time (i.e. real world objects cannot be spaceless nor timeless). For this reason abstract objects, i.e. objects that does not extend in space and time, are forbidden in the EMMO.

EMMO is strongly based on the analytical philosophy dicipline semiotic. The role of abstract objects are in EMMO fulfilled by semiotic objects, i.e. real world objects (e.g. symbol or sign) that stand for other real world objects that are to be interpreted by an agent. These symbols appear in actions (semiotic processes) meant to communicate meaning by establishing relationships between symbols (signs).

Another important building block of from analytical philosophy is atomistic mereology applied to 4D objects. The EMMO calls it 'quantum mereology', since the there is a epistemological limit to how fine we can resolve space and time due to the uncertanity principles.

The mereotopology module introduces the fundamental mereotopological concepts and their relations with the real world objects that they represent. The EMMO uses mereotopology as the ground for all the subsequent ontology modules. The concept of topological connection is used to define the first distinction between ontology entities namely the Item and Collection classes. Items are causally self-connected objects, while collections are causally disconnected. Quantum mereology is represented by the Quantum class. This module introduces also the fundamental mereotopological relations used to distinguish between space and time dimensions.

The physical module, defines the Physical objects and the concept of Void that plays a fundamental role in the description of multiscale objects and quantum systems. It also define the Elementary class, that restricts mereological atomism in space.

In EMMO, the only univocally defined real world object is the Item individual called Universe that stands for the universe. Every other real world object is a composition of elementaries up to the most comprehensive object; the Universe. Intermediate objects are not univocally defined, but their definition is provided according to some specific philosophical perspectives. This is an expression of reductionism (i.e. objects are made of sub-objects) and epistemological pluralism (i.e. objects are always defined according to the perspective of an interpreter, or a class of interpreters).

The Perspective class collects the different ways to represent the objects that populate the conceptual region between the elementary and universe levels.

Middle Level

The middle level ontologies act as roots for extending the EMMO towards specific application domains.

The Reductionistic perspective class uses the fundamental non-transitive parthood relation, called direct parthood, to provide a powerful granularity description of multiscale real world objects. The EMMO can in principle represents the Universe with direct parthood relations as a direct rooted tree up to its elementary constituents.

The Holistic perspective class considers the importance and role of the whole and introduces the concept of real world objects that unfold in time in a way that has a meaning for the EMMO user, through the definition of the classes Process and Participant.

The Perceptual perspective class introduces the concept of real world objects that can be perceived by the user as a recognisable pattern in space or time. Under this class the EMMO categorises e.g. formal languages, pictures, geometry, mathematics and sounds. Phenomenic objects can be used in a semiotic process as signs.

The Physicalistic perspective class introduces the concept of real world objects that have a meaning for the ontologist under an applied physics perspective.

The semiotics module introduces the concepts of semiotics and the Semiosis process that has a Sign, an Object and an Interpreter as participants. This forms the basis in EMMO to represent e.g. models, formal languages, theories, information and properties.

EMMO relations

All EMMO relations are subrelations of the relations found in the two roots: mereotopological and semiotical. The relation hierarchy extends more vertically (i.e. more subrelations) than horizontally (i.e. less sibling relations), facilitating the categorisation and inferencing of individuals.

Imposing all relations to fall under mereotopology or semiotics is how the EMMO force the developers to respect its perspectives. Two entities are related only by contact or parthood (mereotopology) or by standing one for another (semiosis): no other types of relation are possible within the EMMO.

Repository Description

You can find the EMMO ontology at http://emmo.info/emmo. The basic structure of the EMMO is collected by the top ontology.

The overall middle level ontologies are collected by the emmo ontology.

Examples of common extensions of EMMO middle can be found in the domain sub-directory.

The OWL2-DL sources are available in turtle format. Other formats are available from https://emmo-repo.github.io/.

A description of the EMMO Governance, organisation of related repositories, conventions and how to contribute can be found here.

How To Use It

In order to be able to view and navigate the EMMO ontology we recommend to download the Protégé editor from https://protege.stanford.edu/products.php#desktop-protege.

See these instructions for how to set up Protégé for working with EMMO-based ontologies.

The fastest way to access the EMMO is to open the ontology via Protégé via the menu under File -> Open from URL... and copy the URL http://emmo.info/emmo: Protégé will automatically download all the necessary dependencies.

The EMMO hierarchy will be visible only after reasoning inference: use ctrl-R to start the reasoner and under the Entities tab, select the Classes subtab and Inferred in the scroll button.

It is recommended to use FaCT++ as reasoner. You can select it through the menu Reasoner. An instruction for how to install the FaCT++ plugin on Protege 5.5.0 on Windows can be found in the doc subdirectory.

To access EMMO from Python, we recommend EMMO-python.

Pre-inferred ontology and documentation

Browsable documentation and pre-inferred versions of EMMO are available on https://emmo-repo.github.io/.

Contacts:

You can contact EMMO Authors via [email protected]

Acknowledgement

This work has been supported by several European projects, including:

EMMC-CSA (2016-2019), that has received funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 723867.
SimDOME (2019-2023), that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 814492.
MarketPlace (2018-2022) that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 760173.
VIMMP (2018-2021) that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 760907.
OntoTrans (2020-2024) that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 862136.
ReaxPro (2019-2023) that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 814416.
OntoCommons (2020-2023) that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 958371.
OYSTER (2017-2021) that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 760827.
NanoMECommons (2021-2025) that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 952869.
OpenModel (2021-2025) that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 953167.

This work was conducted using the Protégé resource, which is supported by grant GM10331601 from the National Institute of General Medical Sciences of the United States National Institutes of Health.

emmo's People

Contributors

Stargazers

Watchers

Forkers

egonw lukas-koschmieder jesper-friis quaat luisenriqueramos1977 standardgalactic gerhardgoldbeck andrecastro0o ebrahimnorouzi jannisgrundmann simonstier hothello beyucel jsimonclark davidmercier berndbayerlein lara-ontologies

emmo's Issues

Change file format from rdf/xml to turtle

Turtle is a more readable and git-friendly file format than the current rdf/xml.

The idea is therefore to change the file format of the development version of EMMO from current rdf/xml to turtle. However, since rdf/xml is subborted by more tools we must at the same time set up automatic tools that converts both the asserted and inferred ontology to rdf/xml and publish them on GitHub Pages. New columns for rdf/xml and turtle (and maybe other formats) should be added to the table on https://emmo-repo.github.io/.

This requires issue #121 to be implemented first.

Use SKOS mapping concepts when referring to other resources

Currently EMMO refers to other resources and ontologies using subproperties of rdfs:seeAlso. I think replacing these with subproperties of skos:exactMatch and skos:closeMatch would improve interoperability.

See https://www.w3.org/TR/skos-primer/#secmapping

Standard annotations

EMMO defines a set of annotations under the annotations namespace. For increased interoperability with standard tooling, it would be better to use standards like Dublin Core and SKOS as follows:

annotations:author: use dcterms:contributor instead
annotations:license: use dcterms:license instead
annotations:definition: use skos:definition instead
annotations:example: use skos:example instead
annotations:elucitation: I don't think that there is a corresponding standard. We may keep it as a subproperty of rdfs:comment, but I think it is more consistent to change it to a subproperty of skos:note (which itself is a subproperty of rdfs:comment).
annotations:altLabel: use skos:altLabel instead
rdfs:label: use skos:prefLabel instead. This is according to best practices. It is already included in the SKOS standard that an entity should only have one skos:prefLabel.

For annotating the ontology itself, dcterms provides some additional useful properties like dcterms:title, dcterms:abstract, dcterms:date, ...

This enhancement will also fix issue #23.

SKOS also defines skos:Collection and skos:OrderedCollection which might useful when defining compositions and arrays, respectively, in EMMO.

This enhancement require that we add the following namespaces to all owl files:

xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:skos="http://www.w3.org/2004/02/skos/core#"

human readable IRI

currently IRIs are complex, e.g., http://emmo.info/latest/domains/emmo-material.owl#EMMO_a2b006f2_bbfd_4dba_bcaa_3fca20cd6be1
for a machine it does not matter if its like that or something like http://emmo.info/latest/domains/emmo-material.owl#EMMO_UNIT_MASS

the latter is much simpler. Are there any advantages for UUID like IRI#s?

Improve the model branch

While EMMO has had developed physical quantities quite far, the description of models is lacking behind.

Fix redirections

Example:
http://emmo.info/emmo/1.0.0-beta/top is supposed to be redirected to https://github.com/emmo-repo/EMMO/raw/1.0.0-beta/top/top.owl but unfortunately it is redirected to https://github.com/emmo-repo/EMMO/raw/1.0.0-beta/emmo.owl which is the top-level EMMO itself.

The same is the case for all other modules.

Missing annotations

From running OntOlogy Pitfall skanner! (OOPS!) on http://oops.linkeddata.es/

Results for P08: Missing annotations.87 cases | Minor

This pitfall consists in creating an ontology element and failing to provide human readable annotations attached to it. Consequently, ontology elements lack annotation properties that label them (e.g. rdfs:label, lemon:LexicalEntry, skos:prefLabel or skos:altLabel) or that define them (e.g. rdfs:comment or dc:description). This pitfall is related to the guidelines provided in [5].

[5] Vrandecic, D. (2010). Ontology Evaluation. PhD thesis.

Create command line tool for converting from turtle to rdf/xml

Improvements in Readme.md

In the Middle Level description text there are four paragraphs entitled: Reductionistic, Holistic, Phenomenic and Physics while in the picture and in the owl file names are slightly different, this might be confusing.

Document emmo modules individually

The documentation of all top and middle EMMO modules are currently the same as http:emmo-repo.info/emmo. But it would make sense to replace dcterms:abstract with a description of the different modules.

dcterms:title should maybe also be updated.

hasSymbolData is functional and has domain Symbol

Hi, I have a question concerning issue #85 .

in 1.0.0-alpha2, hasSymbolData has domain Symbol and is functional. That still means that every Symbol, including math.Integer or math.Real must have that relationship, right?

    <owl:DatatypeProperty rdf:about="http://emmo.info/emmo/middle/perceptual#EMMO_23b579e1_8088_45b5_9975_064014026c42">
        <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/>  # it is functional
        <rdfs:domain rdf:resource="http://emmo.info/emmo/middle/perceptual#EMMO_a1083d0a_c1fb_471f_8e20_a98f881ad527"/>  # domain is symbol
        <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
        <skos:prefLabel xml:lang="en">hasSymbolData</skos:prefLabel>
    </owl:DatatypeProperty>

Recursive definitions

From running OntOlogy Pitfall skanner! (OOPS!) on http://oops.linkeddata.es/

Results for P24: Using recursive definitions.5 cases | Important

An ontology element (a class, an object property or a datatype property) is used in its own definition. Some examples of this would be: (a) the definition of a class as the enumeration of several classes including itself; (b) the appearance of a class within its owl:equivalentClass or rdfs:subClassOf axioms; (c) the appearance of an object property in its rdfs:domain or range rdfs:range definitions; or (d) the appearance of a datatype property in its rdfs:domain definition.

• This pitfall appears in the following elements:
› http://emmo.info/base/emmo-physical.owl#EMMO_0f795e3e_c602_4577_9a43_d5a231aa1360
› http://emmo.info/base/emmo-physical.owl#EMMO_29072ec4_ffcb_42fb_bdc7_26f05a2e9873
› http://emmo.info/base/emmo-physical.owl#EMMO_c5ddfdba_c074_4aa4_ad6b_1ac4942d300d
› http://emmo.info/domains/emmo-material.owl#EMMO_70dac51e_bddd_48c2_8a98_7d8395e91fc2
› http://emmo.info/domains/emmo-material.owl#EMMO_5b2222df_4da6_442f_8244_96e9e45887d1

The corresponding labels are:

elementary
void
physical
field
matter

URI contains file extension

From running OntOlogy Pitfall skanner! (OOPS!) on http://oops.linkeddata.es/

Results for P36: URI contains file extension.ontology* | Minor

This pitfall occurs if file extensions such as ".owl", ".rdf", ".ttl", ".n3" and ".rdfxml" are included in an ontology URI. This pitfall is related with the recommendations provided in [9].

*This pitfall applies to the ontology in general instead of specific elements.

[9] Archer, P., Goedertier, S., and Loutas, N. (2012). D7. 1.3-study on persistent URIs, with identification of best practices and recommendations on the topic for the Mss and the EC. PwC EU Services.

Broken ontology URL

The ontology URL (http://emmo.info/emmo.owl) (see README.md) is broken: HTTP 404 (Not Found).

Add Intentional processes

In technological applications many actions are intentional. We need to cover it in EMMO.

A proposal to add a "triangle with a central element" similar to Semiotic Triangle is suggested:

nodes:

physical representing the thing that is subject to the action. This physical has properties associated with in in a semiotic process that are subject to change as a result (note the action is not on the properties as wrongly attributed in some process description, but on the thing (physical) itself)
physical representing the rendered or operated on the thing above (also physical) along with its new properties (again obtained by new semiotic processes)
The "intentional" representing the plan, i.e., the change (e.g., cut a sample, pull a sample, or an entire set of steps like an algorithm, or a step in an algorith, or a MODA workflow, etc)

the center of the triangle has the agent.

All the above is contained in an intentional process, like the sign, object etc are contained in the semiotic process.

The semiotic process can also have its on "intentional triangle" to describe how the measurement is done for example, and by whom etc.

Add chemical composition

We need a semantic way to describe chemical compositions and other physical quantities that are specific to a constituent (atom or molecule).

This is a long-needed feature that has been discussed a lot, but never went into EMMO.

This issue is different from issue #99, since chemical compositions are unordered.

Clean up the released inferred ontology

The inferred ontology produced with FaCT++ includes some redundant isA (isSubclassOf) relations that would be nice to get rid of.

Examples of such redundant relations:

Matter isA Physical         (redundant because Matter isA Physicalistic isA Perspective isA Physical)
Field isA Physical          (redundant because Field isA Physicalistic isA Perspective isA Physical)
Process isA Physical        (redundant because Process isA Holistic isA Perspective isA Physical)
Participant isA Physical    (redundant because Participant isA Holistic isA Perspective isA Physical)

Since the reasoner does not add all isA relations to all possible ancestors, tools using the ontology must anyway check the list of ancestors. To avoid double-counting because of these redudant isA relations, the tools must add additional tests complicating their implementation.

This would require that we add an additional tool.

plz consider listing in BioPortal and OLS

BioPortal: http://bioportal.bioontology.org/
EBI Ontology Lookup Service: https://www.ebi.ac.uk/ols/index

Add hasPrevious and hasNext object properties as subproperties of hasContactWith

This allows introducing ordering and is very important for concepts like 'string', 'serialisation', ordering of dimensions, etc

This is an essential and long-needed feature for providing a semantic description of dimensional properties.

A more general implementation of ordering would be LISP-like (head rest) tuples or "compartments". The 'head' of a compartment would be a reference the class or individual that should be ordered, while the 'rest' or a compartment would be a reference to another compartment or owl:Nothing.

xml:lang in comments in emmo-inferred

Dear @emanueleghedini , @jesper-friis ,

I hope you are doing well.
While using the emmo-inferred.owl file I notice some a minor inconsistency I guess. For instance the second line of the following excerpt of code is xml:lang="unibo.it" instead of xml:lang="en". Please let me know what you think.

Version 1.0.0-alpha2</owl:versionInfo>
        <rdfs:comment xml:lang="unibo.it">Contacts:
Gerhard Goldbeck
Goldbeck Consulting Ltd (UK)
email: [email protected]

Many thanks!

Kind Regards,
Joana

Hands-on Examples with instance data

Dear EMMO developers,

I have been recently looking into EMMO an it’s seems to be a great ontology in the materials domain.

It is very well documented (e.g. training), however, I am missing an examples section where hands-on examples are presented. Maybe I just did not find them?

From other well known ontologies, e.g. SOSA https://www.w3.org/TR/vocab-ssn/#examples, these kind of examples are provided, which are very helpful to figure out the usage.

For instance it would be interesting to represent the following data:

Material: 55NiCrMoV6

CHEMICAL COMPOSITION (WEIGHT %)
C (％): 0.50 ～ 0.60
Si(％): 0.10 ～ 0.40
Mn(％): 0.65 ～ 0.95
P(％)≤: 0.030
S(％)≤: 0.030
Cr(％): 0.60 ～ 0.80
Mo(％): 0.25 ～ 0.35
V(％): 0.07 ～ 0.12
Other(％): Ni 1.50 ～ 1.80
MECHANICAL PROPERTIES - HOT WORKING, HEAT TREATMENT AND HARDNESS
Hot working tenperature /℃: 1050～850
Annealing temperature /℃: 650-710
Hardness after annealing ≤HBW: 240
Quenching temperature /℃: 830 - 870

Best

Georg

Factor out all scripts under .github/scripts into an own easily reusable repository

Make a new repository with tools for publishing

inferred ontology
the ontology in a few common formats (rdf/xml, turtle, ...)
generated documentation (html, pdf)

for each release.

This should be easy to use on both github and gitlab supporting GitHub Pages, GitLab Pages, +++ as targets.

Add redirection for inferred ontology

If we add the following redirections to http://emmo.info

http://emmo.info/emmo/emmo-inferred.owl -> https://emmo-repo.github.io/versions/latest/emmo-inferred.owl
http://emmo.info/emmo/<VERSION>/emmo-inferred.owl -> https://emmo-repo.github.io/versions/<VERSION>/emmo-inferred.owl

we can delete emmo-inferred.owl from the repository. That will prevent growing the EMMO repository unnessesary much, making slow and large to clone.

version number in IRI of Newton and Farad

The IRI of Newton and Farad contains the version 1.0.0-alpha or 1.0.0-alpha2. This must be a mistake.

Scientific notation not supported with xsd:decimal

AllegroGraph was not able to import EMMO because siunits.owl use xsd:decimal, which does not support scientific notation.
Changed xsd:decimal to xsd:float in the file and imported the ontology successfully into the triplestore.

See https://github.com/quaat/EMMO/blob/master/middle/siunits.owl

Equivalent classes not explicitly declared

From running OntOlogy Pitfall skanner! (OOPS!) on http://oops.linkeddata.es/

Results for P30: Equivalent classes not explicitly declared.4 cases | Important

This pitfall consists in missing the definition of equivalent classes (owl:equivalentClass) in case of duplicated concepts. When an ontology reuses terms from other ontologies, classes that have the same meaning should be defined as equivalent in order to benefit the interoperability between both ontologies.

• The following classes might be equivalent:
› http://emmo.info/domains/emmo-geometry.owl#EMMO_d7bf784a_db94_4dd9_861c_54f262846fbf, http://emmo.info/domains/emmo-material.owl#EMMO_70dac51e_bddd_48c2_8a98_7d8395e91fc2 (sphere, field)
› http://emmo.info/domains/emmo-geometry.owl#EMMO_39362460_2a97_4367_8f93_0418c2ac9a08, http://emmo.info/base/emmo-mereotopology.owl#EMMO_eb3a768e_d53e_4be9_a23b_0714833c36de (point, item)
› http://emmo.info/domains/emmo-material.owl#EMMO_3397f270_dfc1_4500_8f6f_4d0d85ac5f71, http://emmo.info/domains/emmo-material.owl#EMMO_eb77076b_a104_42ac_a065_798b2d2809ad (molecule, atom)
› http://emmo.info/base/emmo-physical.owl#EMMO_29072ec4_ffcb_42fb_bdc7_26f05a2e9873, http://emmo.info/domains/emmo-material.owl#EMMO_3c218fbe_60c9_4597_8bcf_41eb1773af1f (void, vacuum)

Several classes with the same label

From running OntOlogy Pitfall skanner! (OOPS!) on http://oops.linkeddata.es/

Results for P32: Several classes with the same label.3 cases | Minor

Two or more classes have the same content for natural language annotations for naming, for example the rdfs:label annotation. This pitfall might involve lack of accuracy when defining terms.

Missing restrictions

A few missing restrictions:

SiCoherentDerivedUnit should also be a subclass of DerivedUnit
According to slide 129 in Emanuele's presentation at the training workslop June 7, 2019 is a quantitative property related to a measurement. Hence, add Measurement hasParticipant some QuantitativeProperty, which is a refinement of the observation having a property as a participant.

Add model entities with associated properties

Missing license

From running OntOlogy Pitfall skanner! (OOPS!) on http://oops.linkeddata.es/

Results for P41: No license declared.ontology* | Important Important

The ontology metadata omits information about the license that applies to the ontology.

*This pitfall applies to the ontology in general instead of specific elements.

Exception: 'unibo.it' is not a valid language tag!

Hello,

I get the following error, when parsing EMMO using rdflib:

  File "/home/urba/miniconda3/envs/osp/lib/python3.8/site-packages/rdflib/term.py", line 566, in __new__
    raise Exception("'%s' is not a valid language tag!"%lang)
Exception: 'unibo.it' is not a valid language tag!

I guess this is the reason:

<rdfs:comment xml:lang="unibo.it">Contacts:
Gerhard Goldbeck
Goldbeck Consulting Ltd (UK)
email: [email protected]

Emanuele Ghedini
University of Bologna (IT)
email: emanuele.ghedini</rdfs:comment>

Project support acknowledgements

Can we please add the VIMMP, MarketPlace and OntoTrans projects to the acknowledgements. GCL used resources from these projects to contribute. Should be done for alpha-2
This work is conducted under the framework of the VIMMP project (2018-2021), that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 760907
This work is conducted under the framework of the MarketPlace project (2018-2022), that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 760173
This work is conducted under the framework of the OntoTrans project (2020-2024), that receives funding from the European Union’s Horizon 2020 Research and Innovation Programme, under Grant Agreement n. 862136

Inverse relationships not explicitly declared

From running OntOlogy Pitfall skanner! (OOPS!) on http://oops.linkeddata.es/

Results for P13: Inverse relationships not explicitly declared.17 cases | Minor

This pitfall appears when any relationship (except for those that are defined as symmetric properties using owl:SymmetricProperty) does not have an inverse relationship (owl:inverseOf) defined within the ontology.

• OOPS! has the following suggestions for the relationships without inverse:
› http://emmo.info/perspectives/emmo-existent.owl#EMMO_b2282816_b7a3_44c6_b2cb_3feff1ceb7fe could be inverse of http://emmo.info/perspectives/emmo-existent.owl#EMMO_a50d920d_1ee3_4668_9a73_5d80a1c6fe15
› http://emmo.info/base/emmo-mereotopology.owl#EMMO_7afbed84_7593_4a23_bd88_9d9c6b04e8f6 could be inverse of http://emmo.info/base/emmo-4d.owl#EMMO_f68030be_94b8_4c61_a161_886468558054
› http://emmo.info/base/emmo-4d.owl#EMMO_f68030be_94b8_4c61_a161_886468558054 could be inverse of http://emmo.info/base/emmo-4d.owl#EMMO_6e046dd0_9634_4013_b2b1_9cc468087c83

Add datatypes to EMMO

This is a first draft for adding datatypes to EMMO. Datatypes (here called Value) are essential for using EMMO in actual applications.

Would it be better to rename "Value" to "Datatype"? I have been using Value here, since it feels more natural to say that a property has part Value than DataType.

The SumType is an interesting suggestion by Petter that needs to be discussed to get right. It will allow an EMMO-based application ontology to specify that e.g. salt concentration may be represented with either a single average value, a statistical distribution or spatially resolved grid.

Edit: Updated CompoundItem.

Classes

Value

subclassOf SymbolicDomain (??)
Subclasses:
- BasicValue
  - disjointUnionOf Boolean, Number, String
- NumericValue
  - disjointUnionOf Number, NumericArray
- Array
  - hasDimension some Dimension
    Subclasses:
    - NumericArray
      - hasSpatialPart some Number
        Subclasses:
      - Matrix
        
        hasDimension exactly 2 Dimension
- CompoundValue
  An unordered set of key-value pairs, like C struct's or Python dict's.
  - hasSpatialPart some CompoundItem
- SumType
  How to implement this?
  - hasSpatialPart X or Y or Z (??)

Number

Natural
Integer
Rational
Subclasses:
* Float
Real
Complex
Quaternion
Octonion (for Georg :-)

Boolean

subclassOf Mathematical

CompoundItem
A CompoundItem has two spatial parts, 'item' and 'value'. It makes a
connection between an already defined concept (an EMMO Item) and a corresponding value.

subclassOf SymbolicStructured ??
hasKey some Item (should we use "exact 1" Item ??)
hasValue some Value (should we use "exact 1" Value ??)

Dimension
Dimensions are used to construct arrays. They have a size and may be chained using hasNextDimension to provide an ordered list of dimensions. It would also be very useful to assign a name to each dimension or a quantity. Should we use value restrictions for that?

subclassOf Mathematical
hasValue some Natural (or exactly 1?)
hasNextDimension some Dimension (or max 1?)

Relations

hasValue

subclass of: hasSpatialPart
domain: Item # should it be more restricted?
range: Value

hasKey

subrelationOf hasSpatialPart
domain: CompoundItem
range: Item

hasDimension
Cardinality may be used to specify exact, max or min size of a dimension.
Otherwise the dimension size must be assigned at instantiation.

subclass of: hasSpatialPart
domain: Array or Property?
range: Dimension

hasNextDimension

subclass of: hasSpatialPart
domain: Dimension
range: Dimension

domains catalogue file wrong path

the catalogue file under domains in the emmo-units branch (see #15 ) contains some wrong references:
<uri id="Automatically generated entry, Timestamp=1577294513690" name="http://emmo.info/domains/emmo-si-units.owl" uri="emmo-si-units.owl"/>
--> there is no emmo-si-units under domains.

also need to replace local references as in:

<uri id="Imports Wizard Entry" name="http://emmo.info/emmo.owl" uri="file:/home/jesperf/prosjekter/EMMC/emmo/emmo.owl"/>

Value other than number for physics quanity

currently a physics quantity has a number and unit, however, this may mean (if we ugnore transitivness) that emmo only supports scalar quanititeis like mass or Temperature, not e.g., force or velocity etc which are vector quantities or tensor quanitities that descrive how a physics quantitiy is represented int time-space.

Proposal:

replace number by value in physical quantity
has_spatial_part some ~~number~~ value
then either:
- add value as a mathematical, since a value maybe a function or any other mathematical, not only a number (and can also be a number of course) and let value be a super class of any scalar, vector or any other emmo:mathemtatical type
  OR alternatively,

the physics quantities themselves subclass from vector_quantity, tensor_quantity, etc. and each would have a value that is a mathematical

NOTE this is not about the data type which should not be part of EMMO it self, but the implementations, this is about the representation of physics quantities that are not simple numbers (the data type may refer for example to double or float, in emmo it is simply a read number).

maybe related to #27

Unconnected ontology elements

From running OntOlogy Pitfall skanner! (OOPS!) on http://oops.linkeddata.es/

Results for P04: Creating unconnected ontology elements.7 cases | Minor

Ontology elements (classes, object properties and datatype properties) are created isolated, with no relation to the rest of the ontology.

• This pitfall appears in the following elements:
› http://emmo.info/domains/emmo-material.owl#EMMO_7db59e56_f68b_48b7_ae99_891c35ae5c3b
› http://emmo.info/domains/emmo-material.owl#EMMO_eb3c61f0_3983_4346_a0c6_e7f6b90a67a8
› http://emmo.info/domains/emmo-material.owl#EMMO_4588526f_8553_4f4d_aa73_a483e88d599b
› http://emmo.info/domains/emmo-properties.owl#EMMO_2a888cdf_ec4a_4ec5_af1c_0343372fc978
› http://emmo.info/domains/emmo-material.owl#EMMO_25f8b804_9a0b_4387_a3e7_b35bce5365ee
› http://emmo.info/domains/emmo-properties.owl#EMMO_251cfb4f_5c75_4778_91ed_6c8395212fd8
› http://emmo.info/domains/emmo-material.owl#EMMO_db03061b_db31_4132_a47a_6a634846578b

Symmetric or transitive object properties?

From running OntOlogy Pitfall skanner! (OOPS!) on http://oops.linkeddata.es/

SUGGESTION: symmetric or transitive object properties.3 cases

The domain and range axioms are equal for each of the following object properties. Could they be symmetric or transitive?
› http://emmo.info/perspectives/emmo-existent.owl#EMMO_b2282816_b7a3_44c6_b2cb_3feff1ceb7fe (has spatial direct part)
› http://emmo.info/perspectives/emmo-existent.owl#EMMO_a50d920d_1ee3_4668_9a73_5d80a1c6fe15 (has spatiotemporal direct part)
› http://emmo.info/base/emmo-mereotopology.owl#EMMO_ec2472ae_cf4a_46a5_8555_1556f5a6c3c5 (emmo relation)

Chemical composition and other "compound physical quantities"

in many cases in physics and materials science we need to relate a quantity to multiple "keys". Having a data structure supported for this in the ontology like in #27 may lead to overuse and to "injection" of EAV data paradigms with lower semantic power than is presented in EMMO.
here another solution is proposed that alleviates the need for arbitrary keys in data structures. As an example we consider the chemical composition: "$Al 40 %, O 60 %" of some crystal.

here obviously one needs to specify an element, and a corresponding physical quantity (the mass %). instead of defining a map with arbitrary strings, like "Al" --> value "40 %" we can and "O" --> "60 %", we can define that

chemical composition is a physical quantity that has in addition to number and unit an IUPAC chemical element (or molecule).

then the chemical composition of an alloy can simply have properties of all chemical composition instances, without the need for explicit keys.

Naming convension for domain ontologies

Currently the EMMO domain ontologies hosted on github are prefixed with "domain-". Is this really nessesary?

Discuss and document what we agree on in the governance document.

Graphic is not a property: separating symbols and property (a sign according to semiotic)

In current EMMO a property appears both under (subclass of) symbol and sign. Property under sign makes sense in a semiotic way, i.e., it is related to something that in fact is related to an object (which is related to a physical). "Property " under symbol is an arbitrary graphical (think of a blob of ink or the alphabet on your keyboard). The graphical is not necessary a sign, and hence not a property always.

** solution proposed by @emanueleghedini (please correct if wrong of course). **
remove property under graphical and define instead a "property_representation" or "property_symbol" that stands for a property (sign) in a mathematical model.

property under sign should be one that can be represented by mathematical symbols that stand for property (the property_symbols..)

Add a toplevel workflow representation

emmo-units

The branch emmo-units adds base units to emmo. It adds domains/emmo-units.owl which includes:

physical quantity subclasses:
- base quantity (with the 7 base SI quantities as subclasses)
- derived quantity
- dimensionless quantity (with solid and plane angle as subclasses)
measurement unit subclasses:
- base unit (with the 7 SI base units as individuals)
- derived unit
- dimensionless unit (with subclass prefix unit and the 20 SI unit prefixes as individuals)
new object properties:
- has_physical_dimension (+ 3 subrelations) allowing to relate derived quantities to base quantities (e.g. velocity is length/time)
- is_unit_for relating unit individuals to their corresponding physical property
new data properties:
- has_symbol for relating unit individuals to their standard (SI) symbol
- has_unit_conversion (+ 2 subrelations) for unit conversions

Add uncertainty

BaseUnit has too many specific units

I agree we need to standardise on SI units, however, we not make it more explicit and open and consistent as follows:

The BaseUnit class, has subclasses: ElectricUnit, LengthUnit, etc.
e.g., LengthUnit will have a subclass BaseLengthUnit which has Metre and other units
alternatively, LengthUnit has a subclass all possible units needed, and the Meter will also inherit from BaseSiUnit, which is another class we need to have.

In this way we eliminate the clutter in the actual quantities having to add possible units in the class definition. For example:

for Area, we simply put

hasUnit Some AreaUnit,

isn't this much more elegant?

@emanueleghedini @jesper-friis your comments please?

thanks.

Rename ContinuousManufacturing

Within manufacturing, the term "continuous manufacturing" is normally used for a manufacturing process that is continuous in time as opposed to manufacturing in batches. This is not the same as 'ContinuousManufacturing' in EMMO, which is currently used for a manufacturing process whose product is the result of the combination of more substances.

Is it possible to find another term for this that will be understod correctly within the manufacturing domain?

Reasoning with Protégé/HermiT fails

Please indicate how to create inferences with this ontology. Thanks,

Readd annotation superproperties to inferred ontology

When exporting the inferred ontology from Protege, all superproperties of annotations are stripped off. This seems to be a bug in Protege, but might also be a result of that OWL-DL does not support annotation superproperties. Nevertheless, we want the superproperties back in the inferred ontology.

Create a script that adds the annotation superproperties back to the inferred ontology.

Use a single namespace for EMMO top and middle

The reason that EMMO is divided into several modules is to organise the ontology into topical related concepts, not impose namespaces.

All names and skos:prefLabels are required to be unique within EMMO top and middle. Hence, there are no need for namespacing within EMMO top and middle. As suggested by Matthias, using a single namespace will make it simpler to move entities between modules and thereby simplify maintainance.

If we go for this, remember to document it in the governance document.

Real hasSymbolData exactly 1 xsd:string

In the 1.0.0-alpha2 version of emmo a math.Real hasSymbolData exactly 1 xsd:string, because it is a subclass of symbol. I think it should only have numerical data. What do you think?

emmo-repo / emmo Goto Github PK

emmo's Introduction

Elementary Multiperspective Material Ontology (EMMO)

Table of content

About EMMO

Some words about the new name and logo

Use of EMMO in domain ontologies

EMMO in a Nutshell

Top Level

Middle Level

EMMO relations

Repository Description

How To Use It

Pre-inferred ontology and documentation

Contacts:

Acknowledgement

emmo's People

Contributors

Stargazers

Watchers

Forkers

emmo's Issues

Classes

Relations

Proposal:

maybe related to #27

Recommend Projects

Recommend Topics

Recommend Org