[BUG] - Built-in ontology is somehow broken when used in submodules

[mprather]

Description

Oml2Owl includes a list of default ontologies. link

In a scenario where you have a vocabulary A that utilizes the following statement

extends http://www.w3.org/2001/XMLSchema# as xsd

Everything works as expected when the project is run through the conversion stask.

However, if vocabulary A is used as a submodule in project B, then Oml2Task doesn't know what to do with xsd definition when project B is built.

The workaround: when A is included as a submodule, delete A's root catalog.xml file.

Steps to Reproduce

Steps to reproduce the behavior:

• Create a simple vocabulary A. It should extend the XMLSchema namespace.
• Verify A can be built as a standalone project.
• Create a new project B that will use A.
• Include A as a submodule
  • update B to use A's vocab file
  • update B's catalog.xml with the correct submodule path info
• Build B

Result:

task ':downloadDependencies'
task ':omlToOwlModels'
  - [task ':downloadDependencies']
task ':owlReasonTestModels'
  - task ':omlToOwlModels'
task ':build'
  - task ':owlReasonTestModels'
> Task :omlToOwlModels FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':omlToOwlModels'.
>
  Diagnosis of Vocabulary http://namespaceA#
        Namespace <http://www.w3.org/2001/XMLSchema#> could not be resolved to a vocabulary

* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':omlToOwlModels'.
        at io.opencaesar.oml2owl.Oml2OwlTask.run(Oml2OwlTask.java:215)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Expected Behavior

Two general expectations:

1. No failure. This is a built-in ontology that should always be available.
2. No adjustments to the submodule's catalog.xml. The workaround requires the deletion of the file, which is artificially changes the state of the submodule.

Additional Context

Here's the general folder structures that have been tested to repro the problem.

As a folder in the root

Project B root
 |-- submodule A
 |-- <standard project folders>

As a folder in src/oml

Project B root
 |-- src
      | -- oml
            |-- submodule A
 |-- <standard project folders>

In both scenarios, once A's catalog file is removed everything works.

[melaasar]

When OML resolves a reference in some ontology, it walks up the folder hierarchy of the ontology looking for a catalog.xml and would work with the nearest catalog.xml. So, in both options above, references in A's ontologies will resolve using A's catalog.xml, while references in B's ontologies will resolve using B's catalog.xml. This would include B's references to A's ontologies or the standard ontologies.

What is the content of your B's catalog.xml? Does B have its own copy of the standard vocabularies in build/oml or is it mapped to those in A's build/oml?

[mprather]

The point that I'm trying to illustrate is that internal/provided-by-caesar namespaces should not be affected by any catalog manipulation. In this case, the error solely resides with the fact that the XMLSchema namespace breaks based on the hierarchy of the catalog files. This should never happen if the namespace is provided by the tooling.

[melaasar]

Currently, although "xsd" is a standard vocabulary, OML resolves it to an ontology file through a catalog just like non-standard ontologies (the core-vocabularies package provide such file). I think what you're asking above is to resolve such standard libraries in a special way (without needing to declare a dependency on core-vocabularies and without needing to use a catalog) like by having them packaged by the OML runtime environment itself, right?

[mprather]

The gist is that if OML provides some definition then the user's folder structure should not matter. Internally OML needs to put whatever elements it says it provides in a location that is independent of the user's folder structure, rather than relying on it.

Our situation where we have project A inside project B, the current behavior requires us to change A in order to be used by B.

If A works as standalone but then you have to axe its catalog to get the "default / built in" namespaces to work when you want it to work with another project, this seems like a clear problem. This really prevents simple project/folder encapsulation. It's currently possible to work around the issue by simply deleting A's catalog but that is a clunky local-dev change (for every dev that wants to use A inside other projects) that has to be constantly ignored (and more frustratingly, not checked in to avoid breaking the standalone case for A).

If OML says something is provided out-of-the-box, then Yes, OML should special case whatever it is providing.

To be clear I am not asking to remove the requirement to define the appropriate namespace and aliases for a project. Project A should define whatever it needs. Same with Project B. The difference is that in the case of the "built in" ontologies, then OML should make sure those ontologies are handled independently so that they will work no matter how the user structures any given project.