Closed kvistgaard closed 1 year ago
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.
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.)
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.
In DCAT2 ,
data:service
is axiomatized asPlease 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 (viadcat:servesDataset
,dcat:service
, which otherwise is very appropriate, cannot be used as the applicated will be inferred as of typedcat: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.