Re: [protege-user] Merging Imported Ontologies
Jean-Louis Janin <[email protected]>
| Newsgroups | gmane.comp.misc.ontology.protege.owl |
|---|---|
| Message-ID | <[email protected]> |
Hi, Thank you for this information. LEXEAU has not been developped as an OBO ontology, but some of OBO's tutorials and guides content may be very useful. Best regards, Jean-Louis Janin Le 15/02/2025 à 15:06, Balhoff, Jim a écrit : > Hi, > > You may be interested in some of the workflows that the OBO Foundry > has developed for ontology builds and releases on GitHub: > https://oboacademy.github.io/obook/ > > There is some especially relevant info under Tutorials and How-to Guides. > > Best regards, > Jim > >> On Feb 15, 2025, at 4:05 AM, Jean-Louis Janin >> <[email protected]> wrote: >> >> 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 former >>> 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 thoughtful 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