Life cycle customization

Life Cycle

As described in the Principles and concepts section, the visibility and behaviour of registered entries is governed by a status value. These status values are declared as SKOS concepts arranged in a hierarchy. The set of legal transitions from one status value to another comprises a life cycle.

A set of core status values is built into the system operation. However, additional status values can be defined along with life cycle transitions between them.

The built in status values are:

URI	Label	Description	ISO 19135:2005 Standard
reg:statusSubmitted	submitted	Awaiting acceptance. New entries have this status by default.	submitted
reg:statusReserved	reserved	A reserved entry, same semantics as reg:statusSubmitted
reg:statusInvalid	invalid	Rejected and should no longer be considered part of the registry.	invalid
reg:statusExperimental	experimental	Currently in use but not fully reliable.
reg:statusStable	stable	Currently in use and reliable.
reg:statusSuperseded	superseded	An entry which has been replaced by another.	superseded
reg:statusRetired	retired	A historical entry.	retired

Status Hierarchy

The status hierarchy determines the groupings to which each status in the life cycle belongs. Group membership is equivalent to the skos:broader relationship in the concept hierarchy.

The built in groupings in the status concept hierarchy are:

URI	Label	Description	ISO 19135:2005 Standard
reg:statusNotAccepted	notaccepted	For internal or administrator use only.	notValid
reg:statusAccepted	accepted	Currently or historically in use.
reg:statusValid	valid	Currently in use.	valid
reg:statusDeprecated	deprecated	An entry which is no longer in use.

The built-in hierarchy is represented by this tree structure, where the leaves are status values:

reg:statusNotAccepted
├── reg:statusSubmitted
├── reg:statusReserved
└── reg:statusInvalid
reg:statusAccepted
├── reg:statusValid
|   ├── reg:statusExperimental
|   └── reg:statusStable
└── reg:statusDeprecated    
    ├── reg:statusSuperseded
    └── reg:statusRetired

The registry API uses the hierarchy to support filtering register items by a range of statuses. For example, to find only register items with a superseded or retired status, you can apply a filter of status=deprecated.

All of the default life cycle statuses belong to this hierarchy. You can add your custom status values to these groupings, or define custom status groupings which extend the hierarchy. Usually, every status in the life cycle should be (transitive) members of the default hierarchy.

Note

Although it is possible to customise the hierarchy by adding new members and sub-groupings, altering the relationships between the default groupings is not recommended as some registry behaviour depends on them.

Default Life Cycle

The registry implements a standard set of status transitions if no customisations have been configured. The transitions are represented by this diagram:

As such, it is possible accept a submitted item into either experimental or stable status, however it is not necessary to go through an experimental phase before marking something as stable. It is possible to retire or supersede an entry with either experimental or stable status.

The vertical black lines represent the skos:broader relationship. Both experimental and stable are specializations of valid, so entries with these states will be shown as valid entries within the register listings.

In addition to the transitions above, you can change the status of registry items from any status (including custom status values) to reg:statusInvalid at any point in the life cycle. This is equivalent to deleting or archiving the entry.

Custom Life Cycles

To define a custom life cycle, create and populate the system register /system/lifecycle with reg:Status instances which define the statuses in your life cycle. While this register exists, the default status transitions will be ignored and replaced by your custom ones.

The statuses will be items in a register like any other, and their RDF properties will define their behaviour. Similarly to other registry items, they must have a rdf:type and a label. The RDF properties related to life cycle customisation are:

Property	Description	Cardinality
skos:broader	The grouping that the status belongs to in the hierarchy.	0..1
reg:priorState	A predecessor to the status in the life cycle.	0..
reg:nextState	A successor to the status in the life cycle.	0..
rdfs:label	The uniquely identifying label for the status. Displayed in UI status elements.	1
skos:prefLabel	Alternative to rdfs:label	1
reg:presentation	The presentation style to apply to the status in the UI.	0..1

When defining transitions between statuses, you can use nextState, priorState or both. The values of these properties can be the (resource) URI or (string) label of another status.

Your custom status values can reference the default status values as their reg:nextState and reg:priorState. This may be useful when migrating from the default life cycle to a custom one, as existing entries in the registry will retain their old statuses.

Since new registry entries will still be created with submitted status by default, you must always define transitions from submitted to other values in your life cycle. You should do this by adding a reg:priorState relationship with a value of reg:statusSubmitted.

The reg:presentation value is optional and is a hint to the user interface on how to present such values. In the default user interface templates provided by registry-config-base they correspond to bootstrap label classes. In that case the legal values of reg:presentation are default, warning, success and danger.

Example

<validation>
        a                 reg:Status ;
        rdfs:label        "validation" ;
        reg:nextState     "preoperational" ;
        reg:presentation  "warning" ;
        reg:priorState    reg:statusSubmitted ;
        skos:broader      reg:statusAccepted .

Extending the default life cycle

You may want to incorporate some or all of the default status values into your life cycle. If you only want to be able to change the status of entries from or to a default status, you can simply reference them in the reg:priorState or reg:nextState relationships as described above. However, if you want to restore the transitions between default statuses (for example experimental to stable) you must define those statuses as entries in your life cycle register.

You can define a default status as an external resource in your life cycle register. The turtle definitions for those statuses are here. Modify or omit any of the statuses in the file, then import the new definitions into your life cycle register alongside your custom statuses. You should not change any properties other than priorState, nextState and presentation.