In CPSV-AP_IT more detail has been added to capture information on the role an Agent plays in the delivery of a Public Service. The classes that have been added are:
- RoleInTime: association with Agent (playsRoleInTime) and Public Service (roleFor);
- Role: association with RoleInTime (withRole);
However, in a paper submitted by Nicola Guarino, the following is suggested:
With respect to roles, the CPSV-AP_IT has introduced a mechanism for reifying the role-playing relationship, taking into account in this way of the different time spans when a particular role is actually played. While this mechanism may be useful in some cases (e.g., describing the evolution of a particular service in time), I don’t see 7how it is justified while describing services, which is the main purpose of CPSV. Rather, I think it is crucial for the CPSV to describe in advance the semantics of the various roles involved in a service in terms of the various classes they apply to, as described above, instead of just relying on a core vocabulary of roles, as suggested by the CPSV-AP_IT.
Component
DocumentationCategory
feature
Login or create an account to comment.
Comments
I agree with Nicola in thinking that this is out of scope for CPSV-AP. That doesn't stop anyone adding in any properties as required of course.
For role descriptions, I'd point to the ORG Ontology for a mechanism to provide as much detail as necessary. Also, I believe it's likely that ISA will be working on a roles and mandates vocab before the end of the year.
Having spoken to Giorgia about this at SEMIC, I believe we should add in a new class of Participation. This is linked from the PS via 'has participation' and from Agent with plays role. It's possible to add any description to this. It will cover providers of the service who are not legally liable for it (e.g. an outside contractor) and potentially other roles.
In my view, the actual roles will be from a controlled vocab (i.e. a SKOS concept scheme, as in Italy), however, if Nicola's argument carries the WG then it could be another class that, again, can have any kind of description/semantics.
This is consistent with the modelling used in CPOV/ORG where the Participation class is called Membership - which does not feel quite right, hence the new name. But the Role class and overall approach is exactly the same.
The proposed text for the spec is as follows:
Participation Class
Public Services may be provided by outside organisations, such as commercial contractors, and may have any number of other dependencies. These can be described using the Participation class. The actual role played by the participant is given by a Role class that may provide further information about the role, irrespective of who plays that role.
Identifier [1..1]
This property represents a formally-issued Identifier for the Participation.
Description [1..1]
A free text description of the Participation.
Temporal [0..n]
Links to a Period of Time in which the Agent associated via the Plays Role property (section 3.15.4) participates/participated. If the Period of Time has only a start date, then it can be inferred that the participation is still active.
I think this gets relevant when you're instantiating public services. So long as you're making generic descriptions of public services (in order to eg. re-use those on a local level), the participation is overkill. With this in mind, I agree with the proposed model.
In my view, certain roles are so important for describing what a (public) service is, that we can't just represent them as a particular kind of participation plus a controlled vocabulary. I am thinking of:
- The Authority in charge of the service
- The service Provider (which may or may not be a contractor delegated by the Authority)
- The service Producer, which is the one who executes the Action the service is about (e.g., the teacher, for a school service)
- The service Customer (typically the Citizen or Business that requests the service)
- The service Consumer (the beneficiary of the service action - e.g., the student, in the case of a school service)
The very definition of what a service is, and all the varieties of different services, depend highly on how these different roles are related one each other. Collapsing all these roles in a Participation class would not give us a chance to express these varieties. So I suggest to introduce specific relations for each of these core roles (see Fig. 1 of my comments to the CPSV-AP_IT). An better solution would be to introduce these roles as classes, but in this case the change would be more substantial and perhaps not needed at this stage.
BTW, in the Italian document the choice of avoiding specific role classes, using instead a 'Role' class whose instances are role names taken from a controlled vocabulary, is justified by pointing to a paper that appeals to the OntoClean methodology. Unfortunately this is just a misunderstanding, as I explained in note 8 of my comments to the CPSV-AP_IT.
During the 24/5/16 telco it was agreeed that the Participation class would be added, however, no temporal properties would be provided as part of the CPSV-AP (they can be added by individual implementations of course).
However, since this is complicated, it was further resolved that the three basic roles would be defined with their own properties: Competent Authority, Service Provider and Service User. The latter two link to the Agent class, the Competent Authority links to the Public Organization class.