Thank's David : 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?
- The concepts within an ontology are "alive," meaning that they can evolve or change over time. Certain concepts may be relevant now, but might become obsolete or replaced in the future. We need versions to capture this dynamic nature of concepts, ensuring that the context in which they were used is preserved. - We build ValueSets based on the ontologies, and it's crucial for us to track which version of an ontology was used to create a specific ValueSet. This ensures consistency and traceability when dealing with clinical or technical data Do you need to keep them forever? Not necessarily all old versions. We usually want to maintain the current (n), the previous (n-1), and the version before that (n-2) . Older versions can be archived but are no longer actively used in the system. Why would anyone need to review or use an older version of the same ontology? Our connected systems and software need to support at least the (n-1) version, as migrations to new versions are not automatic. For example, during the transition to a new version, software may still rely on the previous one until the migration is complete and validated. Therefore, maintaining access to the n-1 version ensures operational continuity. Le lundi 22 juillet 2024 à 13:33:56 UTC+2, David Price a écrit : > > 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 > > <https://groups.google.com/d/msgid/topbraid-users/997a7c2e-4f6a-4291-91a7-b542a65d6b55n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- The topics of this mailing list include TopBraid EDG and related technologies such as SHACL. To post to this group, send email to topbraid-users@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-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/214be5c8-d380-442e-b867-a3649bc6094fn%40googlegroups.com.
