CommonCoreOntology / CommonCoreOntologies

The Common Core Ontology Repository holds the current released version of the Common Core Ontology suite.
BSD 3-Clause "New" or "Revised" License
197 stars 58 forks source link

Import Issues when opening from URL in 1.7 and 2.0 #547

Open CarterBeauBenson opened 1 week ago

CarterBeauBenson commented 1 week ago

CCO 1.5 was able to be opened in Protégé using the "raw" file on GitHub because the URLs for the import files resolved at the ontologyrepository.org webpage. This allowed users to view CCO in GitHub without having to clone the repository or download files.

1.7 Issue: This method does not work correctly for 1.7. A user can open 1.7 AllCore.ttl or Agent.ttl and be mislead by the version IRI that they are viewing 1.7 when in reality, they are viewing 1.5. This is because the URLs for the imports still resolve at the ontologyrepository page that has not been updated since 1.5. Note, the only way for a user to view 1.7 using the open from URL feature is to open CommonCoreOntologiesMerged, since there are no in the file.

2.0 Issue: This method does not work at all for 2.0 because the URLs point to commoncoreontologies.org, which is still under construction.

I understand that the preferred method of working with CCO is by cloning the repository. All core works correctly when opened from a local directory because the catalog file is automatically in the correct folder. The local method does not automatically work when trying to open a module. For example when opening the Agent Ontology, the Information Ontology fails to import. This would not be a problem if there was a catalog file for the Agent ontology in the same folder as the Agent Ontology.

That said, I think that there should still be the option for people to open 1.7 and 2.0 via the "open URL" function in Protégé.

Proposal: I suggest keeping Dev and Master Branches the way they are now, with clear instruction that one ought to clone the repository to work with it. In addition, I suggest the creation of a third branch that is intended to be able to be opened using the "open URL" function. This would be achieved by replacing the import URL in each ontology with the resolvable GitHub raw file URL. For example, I suggest a replacement of "https://www.commoncoreontologies.org/ExtendedRelationOntology" in the Imports of the Geospatial ontology with "https://raw.githubusercontent.com/CommonCoreOntology/CommonCoreOntologies/refs/heads/develop/src/cco-modules/ExtendedRelationOntology.ttl". This would allow users to open each file from the Raw.

Once the URLs for ontologies using the commoncoreontologies.org resolve correctly, this branch should be trimmed.

alanruttenberg commented 1 week ago

Why not just make a catalog-v001.xml and put it into the directory with the modules. Then when you open a module the catalog will be consulted and the local version used. I can create that catalog if you don't know how.

alanruttenberg commented 1 week ago

To be clear this will work with a cloned repository, not by putting the URL into Protege.

alanruttenberg commented 1 week ago

If you are going to change an IRI, change the version IRI rather than the ontology IRI

CarterBeauBenson commented 1 week ago
  1. You are correct, you can put a catolog-v001.xml into the folder in order to resolve the issue locally. That is not really the point though. I do not think each user should have to resolve this themself. For example there is a catologv001.xml file in the Merged folder on the GitHub repo that resolves this issue.

  2. Yes. But it only addresses one point.

  3. I do not believe I said anything about changing ontology IRIs, only the location of the ontology that is being pulled in from. For example, if I move an ontology file from a folder and put it on my desktop, I have changed the location path of the file, not the IRI of the ontology. The principle is the same here. It would change the path to the ontology, not the IRI of the ontology. If the point is that changing where an import points to in an owl file is enough to change the version IRI of that file, then I agree with you.

CarterBeauBenson commented 1 week ago

I do not take this "https://raw.githubusercontent.com/CommonCoreOntology/CommonCoreOntologies/refs/heads/develop/src/cco-modules/ExtendedRelationOntology.ttl" to me an ontology IRI. I take it to be a URL that points towards an ontology with this IRI "https://www.commoncoreontologies.org/ExtendedRelationOntology". The IRI and the URL used to be identical, the problem I am pushing at for opening ontologies using the "Open by URL" protégé feature is that they are no longer identical. Furthermore, the URLs for the ontologies in 1.7 point towards 1.5. Once again, this is not a problem if the repository is cloned.

alanruttenberg commented 1 week ago

Not sure what you mean by having each user resolve this by themselves?

The ontology should be accessible from the ontology IRI or version IRI. Spec says:

The ontology document of an ontology O SHOULD be accessible via the IRIs determined by the following rules:

If O does not contain an ontology IRI (and, consequently, it does not contain a version IRI either), then the ontology document of O MAY be accessible via any IRI. If O contains an ontology IRI OI but no version IRI, then the ontology document of O SHOULD be accessible via the IRI OI. If O contains an ontology IRI OI and a version IRI VI, then the ontology document >of O SHOULD be accessible via the IRI VI; furthermore, if O is the current version of the ontology series with the IRI OI, then the ontology document of O SHOULD also be accessible via the IRI OI.

Thus, the document containing the current version of an ontology series with some IRI OI SHOULD be accessible via OI. To access a particular version of OI, one needs to know that version's version IRI VI; the ontology document of the version SHOULD then be accessible via VI.

CarterBeauBenson commented 1 week ago

I am certain that we are talking about different things. I am pointing out two possible problems.

  1. To see the first problem, click here: http://www.ontologyrepository.com/CommonCoreOntologies/Mid/InformationEntityOntology Then Click here: https://www.commoncoreontologies.org/InformationEntityOntology

When you open 1.7 AllCore.ttl on the Master branch using "Open from URL..." in Protégé, it imports 1.5 from http://www.ontologyrepository.com/ When you open 2.0 from the Dev branch using "Open from URL..." in Protégé, it tries to find imports here https://www.commoncoreontologies.org/ which is currently under constructions

  1. The other problem is that if all you do is clone the repository, then try to open any single module locally in Protégé, then it fails to execute its imports. Why does it fail to execute it imports? because every module is missing a catolog-v001.xml file. Of course, I could configure these my self. My point is that a user should not have to do this.
alanruttenberg commented 1 week ago

You are right, I'm confused as to what the desired behavior is and what the problem is. The catalog goes in the repository. It doesn't have absolute paths in is. You click on a module and it opens up. I'm in the develop branch - cco-modules, with the attached catalog. catalog-v001.xml.zip For 1.7 (master branch) a different catalog is used. catalog-v001.xml.zip Finally, the problem with 1.7 seeems to be that your imports aren't importing the version IRI, instead the ontology IRI, with the ontologies at the active ontology IRI being 1.5 Fix 1.7 to import version IRIs and you should be good. And tell people to import a specific version IRI until the new domain is set up.

CarterBeauBenson commented 1 week ago

Leaving what I take to be problem 2 aside for a moment, lets focus on the first issue.

Do you ever open an ontology using the "open from URL" feature on Protégé? If not, I ask you to do an experiment. Please try to open AllCore 2.0 using the "open from URL" feature.

For a second experiment, please locate the Agent Ontology on the CCO Master, which is CCO 1.7. Please open the raw file and find the import of the Information Ontology. You will see owl:imports http://www.ontologyrepository.com/CommonCoreOntologies/Mid/InformationEntityOntology ;

Please copy and paste the IRI of the ontology into your browser.

If you look at the version IRI of the xml file you will see

Version 1.5 Therefore, when someone opens a CCO 1.7 ontology using the "open from URL", the imports are that of 1.5, not 1.7.
alanruttenberg commented 1 week ago

What does it mean to "open a version 1.7 ontology" using the open from URL in protege. Exactly what URL are you using?

CarterBeauBenson commented 1 week ago

https://raw.githubusercontent.com/CommonCoreOntology/CommonCoreOntologies/refs/heads/master/src/cco-modules/AgentOntology.ttl

That URL that is on GitHub that has this version IRI

http://www.ontologyrepository.com/CommonCoreOntologies/Mid/2024-11-03/AgentOntology

and this Base IRI http://www.ontologyrepository.com/CommonCoreOntologies/Mid/AgentOntology

alanruttenberg commented 1 week ago

You still seem to be missing the point that imports for 1.7 should be imported using 1.7 versionIRIs, not plain CCO IRIs.

Kinds of versions:

  1. Open an ontology, import ontology IRIs: Whatever version the team wants to call current. Unstable in that what's current can change and engineering projects that want stability won't usually choose this method.
  2. A specific version. Open it with with a version IRI. It does subsequent imports using the version IRIs. This way guarantees you get the correct version.

I don't know what the redirect rules are at ontologyrepository are but if you want 1.7 to be the current ontology, you need to fix those rules so that the other ontology IRIs return 1.7 versions. OR BETTER, have 1.7 import using the 1.7 versionIRIs (and make sure those resolve)

Particularly during transition times is to use my #2. Even if you do #1 it is still best practice to import using the versionIRIs

CarterBeauBenson commented 1 week ago

Only the Base IRI points to an existing website. That existing website contains 1.5.

alanruttenberg commented 1 week ago

We should probably have a phone conversation, cause we're apparently failing to communicate. I'm going out now but could talk tomorrow. How is the redirect from ontologyrepository to the desired file handled?

CarterBeauBenson commented 1 week ago

http://www.ontologyrepository.com/CommonCoreOntologies/Mid/AgentOntology rdf:type owl:Ontology ; owl:versionIRI http://www.ontologyrepository.com/CommonCoreOntologies/Mid/2024-11-03/AgentOntology ; owl:imports http://www.ontologyrepository.com/CommonCoreOntologies/Mid/InformationEntityOntology ; dcterms:rights "CUBRC Inc., see full license."@en ; dcterms:license "BSD 3-Clause: https://github.com/CommonCoreOntology/CommonCoreOntologies/blob/master/LICENSE"@en ; rdfs:comment "This ontology is designed to represent agents, especially persons and organizations, and their roles."@en ; rdfs:label "Agent Ontology"@en ; owl:versionInfo "Version 1.7"@en .

This is literal code from Agent Ontology 1.7. The import is not a version IRI, it is a base IRI. Am I supposed to manually resolve this when I open the ontology myself? That was not the case before 1.6 was released.

mark-jensen commented 1 week ago

549

avsculley commented 1 week ago

@alanruttenberg A specific issue resulting from the issue @CarterBeauBenson mentions is that the ontology that loads from the All Core raw url from the "Master" branch (https://raw.githubusercontent.com/CommonCoreOntology/CommonCoreOntologies/refs/heads/master/src/cco-merged/AllCoreOntology.ttl), and which is labeled 1.7 in its ontology annotations, still has the 1.5 definitions. Agent, for example, is defined as

"A Material Entity that is capable of performing Planned Acts"@en

The 1.7 definition of Agent is

"A Material Entity that bears an Agent Capability."@en

And this is the case for all definitions loaded from https://raw.githubusercontent.com/CommonCoreOntology/CommonCoreOntologies/refs/heads/master/src/cco-merged/AllCoreOntology.ttl

CarterBeauBenson commented 1 week ago

@alanruttenberg I am free after the P&G for a teams call. I can show you what Alec and I speak of.