Description
The current version of the CPSV-AP specification does not have a way to register the statuses that a public service can go through when executed. It uses ADMS status to describe the status of a public service in the context of public service portfolio management and lifecycle management.
Proposed solution
We propose to add a new property to the model which allows to document the different statuses a public service can go through when executed. The focus would be on the statuses communicated towards the user of a public service, but can however be generically defined to cover any status a public service can go through. In order to make a clear difference with the status property already included, we propose to label it as "executionStatus".
Comments
The WG agreed on the proposed solution during the webinar held on the 12th of May. The changes will be addressed in the new draft version of the CPSV-AP.
Comment made by Dieter De Paeper through the mailing list:
I would have expected the Execution status field to be a list of codes (Concepts) rather than text. This would make more sense for cases where statuses are translated. E.g.: "Unavailable"@en and "Onbeschikbaar"@nl are in fact the same status.
In addition, please clarify if this term applies to the status of the service, or the status of instances of the service. I suspect the latter from the current definition.
Michiel De Keyzer's reply to Dieter's comment through the mailing list:
Indeed this can be a list of codes, however it is not the idea to predefine them in the context of CPSV-AP. The idea of this is to enable the capturing of the possible statuses a service can go through when excecuted/requested/consumed, when describing the public service. This said, it is indeed in line with the second option you described in your e-mail, enabling to describe the different statuses a public service can go through when instantiated.
Reply from Dieter through the mailing list:
I agree predefining statuses should not happen in CPSV-AP, just wanted to point out that skos:Concepts are better suited for that than Literals.
Comment made by Nicola Guarino through the mailing list:
The discussion about ExecutionStatus raises again a crucial semantic issue that needs to be clarified: the relationship between services and their “instances”. Both Dieter and Michiel agree that the term “execution status” refers to the status in which a single instance of a particular service can be, at a given time. Dieter clarifies that the attribute is actually intended to describe the list of possible statuses, so that I imagine that a particualr service may be described by the list [requested, under-execution, executed] and another one by the list [requested, accepted, rejected, under-execution, suspended, executed]. If so, the attribute name should perhaps be changed in ExecutionStatuses (plural form).Anyway, what is the instance of a particular service?
Usually, the term “instance” is used to talk of instances of a class. But a particular service is not a class! It seems to me that, again, we run into the problem of distinguishing two notions of service:
A - service as a single provision
B - service as the collection of all activities concerning multiple provisions of a particular service offering
Note that A is a part of B, but not an instance of B. Not also that both A and B can have their own statuses, but they are very different: for example, B can have the statuses [available, unavailable], but these statuses make litlle sense for A.
Proposed change: Rename the "ExecutionStatus" property by "ExecutionStatuses" and change its range to skos:Concept. The changes will be reflected in the next draft of the CPSV-AP v2.1.