capture status

[carueda]

UI counterpart of https://github.com/mmisw/orr-ont/issues/11

[carueda]

The status attribute will be handled in a similar way as with the visibility one. There will be a fixed set of possible values, at least initially.

• In ontology page, include button showing current status and drop-down list with options to change it
• For create vocab/mapping options, no need to include this attribute, at least initially, given the new option above that allows to changed it on any registered ontology
• However, do include it in the Upload sequence (which already has the visibility one)

Note: For now we will handle status similarly as with visibility: as a direct attribute to the ontology version model and not with direct association to any metadata property. In this sense we can explain to the user that if any metadata attribute (in particular for uploaded ontologies) should reflect the intended status, then it's up to them to maintain the correspondence. That is, upon a change in status that should be reflected:

• the user would first create a new version with the relevant metadata property updated; then use the change-status option to reflect the corresponding value for the attribute.

[carueda]

From https://www.w3.org/2003/06/sw-vocab-status/note.html, the following status values will be made available (with "resource" substituted for "term" in the descriptions, plus an additional draft entry):

• draft The resource is in preliminary stages of development.
• unstable The meaning, deployment practices, documentation (or important associated software/services) associated with this resource are liable to change arbitrarily at some point in the future. They may not, but stability is not guaranteed. Use with caution.
• testing The meaning, deployment practices, documentation and general understanding of this resource are approaching some stability, but changes are still possible due to implementation experience or other unanticipated factors.
• stable The resource is relatively stable, and its documentation and meaning are not expected to change substantially.
• archaic This resource is marked as old-fashioned; although used, it is not considered typical of current best practice and alternative expressions may be preferable.

[graybeal]

Much better. Please add also "deprecated: This resource is marked as no longer suitable for use, although past uses may still exist."

[carueda]

I actually had "deprecated" in my initial addition to the list, but then thought that it was so similar to "archaic" . In fact I was thinking about simply changing that key from "archaic" to "deprecated". Please give me your opinion to select one, or some combination of the following:

• if you think there's enough differentiation between them, keep both "archaic" and "deprecated"
• else, keep "archaic" (as already defined, or with your new definition)
• ... or, rename "archaic" to "deprecated"
• ... or?

[carueda]

I'm working on this right now -- will add your "deprecated" option to list in the mean time.

[graybeal]

Thanks Carlos, adding deprecated is the right thing, so, no further action needed. The two are quite distinct, and I think archaic is something that wouldn’t be used much, but is worth having for compatibility.