EMMO extensions: ontology packages with coincident ontology namespaces #593
Labels
pico
Issue affecting the PICO ontology installer.
📜 ontology
💬 discussion
The idea is not mature enough to result in an implementation, and needs further discussion.
Thanks to @JoanaFMorgado, I realized that users of the EMMO ontology are working with "emmo extensions". To understand what this means, look at the following two sample ontology packages.
Package
test
test.yml
test.owl
Package
another_test
another_test.yml
another_test.owl
The ontology package
test
contains the namespaceemmo
. The ontology packageanother_test
contains the namespacesemmo
andanother_test
. Note that among the two packages, there are three classes in total. Two of them are in different packages but labeled the same (this is not a mistake, it is what the user intends to do), and the remaining one belongs toanother_test
.The problem is that all the classes in the ontology files belong to the namespace
<http://emmo.info/emmo>
, and as said, there are two classes with the same label. Therefore, when the user refers to "labeled_thing", there is ambiguity and the following happens.This is good, and guarantees that the user won't be referring to the wrong ontology class. This exception was implemented in pull request #584. An error is also raised when a single ontology package containing two classes with the same label is installed. However, this behavior at installation time is not implemented for the "emmo extensions" case (the example), that is, when the two classes have the same label but are contained in different files. In my opinion, the behavior should also be extended to that case.
@emanueleghedini @JoanaFMorgado This issue is relevant for you, as it relates to the question of whether classes in "emmo extensions" should use the emmo namespace or a different one. If they all use the same namespace, in order to remove this ambiguity, the user would have to uninstall all extensions with conflicting labels except for the one they actually want to use . Another option is to use
get_from_iri(IRI)
as stated in the exception, but with the emmo IRIs this is very cumbersome.The text was updated successfully, but these errors were encountered: