Add optional dct:hasPart to the Public Service class

[jimjyang]

A Public Service may consist of several other Public Services.

We propose therefore to add dct:hasPart to the Public Service class, (optional, 0..n, range cpsv:PublicService)

[NathanGhesq]

Can you provide some practical use cases on this matter? This way, we can have a better idea of what exactly is the need.

In CPSV-AP we have relations like requires and related. How would such a composition work in practice?

[jimjyang]

@NathanGhesq

We need to group together services in a hierarchical way. See e.g. "Find services | Family and children | Kindergartens | and the services thereunder" at the Norwegian site https://www.norge.no/en/, and similarly "Social security | Support for people with disabilities | Aids and home renovations for people with disabilities | and all the services that you see when clicking on "what services can I get?" " at the Finnish site https://www.suomi.fi/citizen as we understand it.

In our trial version of CPSV-AP-NO we have chosen to use dct:hasPart. cv:isGroupedBy was considered as an option, but it does not support a hierarchical grouping of services per se (it groups into cv:Event, not cpsv:PublicService). "Requires" is not a hierarchical relation, nor is "Related" which in addition is semantically too weak.

[NathanGhesq]

In CPSV-AP, dct:hasPart is already used to list Public Services in a Public Service Dataset.

What we observe on the Norwegian site is a hierarchical classification of Public Services, which looks different from an administrative or physical composition. Thus, it would be appropriate to use a taxonomy to group Public Services in a hierarchical way which could be implemented as a Skos collection and linked to Public Services via 'isClassifiedBy' or 'thematicArea'. You can define low level hierarchical structures by using Skos properties, which allow to specify broader and narrower concepts.

In addition, such taxonomy could be applied to cv:Event, thus a Public Service can be grouped by different 'levels' in the hierarchy of events. CPSV-AP does not prevent adding a relation between cv:Event to be organised in a hierarchical way.

[jimjyang]

@NathanGhesq

You are right that the examples from the Norwegian site shows more a conceptual grouping (thus classification) than an administrative or physical composition of services. We couldn’t (yet) find any real world example on administrative or physical compositions of a service.

Further questions/comments triggered by your first sentence in your reply (referring to https://catalogue-of-services-isa.github.io/CPSV-AP/releases/3.0.0/):

1. In the class Public Service (cpsv:PublicService), the description of the property cv:isDescribedAt says that this property “links a Public Service to the Public Service Dataset(s) in which it is being described”. Isn’t an instance of cpsv:PublicService also a description of the service? What is the rationale (or use cases) for creating and maintaining instance(s) of dcat:Dataset to describe a service in addition to the instance of cpsv:PublicService? When looking at the properties that are (explicitly for this application profile) in the class Public Service Dataset (dcat:Dataset), except for dct:hasPart, the other properties are administrative which don't add any more semantic values as we understand the class.
2. Concerning the property dct:hasPart in the class Public Service Dataset (dcat:Dataset): The description which now says that this property “links a Public Service Dataset to the Public Service” is far too general, it is only a technical description of the property. Could you please rewrite the description to include why, the purpose of, having Public Service(s) as part(s) of a Public Service Dataset?
3. Referring to what we started this issue with, could e.g. the following be a possible use case for dct:hasPart in dcat:Dataset (when and if we need to describe administrative or physical compositions of services)?

4. Depending on the answers to the questions above, _if_ the only semantic reason for creating and maintaining extra instance(s) of dcat:Dataset is the need of the property dct:hasPart, why not simply have this property in the class Public Service (cpsv:PublicService)?

[NathanGhesq]

In this example, the dataset describes a set of innovative public services (the dataset acts as a way of classifying public services in a particular context).

The relation dct:hasPart would enhance the metadata of the dataset by listing the Public Services described in the dataset description ("This dataset includes the list of cases identified by the Innovative Public Services Observatory (IPSO), concerning the use of emerging and disruptive technologies in public services. IPSO is a project jointly carried out by DIGIT and JRC in the framework of the EU ISA² Programme").
Additionally, an example of such relation can be seen in this (old) pilot that was done with The Netherlands. Here, the need was to describe Public Services starting from a Dataset. Thus, the need of creating such relation.

The relation cv:isDescribedAt is exactly the opposite of dct:hasPart. The former was created before the latter over time.

The diagram is correct. Of course, the usage of both relations (isDescribedAt and hasPart) depends on their starting point. Such relations are describing the physical composition of the Public Services, not the administrative composition.

In summary, 'isDescribedAt' and 'hasPart' relations are meant to describe Public Services in a dataset if there is a need to use a dataset like in the Dutch example above.

[EmidioStani]

The example was provided however it is linked to the discussion of using dcat:Dataset in CPSV-AP, see issue #103

[SirkoS]

^{I was asked to provide my opinion to this issue which I'll do in the following.}

This issue mixes up at least three different relations supposedly represented by dct:hasPart:

1. Using it to classify public services in a hierarchy (comment).

   This use has already been rejected in favor of using SKOS relations here.

2. Using it to connect a service description (represented via Dataset) to the described service.

3. Using it to describe service composition (comment).

As (1) has already been rejected, I'll only comment on the later two.

---

Regarding (2):

• There was the question (here) why there is a need to have separate instances of Dataset and PublicService when the description can be attached directly to the latter.

  To me the reason is rather straight forward: Instances of PublicService refer to the service itself.
  On the other hand, instances of Dataset (in this case) refer to the any document or resource that describes the service or its requirements possibly as the result of a legal norm of some sort.
  There may be multiple such documents as, e.g., a general federal law is being specified in more detail on a lower level of government, and finally also linked to technical implementation details.
  In my view, defining/describing documents are semantically, physically, and logically different entities then the service they describe and, hence, two separate classes are needed here.

• Personally, I do not agree to use dct:hasPart to link a dataset to the service it describes for multiple reasons:

  • Here a new definition for dataset is proposed by

    A collection of data including public services descriptions and where they can be found.

    This specifically allows for datasets that are not descriptions of services.
    For those datasets, dct:hasPart would serve no purpose under the narrow definition of (2).

  • The connection between a public service and the corresponding description(s) is already given via cv:isDescribedAt. As edges can be traversed in both directions, I don't see any reason to duplicate that information using dct:hasPart given the discussion surrounding that.

  • The DCAT-AP definition of dct:hasPart is

    A related resource that is included either physically or logically in the described resource.

    As argued before, I'd consider a service and its descriptions two separate entities: Both are neither physically nor logically included in each other.
    So using dct:hasPart to link between them imho contradicts the definition of its semantics and should be avoided here.

---

Regarding (3):

As a scenario I can imagine some kind of authentication service (e.g., via a digital passport or anything alike). Such a service might be part of multiple workflow as authentication is needed in almost every workflow. So, assigning a service to multiple workflows is a strict requirement which might be blocked by using dct:hasPart.

I wonder, whether this use case is already handled by the definition of dct:requires as stated in the current release which states among other things that

for a Public Service to be executed, another Public Service must be executed beforehand.

This allows to build chains of services (horizontal integration) but imho does not allow for combining several services into a combined workflow (vertical integration).

dct:hasPart might be an option here. But using such a general property for a rather specific semantic use case like orchestrating services to a workflow, seems wrong. I'd rather create a subproperty with clearer semantics which will also be more accessible to users later on.
Besides, mereology is a rather tricky area. So, I'd stay away from part-whole-relationsships and rather make the semantics clear using well defined properties instead of those rather generic ones.

For the service composition in general, it might be worthwhile to look into other efforts like BPMN or GerPSOnto.