Align with upstream ckanext-dcat, avoid patches

[amercader]

Hi @seitenbau-govdata, I'm the main developer of ckanext-dcat and I've been assessing your extension as we are really interested in 1) Showcasing custom national profiles on the main ckanext-dcat documentation and 2) Making easier to use for German cities and other organizations so there's a lower entry for publishing DCAT-AP.de compliant metadata.

I'd like to explore with you the possibility of not needing to patch ckanext-dcat to use the extension and align it with the latest version, which would make the usage much easier. I had a look at the diff between your patched profiles.py and the master upstream one:

https://gist.github.com/amercader/6b8de9a58ffdbd3fb2d69f95603e14ec

Your changes are very sensible and most could be ported upstream via pull requests as they are generic enough IMO. For instance:

• Whitespace removal
• mailto handling + value_modifier
• g.add((checksum, RDF.type, SPDX.Checksum))
• URIRef vs Literal: It makes sense to use it on the properties that you chose, but to make it generic what do you think of a URIRefOrLiteral type that returns one or the other depending on whether the value starts with http? But maybe I'm oversimplifying the issue and there is more complexity involved

If needed (probably not), other changes in the patch could be added to the dcatap_de profile directly . For instance if some of the triples added on the default euro_dcat_ap profile don't suit you you can just remove them and re-add them whoever you want to the graph.

How does this sound? If you are happy with this approach I'll have closer look at other parts of the extension like the patched harvester, and we can provide help porting things upstream.

[seitenbau-govdata]

Hi @amercader, thanks for creating the issue addressing the need to back porting the patch within ckanext-dcatde to ckanext-dcat. We fully agree with your intention to back port the changes in our patch of ckanext-dcat to the upstream. And we're really happy that you have planned ckanext-dcatde should become a showcase on ckanext-dcat.

That was and still is our intention when we started with the developing and finishing the release, but the time to the initial release of ckanext-dcatde was to short to first porting back our changes to the upstream and then integrate the updated ckanext-dcat.

I think we can not create the pull requests ad hoc. Probably we can manage it in the next three months. Does this suits to your plans? Or when you have planned to add ckanext-dcatde as an showcase for a custom national profile?

We have still a change pending (not available on GitHub) which adresses the issue https://github.com/ckan/ckanext-dcat/issues/2. We're still working on a pull request for that single issue., but I don't know exactly when we are ready to create the pull request in ckanext-dcat, because our goal is to create a pull request not before we have added or adapted the tests. But the implementation is ready.

Thanks for the hint with shifting individual code to the own profile and removing/replacing triples there if needed. We will try to following it in future releases.

The idea with an type URIRefOrLiteral sounds good for me. I think that should be suitable.

The changes in the patches for the harvester in ckanext-harvest and ckanext-dcat are already ported back to the upstream projects, but we still not updated the used version of the projects in our ckanext-dcatde.

[seitenbau-govdata]

Fixed with commit 77a03b009f0cb210698d2d0f50ff2deb9c8795e8.