Re: [protege-user] Merging Imported Ontologies

Thanks Igor.

On Fri, Feb 14, 2025 at 2:46 PM Igor Toujilov via protege-user <
[email protected]> wrote:

> 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