How to map a specific version for "semanticEquivalent"?

[UlrikeS91]

I'm working on the mapping of schema.org vocab to openMINDS vocab. There are many different versions for the model, I'm comparing their latest version (v28.0) at the moment. Therefore, we should have the version in the mapping somehow.

If they were to change any properties or types in the future, this specific version mapping would remain accurate.

What do you think?

[lzehl]

There should be one type with version information so the mapping is always type to schema.org and the version should be irrelevant for this mapping from our side. The other way around: the resolvable namespace from schema.org always resolves to the latest version (as far as I know). Therefore I would ignore for now the version. Alternatively we get rid of the semantic equivalent completely and just design directly converters... @openMetadataInitiative/openminds-developers please provide your input here.

[lzehl]

related to #33

[UlrikeS91]

I'm leaning towards removing the 'semanticEquivalent' completely.

I've started the work of mapping this for schema.org and, as we already discussed, came across a few issues. Shortly summarized, a single property as we envisioned will be highly inaccurate and raises the question of how useful will this be. The other way around, we would have to increase the complexity and add additional properties to make this mapping more accurate and useful. Then the question is, how much work do we want to put into this? And at which point do we use too much time? Time that could be used to make a full mapping to design a converter.
This mapping would be a great starting point for anybody interested in creating a converter, but I do not want to provide partly inaccurate content (e.g., mapping schema.org's 'amount' to our 'amount' which is semantically the same, but schema.org defines it very differently). Unless we find a good solution for this problem that is not too time consuming, I do not think we should do this kind of mapping at all.

[lzehl]

@UlrikeS91 let's bring this up again in the next dev meeting. I also tend towards removing the semanticEquivalent from the vocab and only keeping track within the vocab of our version mapping (which is difficult enough).

[Raphael-Gazzotti]

I completely agree. Including this in our vocab files seems unnecessary since it won't be utilized by external sources. However, maintaining a mapping within the OpenMINDS schemas is highly valuable and relevant.

[lzehl]

@openMetadataInitiative/openminds-developers common decision is to kill the semantic equivalent from vocab and move this effort to the mappings for the converters.

For mapping in converters look again at other efforts:
RDF mapping language
FAIR impact project (part of EOSC)
similarity ontology
SKOS

[lzehl]

TODO: PR for removing "semanticEquivalent" from vocab