Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

License on resource? #493

Open
tomkxy opened this issue Aug 12, 2021 · 2 comments
Open

License on resource? #493

tomkxy opened this issue Aug 12, 2021 · 2 comments
Milestone

Comments

@tomkxy
Copy link

tomkxy commented Aug 12, 2021

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?

@clange
Copy link
Member

clange commented Sep 15, 2021

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.

@HaydarAk
Copy link

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 :)

@HaydarAk HaydarAk self-assigned this Sep 23, 2021
@JohannesLipp JohannesLipp added this to the 6.0.0 milestone Mar 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants