Don't use too many namespaces

[VladimirAlexiev]

281 shows several namespaces: epo, ecat, epo-ecat, epo-eorder.

Please mind that every new namespace makes it slightly harder for the user of the ontology. I think even the authors may have gotten confused: ecat:eCatalogue but epo-ecat:eCatalogueLine?

Multiple namespaces are justified only for very large ontologies like FIBO that has over 500 modules, each in a separate namespace. For smaller ontologies (up to 1k classes and props), it's a lot more convenient to use a single namespace.

Please note that modularization (breaking the ontology into files, with a well-layered import dependency hierarchy) is orthogonal to namespaces. There's no need to use a separate namespace for each module.

Using a single namespace makes it a lot more likely that ontology term URLs will remain permanent, even in face of module refactoring.

[giorgialodi]

We noticed already some confusion in the names of the modules (during the definition of the UML diagrams) and this will be fixed once the modules will be stabilized. We will think about this suggestion even if I do not see so much issues if I use a different namespace for a different module, whose lifecycle is potentially treated apart from the main ontology (epo). The module has its own classes and props and it will typically import the main ontology epo and that's it, as far as we have seen so far.

[VladimirAlexiev]

"Distinct lifecycle" justifies the creation of multiple modules, but it doesn't require "distinct namespaces". Keeping all terms in the same namespace improves the chance term URLs will remain permanent.

The only benefit of "distinct namespaces" is if you expect conflicts in term names, i.e. the same local name to be used in different namespaces with different meaning. But I can't see such danger.

[guascce]

This will be discussed further when those sub domains will be further analysed.