Best Practices for Managing Multiple Ontology Versions and Archive Collections

[bostoM]

Hello everyone,

I'm seeking advice on the best practices for managing multiple versions of ontologies within EDG. Specifically, I have two main questions:

1. What are the recommended strategies for handling and maintaining different versions of each ontology to ensure consistency and traceability?

2. Is it possible (and advisable) to maintain an archive or collection of old versions of ontologies? If so, what are the best practices for setting up and managing such an archive to ensure easy access and reference?
   
   

Thank you in advance for your help!

[David Price]

On 22 Jul 2024, at 09:42, bostoM <tayeb....@gmail.com> wrote:

Hello everyone,

I'm seeking advice on the best practices for managing multiple versions of ontologies within EDG. Specifically, I have two main questions:

1. What are the recommended strategies for handling and maintaining different versions of each ontology to ensure consistency and traceability?

First, I assume by “maintaining different versions” you mean “releasing managed, identify-able updates of an ontology into an operational environment”.

Versioning of ontologies, whether in EDG or not, does not really have a single industry-accepted “best practice”. It depends on the requirements of your organization.

For example, highly regulated organizations may always require specific versions of ontologies to be used at precise times - e.g. "product data X" was built using ontology O1 graph with version 1.2.2 in the URI.

However, others may want the latest-and-greatest at all times while just keeping an archive of the older versions around for rollback in case of failure - e.g. all product data is created using an unversioned URI for the ontology graph with the ontology contents being “replaced” at intervals.

The one EDG distinction is that the EDG URI and the External Graph URI can be different (see under Setting tab), and the EDG id must be unique within an EDG server. When using versioned URIs, simply cloning the ontology and updating the EDG and external graph Id is one possible way. 

Note that using versioned URIs means that every using ontology or data graph must also be changed when releasing a new version. Please must be in place to address that.

2. Is it possible (and advisable) to maintain an archive or collection of old versions of ontologies? If so, what are the best practices for setting up and managing such an archive to ensure easy access and reference?
   
   

Of course it’s possible and, as mentioned in 1, may be required (e.g. for audit purposes).

The only real recommendation I would make is that you write down your requirements in detail. e.g. Why do you need different versions of each ontology? Do you need to keep them forever? Are they always upwardly compatible, and if not what data migration issues does that raise? Why would anyone need to review or use an older version of the same ontology?  Orgs often use their software version control system to manage “old” releases of ontologies (exported using Sorted Turtle option) to keep old, but not used in EDG releases of ontologies. That works for unversioned URIs too using tags/releases/etc in the software version control system.

Then, once your requirements are clearly understood and agreed by your stakeholders, you can decide on a strategy and determine processes/tools used that satisfies those requirements.

I know that’s not an answer, but the question as posed does not have a definitive answer.

Cheers,

David

Thank you in advance for your help!

--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to topbrai...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/997a7c2e-4f6a-4291-91a7-b542a65d6b55n%40googlegroups.com.