- From: Ivo Velitchkov via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 May 2021 16:01:34 +0000
- To: public-dxwg-wg@w3.org
kvistgaard has just created a new issue for https://github.com/w3c/dxwg: == Verify axiomatization of dcat:service == In DCAT2 , `data:service` is axiomatized as ``` dcat:service rdfs:range dcat:DataService ; 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. Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1363 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 May 2021 16:01:35 UTC