Verify axiomatization of dcat:service

[kvistgaard]

In DCAT2 , data:service is axiomatized as

dcat:service
  rdfs:domain :Catalog ;
  rdfs:subPropertyOf dct:hasPart ;
  rdfs:subPropertyOf rdfs:member ;
.

Please verify the need for these three restrictions.
In general, from a pragmatic perspective, I believe such constraints are unnecessary in an ontology. They are both too restrictive and not restrictive enough. Being too restrive prevents the wider use (one of the reasons I personally avoided DCAT so far). But in practice they are also not restrictive enough, so better to have real constraints (SHACL, ShEX) in application profiles.

From the listed ones, I see the biggest issue being the declaration of domain dcat:Catalog. For example, when reusing DCAT to relate an application (solution etc) to its services and from there to the datasets exposed via these services (via dcat:servesDataset, dcat:service , which otherwise is very appropriate, cannot be used as the applicated will be inferred as of type dcat:Catalog. This also makes more generic use of service problematic. For example, for creating sub-properties :providesService and :realizesService, which are standard architecture relations between Provider/Component and a Service.

[pietervaneverdingen]

We need this modeling flexibility at the heart of a data application ontology (to describe e.g. linked data solutions).

In general it might be a good idea to review all domain and range definitions to decide whether they are too restrictive (or not) and only add them when such a restriction is really needed.

[dr-shorthair]

I suggest dropping the rdfs:member reference. That is a by-way of rdfs which no-one much uses and it is a bit unclear what meta-level it is supposed to represent.

However, these kinda belong together:

dcat:service
  rdfs:domain :Catalog ;
  rdfs:subPropertyOf dcterms:hasPart ;
.

The generic relationship of a catalog to its parts is through dcterms:hasPart.
dcat:service, dcat:dataset and dcat:catalog are specializations of 'has-part' for different kinds of catalogued thing - i.e. this sub-property axiom applies in the context of a Catalog.

The sub-property relationship probably would not apply to a link to services in other contexts. But after all, DCAT is primarily about data catalogs, so perhaps you should not expect dcat:service to a be a free-floating predicate that you can pick and use in a non-catalog context.

(While I agree that SHACL etc may be a better way to implement such constraints, and can be tuned to different contexts, DCAT is currently specified in RDFS and OWL, not SHACL.)

[bertvannuffelen]

But after all, DCAT is primarily about data catalogs, so perhaps you should not expect dcat:service to a be a free-floating predicate that you can pick and use in a non-catalog context.

This is a very important statement which I agree with.