- From: Harshvardhan J. Pandit <harshvardhan.pandit@adaptcentre.ie>
- Date: Tue, 19 Apr 2022 18:54:01 +0100
- To: Bert Van Nuffelen <Bert.Van.Nuffelen@tenforce.com>
- Cc: "public-dpvcg@w3.org" <public-dpvcg@w3.org>, Rob Brennan <rob.brennan@dcu.ie>
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