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

在真实世界用例中演示DPCat

在本节中，我们演示了DPCat在表示由欧洲数据保护主管（EDPS）[41]（EDPS）发布的真实世界ROPA文档中的应用，使用SHACL对其进行验证，使用SPARQL查询检索相关信息，并将其导出为RDF图以及符合DPA模板的电子表格。我们为DPCat的实用性和可行性及其在ROPA信息管理过程中的优势提供了证据。数据、代码和输出可在线获取(https://w3id.org/dpcat/demo/edps-ropa).

使用DPCat表示信息

EDPS是负责监督欧盟机构合规性的DPA，该机构包括欧盟各机构的许多员工及其相关的个人数据处理活动。EDPS已根据GDPR第30条的要求发布了详细的ROPA文件，该文件提供了透明度和问责制。截至2022年3月，EDPS已提供58份ROPA文件集，每一份都包含一份PDF（格式）文件，提供有关处理操作的英文信息。集合基于“主题”进行结构化，主题可以是部门（例如，行政和人力资源或IT）、流程（例如，通信或公共事件）或特定措施（例如，访问文档或物理安全）。

我们分析了EDPS ROPA文件，并选择了四个（id:01、05、13、55），其中涵盖了部门、处理器、联合控制器和数据传输的U1–U4用例。由于所需的大量劳动力和分析工作，以及所选文件足以证明DPCat的应用，我们没有包括其他文件，尽管它们具有相关性。这些文件是用于人类理解的PDF，缺乏一致的语义，例如，目的字段也包含法律依据。

我们对这些文档及其结构的解释如下：每个文档（即PDF）表示一个ROPA实例，其中包含的信息使用ROPARecord实例进行结构化。我们使用的标准是，每个ROPAR记录都将遵循基于信息复杂性和关注点分离的定性标准的单个“上下文条目”。例如，文档X指定了两个处理器，我们将其解释为每个处理器的单独ROPARecord实例，以指示控制器通信和数据管理中的关注点分离。然后，整个文档集和RDF图被表示为单个ROPACatalog实例的一部分，反映了EDPS网站上发布的记录集。

使用ApacheJenaRDFS推理器[42]增强了手动创建的RDF图，以创建一个“完整的图”，简化查询和验证。有限的RDFS推理在这里足以获得图中子类和子属性的扩展，而不是使用OWL推理机生成推理。为了存储信息并提供查询界面，我们使用了GraphDB Free Edition三重存储[43]，因为它是一个符合相关标准（例如SPARQL）的免费可用三重存储，并具有几个方便的功能，例如友好的界面、集成推理器、SHACL验证。用于表示EDPS ROPA文档和信息的ROPARecord、ROPA和ROPARecold实例的简明示例如清单[lst:rdf-ROPA]所示。数据工作流概述如图[图：dpcat演示工作流]所示：

Data workflows in DPCat demo application

@prefix edps: <https://w3id.org/dpcat/examples/EDPS/vocab#> .
@prefix : <https://w3id.org/dpcat/examples/EDPS/05#> .
: a dpcat:ROPA ;
    dct:title "Selection of staff"@en ;
    dct:description "The purpose of the processing ..."@en ;
    dct:created "2021-11-03"^^xsd:date ;
    dct:identifier "05"^^xsd:string ;
    dct:publisher edps:HRBA ;
    dcat:contactPoint edps:HRBA ;
    dcat:dataset :05-1, :05-2, :05-3, :05-4 .
:05-1 a dpcat:ROPARecord ;
    dct:title "Selection and management of interim staff"@en ;
    dct:description "Selection and management of interim staff"@en ;
    dct:created "2022-02-16"^^xsd:date ;
    dct:publisher edps:HRBA ;
    dcat:contactPoint edps:HRBA ;
    dpv:hasDataController edps:EDPS ;
    dpv:hasResponsibleEntity edps:HRBA ;
    dpv:hasPersonalData edps:InterimAgentLastName, 
        edps:InterimAgentFirstName, edps:InterimAgentCV ;
    dpv:hasPurpose edps:MonitoringOf7YearRule, edps:PreparationOfEmploymentContracts, edps:ExecutionOfContract ;
    dpv:isImplementedUsingTechnology edps:SYSPER ;
    dpv:hasRecipient edps:Managers, edps:HRBA ;
    dpv:hasLegalBasis dpv:StaffContract ;
    dpv:hasTechnicalOrganisationalMeasure edps:AuthorisedPersonnelNeedToKnowBasis ;
    dpv:hasDataSource edps:RandstadBelgium, edps:Daoust ;
    dpv:hasStorage [
        a dpv:StorageCondition ;
        skos:editorialNote """The data ... managed by Sysper"""@en ;
        dpv:hasDuration [
            a dpv:StorageDuration, time:Duration ;
            dpv:hasPurpose edps:EnsureReconstructionOfHistoryBySYSPER ;
            dpv:hasPersonalData edps:DataRelatingToSYSPERService ;
            time:numericDuration "5"^^xsd:decimal ;
            time:unitType :unitYear ; ] ] ...

DPV的SHACL形状

为了验证和验证生成的RDF图，我们首先使用DCAT-AP规范提供的SHACL约束，以确保数据符合DCAT和DCAT-AP定义的要求，例如，发布者为foaf:Agent类型。然后，我们开发并使用了表示基数和类型约束的SHACL形状，以确保DPCat需求的正确性。为了执行这些约束，我们使用了开源和免费的TopBraid SHACL工具[44]。

在执行信息验证时，形状约束基于DPCat，其利用DPV和DCAT概念来表示相关信息。然而，DPV和DPCat都没有指明某些信息必须表示的“形状”。因此，对于给定的场景，可能有不止一个“形状”，通常处于任意的复杂程度，这就阻止了一组常见的SHACL形状与DPCat规范一起开发和提供。例如，可以根据dpv:DataTransfer的dpv:hasLocation来建模用于确保数据传输的SHACL约束及其适当位置。然而，DataTransfer实例可以在图中的任意节点上使用，因此很难定义后续约束，例如传输的接收方及其位置。

一个简单的解决方案是将所有相关字段与ROPA或ROPARecord实例相关联。这方面的一个挑战是，所有基于DCAT的结构可能无法合并所有字段，或者这会使DPCat过于复杂。另一种方法是为每个概念的使用确定用例，并为如何使用DPV表达信息定义特定的SHACL形状。鉴于这需要大量的分析和努力，为了本文的目的，我们限制了定义的SHACL形状来表示EDPS文档中的信息。然而，我们主张进一步研究和开发这样的形状，以便可以使用它们来确保在用例和实现中一致地表示数据。

查询ROPA信息

为了模拟DPO或DPA执行的典型任务，我们在两个用例中使用SPARQL查询：（i）检索GDPR第30条要求的信息；以及（ii）组织内各种组织单位、目的、法律基础、接收人、数据传输等方面的实践概述。这里，查询（i）涉及常见的合规文件程序，查询（ii）显示了DPCat根据ROPA信息（例如DPO）帮助创建内部报告或仪表板的潜力。

第一个查询如清单[lst:demo-sparql-art30]所示，其输出片段在表1中，根据GDPR的Art.30检索ROPA信息。

第二个查询如清单[lst:demo-sparqlunits]所示，其输出片段在表2中，通过从ROPARecord实例中检索相关信息，提供了组织的处理活动和与外部实体的关系的概述。

SELECT DISTINCT ?Entry ?title ?purpose ?datasubject ?personaldata 
    ?recipient ?legalbasis ?transfer_location
WHERE {
    ?Entry a dpcat:ROPARecord .
    ?Entry dct:title ?title .
    ?Entry dpv:hasPurpose/skos:prefLabel ?purpose .
    ?Entry dpv:hasDataSubject/skos:prefLabel ?datasubject .
    ?Entry dpv:hasPersonalData/skos:prefLabel ?personaldata .
    OPTIONAL { ?Entry dpv:hasRecipient/dpv:hasName ?recipient } .
    OPTIONAL { ?Entry dpv:hasLegalBasis/skos:prefLabel ?legalbasis . }
    OPTIONAL { ?Entry dpv:hasProcessing ?processing . 
        ?processing a dpv:Transfer . 
        ?processing dpv:hasLocation/skos:prefLabel ?transfer_location } } 

SELECT DISTINCT ?org ?title ?purpose ?processor ?jointcontroller
WHERE {
    ?record a dpcat:ROPARecord ; dct:title ?title .
    ?record dct:publisher/dpv:hasName ?org .
    ?record dpv:hasPurpose/skos:prefLabel ?purpose .
    OPTIONAL { ?record dpv:hasDataProcessor/dpv:hasName ?processor }
    OPTIONAL { 
        ?record dpv:hasJointDataControllers/dpv:hasName ?jointcontroller } } 

导出ROPA

为了演示DPCat如何促进利益相关者内部和利益相关者之间的信息交换和数据治理，我们提供了两个信息导出示例。第一个示例通过使用SPARQL CONSTRUCT查询以RDF图的形式检索相关信息，将信息导出为DPCat定义的目录。SPARQL查询和结果图可以在线查看。此类导出有助于以备份、副本或图形的形式存储信息。它也有助于在利益相关者之间交换ROPA信息，如数据控制器和数据处理器之间的数据治理，所有这些都支持使用DPCat。

第二个示例模拟DPO在电子表格中手动管理信息的自动化。为此，我们使用了一个Python脚本，该脚本执行SPARQL查询，并基于DPA ROPA模板将结果导出到MS Excel（.xlsx）文档中。虽然SPARQL查询本身的输出也可以导出为CSV文档，但在这种情况下，Python的使用是为了复制DPA模板的结构和内容，并在更复杂的XLSX格式上操作，该格式支持电子表格中的选项卡。

实施情况分析和经验教训

DPCat在现实世界ROPA中的应用暴露了构建语义表示的固有困难，这是由于输入缺乏或结构松散，而不是基于机器的工具所要求的严格结构。我们讨论了用一个建议的解决方案进一步探讨这个问题，其中组织为用例创建了一个单独的受控词汇表注册表，以首先注册其概念，例如所使用的特定用途或处理的数据类别，然后确保ROPA文档仅使用这些概念。然而，我们发现这种解决方案明显偏离了缺乏这种结构化数据收集方法的组织流程。我们认为这是一个开放的问题，希望更好的工具能够解决它。

在使用DPV表示ROPA信息时，我们面临的障碍是，DPV作为词汇表可以支持广泛的数据建模风格。由于两个不同的组织可以对其数据进行不同的建模，这对使用DPCat作为通用信息表示机制构成了障碍。虽然DPV的通用概念结构有助于协调两个模型，但工具的开发最好具有一致的信息结构。为此，我们建议创建“DPV形状”，为模块化用例提供建议的数据建模实践。使用SHACL表示的此类形状将促进DPV使用方式的通用性，并将作为其他建模方法的通用模型，这些建模方法可以减少或调整。在此，重要的是要说明DPV的优点之一是缺乏严格的采用要求，这为采用者提供了在其用例中使用它的灵活性。形状的提供使DPV作为词汇表具有持续的灵活性，同时为如何在不同应用程序之间一致使用或互操作提供指导。

最后，我们在确定合适的DPCat特定信息验证机制方面面临挑战。虽然我们利用SHACL形状来证明基于信息和GDPR合规性要求进行此类验证的可能性，但这一领域值得进一步探索。特别是，SHACL约束可用于两类评估：首先检查是否存在必要的信息，以及是否具有与DCAT-AP SHACL形状类似的预期值。第二种是基于GDPR的要求，例如确保使用正确的法律依据。从DCAT和DCAT-AP中的基数约束可以看出，第一个是对符合规范的内在评估，而第二个直接涉及GDPR合规性验证。此前的研究探索证明了SHACL约束在确保GDPR合规性信息正确性和一致性方面的使用[45]。