Re: [protege-user] Merging Imported Ontologies

Hi Jean-Louis,

Git is a leading system for version control. It is widespread and its supporting software is open source. There are numerous resources in the Internet for Git documentation, for example, https://en.wikipedia.org/wiki/Git .

There are various providers of Git services in the Internet. The biggest and most prominent one is GitHub. But there are others as well, like SourceForge.

A usual scenario of using Git is the following. Create your account at GitHub (it's free), login and create a new repository for your project. This will create the repository in the cloud. You can choose whether the repository will be public or private. Public repositories are readable by anyone and free. Private repositories are accessible by you only, but you will need paying some subscription fee.

"Clone" (Git terminology) the repository from the cloud to your computer where you can change the content in the repository and "push" (Git terminology) the changes back to the cloud.

You can collaborate with others working on your repository. For example, grant Mr Z a permission to write to your repository. But, when many people work at the same time on the same repository, content change synchronisation conflicts are quite likely. In this case, to minimise the conflicts, it's recommended to use branching. So, in your repository, create a new branch, let us call it Spanish, and ask Mr Z to work on this branch. After he pushes some new content to the repository, you can "pull" (Git terminology) it from the cloud to your computer.

Cheers,

Igor

Sent: Saturday, February 15, 2025 at 9:05 AM

From: "Jean-Louis Janin" <[email protected]>

To: [email protected], "TOUJILOV Igor (Protege-user)" <[email protected]>

Cc: "JONQUET Clément (LIRMM)" <[email protected]>

Subject: Re: [protege-user] Merging Imported Ontologies

Hello Igor,

Thanks a lot for what seems to me a sound advice. Could you be more explicit about "Git" as a modern tool for version control. I have this problem when I want to developp a multilingual version of LEXEAU, for example adding Spanish to the actual bilingual version ( French and English ), stored on its ontology repository under my administration, aiming at the edition of a Spanish and French Water lexicon on the web out of the revised LEXEAU version in three languages, with a specific software.

What should be the scenario of LEXEAU updating after some translation in Spanish proposed by Mr Z, in Madrid, completing locally the actual version of LEXEAU downloaded from its repository ? What do you mean by "a clone of a Git repository" ? Would you have some bibliography available ?

Regards,

Jean-Louis Janin

Le 14/02/2025 à 23:46, Igor Toujilov via protege-user a écrit :

Hi All,

I want to suggest my solution as a software engineer. I mainly agree with Hyacinth's opinion (with few exceptions).

First of all, I strongly encourage considering the ontology development as a software engineering activity which had already provided commonly accepted industrial solutions and tools for the change management, merging, version tracking, etc. decades ago. If you really want to develop ontologies in a professional way, think of ontologies as software products. And for doing so, you need to look at modern tools for version control, mostly Git.

Well developed ontologies have a modular structure like programming modules. OWL has the import mechanism for managing the modules. Do not ignore this mechanism.

Protege has ontology merge functionality. But do not use it as a replacement of the import mechanism. I use the merge functionality from time to time when I need a temporary snapshot of a combined ontology. For example, Stardog does not support the OWL import directive. So, I sometimes, very infrequently, use the merge to load my ontology to Stardog.

Create a directory under Git control and put there all your ontologies and imported ones for your project.

Do not import ontologies from URLs in your production environment, as this will jeopardise stability. Always import ontologies from a clone of a Git repository.

Regards,

Igor

Sent: Thursday, February 13, 2025 at 8:17 PM

From: "Michael DeBellis" <[email protected]>

To: "User support for WebProtege and Protege Desktop" <[email protected]>

Subject: Re: [protege-user] Merging Imported Ontologies

By the way, In case the updates are not always wanted, what I usually do is placing the main ontology file and the ontologies which are to be imported in a single folder and doing local imports. In this case, Protégé usually addresses the local files using relative paths...

Thanks, that's the kind of practical ideas I was looking for.

On Thu, Feb 13, 2025 at 11:20 AM Hyacinth <[email protected] > wrote:

Well I'm not sure I'm understanding your point yet, but since merging a specific version of an imported ontology with your own ontology will stick the data from that specific version to your own ontology, and considering that the discussion (as far as I understood) is about the case in which the changes in the imported ontologies do matter and therefore import statement is not removed, if the imported ontology gets updated, then the newer version will be loaded from the web while the older version is locally loaded too, possibly causing conflicts. It doesn't seem a sensible approach at least to me.

And if the ontologies are merged and the import statement is removed, then there is no loading of data from outside the current file, and the ontology is effectively offline and not updated which is seemingly not wanted here.

By the way, In case the updates are not always wanted, what I usually do is placing the main ontology file and the ontologies which are to be imported in a single folder and doing local imports. In this case, Protégé usually addresses the local files using relative paths so that if I move the whole folder containing all of the ontologies (and the catalog file containing the mapping of ontology IRIs to local paths) to another location or share it with another person, the paths won't be broken. And any time I want to see the updates to the imported ontologies, I temporarily move the catalog file to another place or simply rename it, so that all the imported ontologies will be loaded from the web and if I want to go offline again, I take the catalog file back to it's for
mer state. Anyway I'm not properly understanding the purpose of merging, actually.

On Thu, Feb 13, 2025 at 7:21 PM Michael DeBellis <[email protected] > wrote:

Why not saving an offline version (as .ttl file(s), say) of the ontology (or each of the ontologies) you want to import, and then importing the files locally into your ontology (rather than importing them from the web)? This way, if the imported ontology gets updated, the changes won't be applied unless you manually update the saved version on your local system. So you can update the imported ontology(s) at your will, but things won't get out of hand if sudden dramatic changes happen to the imported ontology.

That's what I do now and it's always worked for me, because usually what I care about is an application (which is built on an ontology) so issues about staying consistent with the imported ontologies never mattered much. I just use them and then I don't care if they change in the future because it won't affect the system, and that's usually what I care about. Also, usually when I import ontologies like SKOS or Prov, I don't use the entire ontology anyway so even more reason, I'm not that concerned about future evolutions. The difference is this time I'm helping someone who doesn't want to build an application but a new reusable vocabulary that imports several other vocabularies. So I thought it might make sense to be a big more rigorous and thoughtf
ul about imports and to see if anyone had any suggestions, if there were issues I wasn't thinking about, etc.

On Thu, Feb 13, 2025 at 3:54 AM Hyacinth <[email protected] > wrote:

Greetings

Why not saving an offline version (as .ttl file(s), say) of the ontology (or each of the ontologies) you want to import, and then importing the files locally into your ontology (rather than importing them from the web)? This way, if the imported ontology gets updated, the changes won't be applied unless you manually update the saved version on your local system. So you can update the imported ontology(s) at your will, but things won't get out of hand if sudden dramatic changes happen to the imported ontology.

I remember to have experienced some bugs in using local imports in the past, though not remembering exactly what the problem was and not sure whether it still exists.

On Thu, Feb 13, 2025 at 3:44 AM Michael DeBellis <[email protected] > wrote:

I was helping someone start a new research project today where she is going to start by leveraging several diverse vocabularies from different domains. I showed her how to import an ontology.

When I do this, I typically merge the ontologies because in the past I've had issues with imported ontologies. In the worst case, I often download things like Prov to my local drive and then import that way. Of course that leads to problems if I share the ontology because that path won't exist on someone else's machine. So one bit of advice I gave my colleague was to not do that and import from the URL rather than their local drive.

But I'm wondering should one still merge the ontologies in this situation or not? After I do the Merge I usually delete the ontology import that shows up at the bottom of the Active Ontology tab. That way there won't be any issues with loading an ontology and not being able to load it because a server for an imported ontology is down. On the other hand, it seems that to have an audit trail, it is better to leave those import statements. I think (although I haven't tested this) if you do the merge and an imported (and merged) ontology isn't available it won't matter because you can just say skip finding that import and the entities will still be there.

A related issue is what if an imported ontology changes? Not merging and having the Import statement seems the "right" way to do it because you would get the new version. On the other hand, if you are under a deadline and you suddenly have to deal with a bunch of changes to one of the imported ontologies that could be a pain.

Just wondering what people think are the trade offs here between:

1) Whether or not to merge an imported ontology and

2) Whether or not to delete the import statement if you do merge the imported ontology?

Thanks in advance for any opinions,

Michael

https://www.michaeldebellis.com/blog

_______________________________________________

protege-user mailing list

[email protected]

https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________

protege-user mailing list

[email protected]

https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________

protege-user mailing list

[email protected]

https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________

protege-user mailing list

[email protected]

https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________ protege-user mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________ protege-user mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/protege-user

_______________________________________________
protege-user mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/protege-user