Ability to "Release" new versions of an ontology
rduerr opened this issue · comments
In order to act as a working testbed for an ontology, the ontology repository must include the concept of released versions of ontologies and working versions where the advertised and stable URL's point to the lastest release not the latest working copy.
In order to act as a working testbed for an ontology, the ontology repository must include the concept of released versions of ontologies and working versions where the advertised and stable URL's point to the lastest release not the latest working copy.
I suspect this is a no-go, though maybe you have an example of this in practice in an ontology repository (or I have misunderstood the request). Do you have a detailed use case for it, showing how the not-yet-production ontology would be tested, accessed, or otherwise used?
(Above was the TLDR; version of this post...)
This is the first time I've ever seen this particular requirement, though I've desired it. Some years back, I couldn't get anyone on ontolog to agree there was a need to keep track of versions at all -- there was only the current version, and that was everything. Part of the reason for this model, I inferred, is that the construction of inferred triples (reasoning) was expensive, and only likely to be performed across a single version of each ontology in the repository or collection. So putting in a "working version" to test it generally wasn't done -- it had the potential to break reasoning and other services of the repository in unpleasant ways. (Arguably because the repositories never satisfied the 'working version' requirement in the first place, of course.)
A standard practice in the (2) repositories I know of is that the latest ontology is deemed the most current release. Aside from matching the historically expected behavior (the latest release was the only used release), I assume the thinking is that if an ontology is in development and not ready for release, it just won't be stored in the repository in a way that supersedes previous releases (but could be manually stored in some alternate location of course).
(Granted that git for example has nice models for branching and the like, such that you can define your "released version" of your artifact. But I don't think there is a standard, in GitHub or in other git repositories, of which branch is the released branch (though master is of course a favorite). Such definitions are left up to the user. So, I think many ontologies managed with git have a publication workflow to put the released ontology in a standard place.)
I can imagine modifying BioPortal or COR so that a flag would indicate that the latest submission is not to be treated as the released version. (In fact, BioPortal will do this if the submission can't be parsed -- you can download it, but it isn't used in the system.) But what good will such a flag do you? The article under test will not be used for the core functions of the repository, including for reasoning and for returning values at the standard URL. So you can't really test much.
Very interested to see where this might lead us.
John
On Aug 4, 2016, at 5:23 PM, rduerr <notifications@github.commailto:notifications@github.com> wrote:
In order to act as a working testbed for an ontology, the ontology repository must include the concept of released versions of ontologies and working versions where the advertised and stable URL's point to the lastest release not the latest working copy.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/5, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABNU0LcHXeGjR6OTlwOF2vwabVKWXfjlks5qcoJrgaJpZM4JdP2j.
Hi John,
This use case actually is one derived from another issue in github authored by Sky and your points are exactly why I brought it up…
Ruth
On Aug 4, 2016, at 10:36 PM, John Graybeal notifications@github.com wrote:
In order to act as a working testbed for an ontology, the ontology repository must include the concept of released versions of ontologies and working versions where the advertised and stable URL's point to the lastest release not the latest working copy.
I suspect this is a no-go, though maybe you have an example of this in practice in an ontology repository (or I have misunderstood the request). Do you have a detailed use case for it, showing how the not-yet-production ontology would be tested, accessed, or otherwise used?
(Above was the TLDR; version of this post...)
This is the first time I've ever seen this particular requirement, though I've desired it. Some years back, I couldn't get anyone on ontolog to agree there was a need to keep track of versions at all -- there was only the current version, and that was everything. Part of the reason for this model, I inferred, is that the construction of inferred triples (reasoning) was expensive, and only likely to be performed across a single version of each ontology in the repository or collection. So putting in a "working version" to test it generally wasn't done -- it had the potential to break reasoning and other services of the repository in unpleasant ways. (Arguably because the repositories never satisfied the 'working version' requirement in the first place, of course.)
A standard practice in the (2) repositories I know of is that the latest ontology is deemed the most current release. Aside from matching the historically expected behavior (the latest release was the only used release), I assume the thinking is that if an ontology is in development and not ready for release, it just won't be stored in the repository in a way that supersedes previous releases (but could be manually stored in some alternate location of course).
(Granted that git for example has nice models for branching and the like, such that you can define your "released version" of your artifact. But I don't think there is a standard, in GitHub or in other git repositories, of which branch is the released branch (though master is of course a favorite). Such definitions are left up to the user. So, I think many ontologies managed with git have a publication workflow to put the released ontology in a standard place.)
I can imagine modifying BioPortal or COR so that a flag would indicate that the latest submission is not to be treated as the released version. (In fact, BioPortal will do this if the submission can't be parsed -- you can download it, but it isn't used in the system.) But what good will such a flag do you? The article under test will not be used for the core functions of the repository, including for reasoning and for returning values at the standard URL. So you can't really test much.
Very interested to see where this might lead us.
John
On Aug 4, 2016, at 5:23 PM, rduerr <notifications@github.commailto:notifications@github.com> wrote:
In order to act as a working testbed for an ontology, the ontology repository must include the concept of released versions of ontologies and working versions where the advertised and stable URL's point to the lastest release not the latest working copy.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/5, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABNU0LcHXeGjR6OTlwOF2vwabVKWXfjlks5qcoJrgaJpZM4JdP2j.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #5 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABeSvHjbdA155MZhAd-d8nJ2Y9mmWZm0ks5qcr3pgaJpZM4JdP2j.
