Re: DPCat: Data Processing Catalogue using DPV and DCAT(-AP)

Hi. I don't understand why your analysis states DPCat ROPARecord should 
not be a DCAT-AP dataset - there is no reason why we cannot extend DCAT 
or DCAT-AP to represent catalogues of a specific kind - in this case 
related to ROPA.

This follows from existing extensions, such as GeoDCAT-AP which aim to 
be compatible with DCAT(-AP) whilst adding additional metadata specific 
to their domain (in this case for geospatial). Similarly, DPCat aims to 
be compatible with DCAT(-AP) while providing additional metadata about 
the GDPR/ROPA domain.

As for tools, as per DCAT-AP specification, anything that conforms with 
its requirements (e.g. mandatory fields), can be used by tools expecting 
DCAT-AP metadata. Therefore, catalogue tools that work with DCAT-AP 
should work with DPCat catalogs, and same for DCAT and its tools. The 
GDPR and ROPA usefulness DCAT(-AP) aware tools is a separate matter, and 
there is no necessity to have a single tool do both. In fact, this is 
the basis for why we use DCAT(-AP) - existing catalog services should 
work with DPCat when treating it just like any other catalog metadata. 
The additional GDPR/ROPA stuff for these datasets will be additional 
extensions or separate tools.

AFAIK, the definition of a ROPARecord does match the definition of DCAT 
dataset (note that DCAT-AP does not properly redefine dcat:Dataset). I 
quote the definition from DCAT and DCAT-AP below, which to me is 
compatible with the view of ROPA information being a dataset.

DCAT (v2): "A collection of data, published or curated by a single 
source, and available for access or download in one or more 
representations."

DCAT-AP (v2.1.0) "Mandatory class. A conceptual entity that represents 
the information published."

Finally, perhaps what the main issue of contention might be, for ROPA 
(the GDPR concept) - its what is inside that ROPA (i.e. its records or 
entries) that is needed to be queried. Just the fact that a ROPA exists 
with a timestamp is not of much use or value. One can view the ROPA as 
being a catalog record of processing activities - which is what DPCat 
tries to represent.

So the discussion can be narrowed down to whether dpcat:ROPARecord 
should be a dcat-ap:Dataset or is it itself the contents of a dataset - 
on which DPCat states that ROPA entries are 'metadata' to processing 
records as that's what is of use to stakeholders who will be using this 
information.

Regards,
Harsh

On 19/04/2022 18:31, Bert Van Nuffelen wrote:
> This is what I suspected. Now I come to the alignment statement with 
> DCAT-AP. If you state you want to align with DCAT-AP, and the scope of 
> DCAT-AP is describing the datasets as I illustrated, then one cannot 
> state that DPCat ROPARecord is a DCAT-AP dataset.
> Then it is an independent DCAT profile which may take inspiration from 
> DCAT-AP, but which content and scope is different.
> Even more the tools and agreements suited for DCAT-AP (open data 
> portals) are very lickely not fitting the ROPA implementations.
> 
> That is what I meant with the definition of a ROPARecord should match 
> the definition of a DCAT-AP dataset.
> You confirm now that these are two distinct things and should not be mixed.
> 
> But there can be a connection, e.g.

-- 
---
Harshvardhan J. Pandit, Ph.D
Research Fellow
ADAPT Centre, Trinity College Dublin
https://harshp.com/

Received on Tuesday, 19 April 2022 17:54:16 UTC