Open tomkxy opened 3 years ago
Makes sense. The question is how soon you need the solution. By the end of 2021, we are planning in an effort led by @JohannesLipp to clean up the core infomodel by introducing application profiles. In the same course, we'll improve the alignment with DCAT. (Thus, @JohannesLipp, could you please extract the general points out of this specific discussion into an issue that relates to the alignment with DCAT?)
Anyway, this sounds like a quick fix independently from our big clean-up plan. I'm linking to DCAT 3 here, but I don't think that in this field there are changes over DCAT 2.
So, we are talking about ids:standardLicense
and ids:customLicense
, both being subproperties of dct:license
, which is what DCAT recommends to use. These two properties have the domain ids:Resource
(then why are the properties defined in content/DigitalContent.ttl
?!), which is a subclass of ids:DigitalContent
, which is a subclass of dcat:Dataset
.
In contrast, in DCAT, dct:license
does not exclusively apply to datasets. @tomkxy you are half right: in DCAT, dct:license
can be applied to dcat:Distribution
(see here), but it can also be applied to dcat:CatalogedResource
(see here).
The IDS infomodel is still largely based on the simpler design of DCAT 1, which didn't have dcat:CatalogedResource
and its subclass dcat:DataService
. (@JohannesLipp for our DCAT alignment and also the alignment with Gaia-X Self-Descriptions, please note that we need to take into account dcat:DataService
, which relates to what we call endpoints, and also to Gaia-X Service Offerings.) The other subclass of dcat:CatalogedResource
is dcat:Catalog
, which existed both in DCAT 1 and is extended in the IDS infomodel.
Bottom line: I think that instead of attaching lots of attributes to subclasses of dcat:Dataset
, we need a more general approach, in particular regarding data licenses.
For now, could you @HaydarAk please start looking into this and then hand over to @JohannesLipp.
Bottom line: I think that instead of attaching lots of attributes to subclasses of dcat:Dataset, we need a more general approach, in particular regarding data licenses.
That was also my first thought as I read through your answer. Can take a look into that :)
Having to deal with DCAT mappings from harvested sources to IDS in the MDP project, we realized that in DCAT licenses are defined on distribution level which seems to be appropriate since each individual distribution can have its own license.
In IDS licenses are represented on resource level. This makes a mapping from DCAT rather difficult.
Since DCAT is not really exotic, there might suggestions how to handle that?