Shifting all of OCL to default to "latest released" instead of "HEAD"

This sneaky ticket got us started down the path of finally removing HEAD and unreleased repo versions from global search and shifting the behavior throughout OCL:

This shift in behavior will have far reaching impact across OCL, so we have new dev branches (GitHub - OpenConceptLab/oclapi2 at dev and GitHub - OpenConceptLab/oclweb2 at dev) that are deployed on the OCL dev instance where you can start to play with it:

We’ll use this post to start documenting all of the touch points in the API and TermBrowser where users will be impacted by the behavior change and workflow/feature changes that are required.

This behavior change includes:

  • Global search only searches latest released repos by default, and never HEAD
    • We may eventually want users to be able to optionally search all released versions of a repo in global search (but not sure?)
  • Moving OCL away from exposing concept/mapping versions – resources should always be paired with a repo version
  • Processing of references will be impacted by these changes, so we may have to offer organization administrators more control over how references are resolved to repo versions at the org/user level (we expect to do this eventually, and we may have to do it for this)

latest is just a magical thing for FHIR IG Publisher integration. I’ve been using it for a couple of months, and I’m delighted.

1 Like

@italomacedo I’d love to learn about your integration of OCL with the FHIR IG publisher!

On the OCL architecture call today, we identified a few big buckets of work (we’ll definitely be adding more buckets):

  • Navigation in the TermBrowser
    • Clicking on a search result and links in the resource details panel – these are inconsistent in terms of whether they take you to a concept in a repo version, straight to a resource version, to HEAD, etc.
    • latest keyword is not currently understood in the TermBrowser (that is API behavior only)
    • When does the browser take someone to HEAD?
  • Concept/mapping version_url attributes
    • Every resource version has a resource_version_url attribute that is not aware of the repo_version
    • When retrieving a concept from a specific repo_version, the response needs to be repo_version aware – should this impact the resource_version_url or do we need a new attribute?
    • Gets tricky for interim resource versions and for a resource that is in multiple repo versions
  • Evaluation of references
  • Repo Version management