【欧盟RoPA】DPCat：基于GDPR的可互操作和机器可读数据处理目录规范 ，第三部分

DPCat:数据处理目录

在前面的章节中，我们介绍了一个“ROPA通用语义模型”（CSM-ROPA），它基于对DPA ROPA模板的分析，表示了一组整合的信息需求，这些模板可以通过使用DPV作为机器可读和可互操作的词汇表（见第3节）。然后，我们根据利益相关者之间的数据流探讨了ROPA的来源和使用，并确定了五个用例，这些用例提供了在实际环境中使用CSM-ROPA的进一步要求。在本节中，我们将介绍同样在线发布的数据处理目录（DPCat）规范(https://w3id.org/dpcat)，解决了已确定的需求，并促进了组织内和组织间异构源信息的管理，以实现以机器可读和互操作的方式表示ROPA。

DPCat扩展了数据目录词汇（DCAT），这是一种促进数据目录之间互操作性的W3C标准[17]，CSM-ROPA中使用DPV确定了概念，以分别将ROPA和相关信息表示为“目录”和“数据集”，可在利益相关者之间记录和交换。DPCat还旨在保持与“欧洲数据门户的DCAT应用程序配置文件”（DCAT-AP）[18]的兼容性，该配置文件代表了欧盟对数据门户目录元数据标准化的努力。与DCAT-AP的兼容性基于我们的愿景，即DPCat可用于所有基于DCAT-AP目录信息管理工具和数据门户，以提供使用欧盟倡导的标准共享ROPA相关信息的机制，并促进将现有数据门户基础设施用于合规相关目的的可能性，例如控制器、处理器和DBA。

我们之前关于DPCat的工作[2]、[3]基于CSM-ROPA，该模板由六个DPA ROPA模板开发，涉及五个用例中的两个（U2：组织单位，U3：处理器）。这项工作包括17个DPA ROPA模板的更新CSM-ROPA、对DPV的更新（从v0.2到v0.5），以及DCAT和DCAT-AP要求（例如基数）的集成，以实现兼容性。

DPCat概述

如图[图：DPCat概述]所示，DPCat区分ROPA（作为文档或人工制品）和ROPA中的“条目”，其中每个条目代表特定的上下文，例如业务流程或数据处理目的。为了表示这些，我们在语义上将DCAT-AP概念“目录”和“数据集”分别扩展为“ROPA”和“ROPARecord”。我们还将“目录”扩展为“ROPACatalog”，以表示当一个组织有多个ROPA文件时的ROPA目录集合（即目录目录），例如表示不同的时间段或活动或组织单位（例如部门）。附录11概述了这些概念。

DPCat ROPA, ROPARecord, and ROPACatalog overview

ROPARecord是一个dcat：数据集，它对要记录在ROPA中的信息进行分类，类似于ROPA电子表格中的“单行”，表示处理的单个记录。它用作dpv:PersonalDataHandling的一个实例，使用CSM-ROPA分析中确定的相关dpv概念来关联处理目的或法律基础等概念。为了确保与DCAT和DCAT-AP要求和建议的兼容性，例如发布者是foaf:Agent，DPCat将相关的DPV概念声明为DCAT-AP指定概念的子类。在ROPARecord实例中，概念是一致的，即所有目的都适用于所有个人数据，并与所有接收者共享，依此类推。为了表示分离，应创建单独的实例。

（dpcat:）ROPA表示由一个或多个ROPARecord数据集组成的dcat:Catalog，反映了“ROPA作为单个文档”的传统观点，每个条目都是目录中的ROPARecod。在ROPA和ROPARecord中，DCAT属性提供了与相关信息的关联，如发布者指示谁制作或提供了该记录，时间注释（如记录何时制作或表示的时间段），以及注释（如标题和描述）。ROPACatalog在从dcat:Catalog扩展方面与ROPA相同，用于使用dcat:Catalog关系将相关ROPA目录捆绑在一起。

对于利益相关者之间与ROPA相关的常见沟通，例如将该信息的“联系点”（如部门或经理）关联起来，DPCat使用DCAT关系DCAT:contactPoint。此外，为了遵守GDPR术语，它使用DPV属性表示控制器（DPV:hasDataController）、DPO（DPV:hasDataProtectionOfficer）和“责任实体”（DPV-hasResponsibleEntity）。在这种情况下，DCAT和DPV术语之间的重叠（例如，控制者是发布者或DPO是联系人）可能不会总是发生，例如，当代表仅限于某个部门的活动时，该部门的联系人是与DPO联系的该部门的成员。

使用DPCat进行ROPA信息管理

正如我们在第节中详述的。4、用例中的信息和数据治理要求表明，每个实体都需要组织、维护和交换相关信息，以执行ROPA相关流程。作为一种规范，DPCat通过集成到用于信息存储和检索（例如，数据库）和信息管理实践（例如，文档和数据目录）的工具中来支持自动化。它可以表示所有与ROPA相关的信息，或者仅表示目录元数据，并将其链接到外部存储的实际信息（例如电子表格）作为数据集。无论在哪种情况下，DPCat都提供了一致的信息结构，支持技术解决方案，如查询、验证和导出（见下一节），以帮助相关利益相关者完成任务。

DPCat通过结合组织的结构和管理要求，促进ROPA的数据治理。对于U1，如果必须在组织层面维护ROPA，则可以集中维护ROPA和ROPAR记录数据。对于U2–U4，存在不同的信息来源，并且希望以相同的方式记录信息来源和跟进，DCAT关系使出版商和联系点的来源成为可能。相反，ROPACatalog支持收集部门或处理者发布的相关信息。

DCAT的语义为确定如何组织和存储ROPA信息提供了灵活性，而无需确定单个方法或结构。例如，除了基于组织单位和外部实体的结构之外，可能需要基于上下文信息（例如与产品或服务相关的特定业务流程）保存记录。这可以通过创建代表其他集合的其他ROPACatalog条目并将其链接到相关ROPA条目来实现。通过这一点，组织可以在使用ROPA信息时实现多方面的方法，而无需重复数据。

DPCat倡导的技术解决方案的使用面临着一个障碍，即ROPA相关工作流程中的信息来源不一定具备产生一致有效元数据的技术知识。例如，具有必要法律知识的DPO不一定具有或关心信息存储和检索的基本技术问题，而不必超出履行其职责所必需的范围。在这种情况下，DPCat可以继续使用现有的信息存储和管理机制，如数据库和电子表格，将其集成到这些机制中，而不是作为替代。例如，使用SQL数据库，其表中表示的信息将使用DPCat作为模式，通过现有方式提供输入，例如输入表单或使用受控结构导入电子表格。或者，使用基于RDF的解决方案（如三重存储），可以通过使用映射将表单或电子表格转换为DPCat。

我们设想将DPCat集成到一个典型的工作流（即U2–U4）中，用于记录ROPA，如下所示。来源（例如部门代表）生成一份ROPAR记录，其中包含来源为部门的相关信息。他们使用可用的机制，例如一系列表单或转换电子表格的脚本。这些信息被整理成ROPA集合，代表由组织结构确定的上下文分组（例如，每个部门维护）。对于组织外部的来源（例如，处理器），所提供的信息类似地存储在专用ROPA和ROPAR记录条目中，并可选地直接集成到相关数据集中（例如，控制器在其ROPA中列出处理器的技术措施）。这可以使用技术解决方案，如数据库或门户。为了以有组织的方式促进ROPA记录的结构化，ROPACatalog条目用于根据一些标准（如时间期限、法律顾问或负责经理）收集和分组ROPA条目。

使用DPCat进行查询和验证

DPCat支持并支持各种查询和验证方法，这些方法利用其基于元数据的结构来执行信息检索和验证任务。DPCat可以成为技术解决方案中的一个重要工具，通过这些解决方案用于合规相关流程。本节提供了一些查询和验证任务的示例，这些任务可以激励组织在ROPA相关流程中使用DPCat。

与ROPA相关的一个常见查询是检索特定上下文的GDPR第30条信息，例如数据传输或覆盖某个时间段。DPCat通过DCAT和DPV元数据支持此类查询，例如，将传输位置指示为DPV:DataTransfer和DPV:hasLocation以及DCAT DCAT:temporalPeriod，以执行基于时间的过滤。清单[lst:SPARQL retrieve ropa]中提供了一个表示为SPARQL查询的示例。

与查询类似，DPCat还支持信息的验证和确认，通常确保或评估符合GDPR。验证是指是否有足够的信息可用，是否采用正确的形式和格式，是否符合某些要求。核查是指根据某些规范（如GDPR的具体义务）对信息进行评估。

基于DCAT和DCAT-AP规范规定的强制字段的约束也适用于DPCat。因此，使用DPCat表示的数据可以利用现有的验证和验证机制来符合这些标准。此外，DPCat促进GDPR特定约束的表达，这些约束通常由DPA作为指导原则表达，并已成为学术和商业机构研究的主题。然而，与这些现有解决方案相比，DPCat有一个优势，即它还通过作为待验证信息的互操作规范，促进了此类验证机制之间的互操作性。

?Entry a dpcat:ROPARecord .
?Entry dct:title ?title .
?Entry dct:publisher/dpv:hasName ?publisher .
OPTIONAL { ?Entry dcat:contactPoint/dpv:hasName ?contact } .
?Entry dct:created ?created .
?Entry dpv:hasProcessing ?transfer .
?transfer a dpv:Transfer .
# minimum date within which data transfer occurs
?Entry dct:temporal/time:hasBeginning/time:inXSDDate ?start .
FILTER (?start < "2021-01-01"^^xsd:date) .
OPTIONAL {
    # maximum date, if available
    ?Entry dct:temporal/time:hasEnd/time:inXSDDate ?end .
    FILTER (?end > "2022-01-01"^^xsd:date) .
}
OPTIONAL { ?transfer dpv:hasDataImporter/dpv:hasName ?importer . }
OPTIONAL { ?transfer dpv:hasDataExporter/dpv:hasName ?exporter . }

作为GDPR通常涉及的信息验证示例，清单[lst:shacl确保目的]提供了一个shacl约束，该约束确保每个ROPARecord实例都有相关的目的。此外，为了确保信息以正确的形式存在，SHACL约束也有助于GDPR合规，例如确保以下适当的法律依据：（i）它必须具有GDPR第6条规定的相应法律依据（注：虽然GDPR第30条不要求ROPA中有法律依据，但DPA指南强烈建议这样做）；（ii）如果处理涉及特殊类别的个人数据，则还必须具有GDPR第9条规定的相应法律依据；（iii）如果处理涉及向非欧盟地点传输数据，则还必须具有GDPR第45、46或49条规定的相应法律依据。我们计划在未来为信息验证和基于GDPR的需求验证提供此类SHACL形状。

dpcat:Shape_EnsurePurpose
    a sh:NodeShape ;
    sh:name "Ensure every processing has a denoted Purpose "@en ;
    sh:description "Ensure the dpv:hasPurpose property is defined and has a value that is an instance of dpv:Purpose"@en ;
    sh:targetClass dpcat:ROPARecord ;
    sh:property [
        sh:path dpv:hasPurpose ;
        sh:class dpv:Purpose ;
        sh:minCount 1 ;
    ] .

用于互操作信息交换的DPCat

DPCat提供了一种机器可读和可互操作的信息表示，组织可以使用该信息来自动化其ROPA管理和相关任务。在信息来源不同的情况下，特别是当涉及外部利益相关者（如处理者和其他控制者）时，DPCat可以用作“标准化信息表示”，以方便信息流。在本节中，我们将探讨此类发展的潜力。

当他们雇佣数据处理者时，数据控制者的义务包括维护外包给处理者的处理活动的信息，以及如何执行这些活动的一些细节。例如，控制者可以要求处理者提供他们实施的技术和组织措施，以确保处理过程中的充分安全。类似地，控制器可能需要跨境数据传输的数据存储位置信息。如果一个处理器与另一个（子）处理器签订合同以执行处理，它必须保持子处理器操作的类似记录，但也应根据要求将其提供给控制器。在所有这些情况下，信息必须由实体自身定期独立维护，并在上下文需要时传达给其他实体，其他实体也必须独立维护这些信息。此类信息流和要求对于联合控制方与相关控制方的关系也是必要的。

如果为ROPA相关任务传递信息的两个实体使用DPCat作为其内部信息表示，则它们可以使用DPCat指定的记录直接交换ROPA信息。这是一个理想的场景。然而，即使任何一个实体或没有实体不在内部使用DPCat，DPCat也可以用作实体之间交换ROPA信息的通用规范。在这种情况下，发送方实体将其具有的任何内部表示转换为DPCat，并将其发送给接收方实体，以确保其能够理解和解释信息。接收机将基于DPCat的信息转换为它们使用的任何内部表示。因此，DPCat为ROPA信息交换提供了优势，即使组织不希望将其完全用于内部流程。DPCat同样适用于DPA和审计员，他们可以将其作为一种互操作格式，向组织请求信息。DPCat的一致性和机器可读性为研究人员提供了使用自动化和工具减少工作量和重复的潜力。