Add datatypes to EMMO about emmo HOT 7 CLOSED

The branch issue27-emmo-datatypes implements the above suggestion

from emmo.

There is an issue with the Dimension as it is described above. Lets say we are creating a domain ontology and want to add the StiffnessTensor as a subclass of Pressure under derived physical quantities. It is a symmetric tensor of rank 4, where each of the 4 dimensions is of size 3. EMMO should provide the means to specify this, but how?

Should we create Dimension individuals for each of the 4 dimensions, each with a size, a name and a next dimension (except for the last one)?

How should we specify that the StiffnessTensor is a symmetric tensor? With a value restriction?

from emmo.

Why not separate rank from it? First an array has a rank, e.g. 4. Then for each of these 4 "orders"/"degrees" we give the dimension?

Individuals make it harder to assign variable dimension names to it a dimension I guess.

from emmo.

thanks @jesper-friis
I am not sure that we need low level data types, this should be implementation specific, my main concern, if I understand correctly is, e.g., with the following :

CompoundItem
A CompoundItem has two spatial parts, 'name' and 'value'. It makes a
connection between the name and the value.

subclassOf Composition (??)
hasName some String (should we use "exact 1" String ??)
hasValue some Value (should we use "exact 1" Value ??)

first: do you mean that we can define a data point like "key" -> value maps with arbitrary "key" set by user on individual level.

If yes, I would strongly recommend to rethink this, as it is introducing a syntactic layer that will enable polluting the ontology with syntactic garbage, as the key is random, unless we limit its use in some way. A better solution is to define specific entities rather than keys. See e.g., https://gitlab.cc-asp.fraunhofer.de/mat-info/ontology/materials-composition which we wold like to port to EMMO after review.

I will make an issue for this here too.

Note: having such a symbolic to describe implementations is actually a good idea, the comment above refers to using this to represent information better represented by the proper ontology entities see #30 for example.

from emmo.

@ahashibon, you have a very good point. The idea behind CompoundValue was to allow the user to be able to describe more complex data. But you are right, arbitrary keys it allows to bypass the semantics, they should be related to EMMO classes.

from emmo.

maybe constraining the keys to EMMO classes of specific types like in SimPhoNY CUDS would be good.
It will allow to bring the CUDS itself into EMMO naturally.

from emmo.

They already are via the restriction hasKey some Item.

from emmo.