## Background / Context Currently, in Semantic Treehouse, we can publish and manage ontologies, technical specifications, and DPP templates. However, there is **no support yet for publishing legal sources (e.g., CPR, ESPR) or the derived data requirements (legal, sectoral, company)**. This EPIC addresses that gap. ## Why - **Traceability**: Without explicitly modeling legal sources and requirements in STH, it's difficult to demonstrate that a DPP template is legally compliant. - **Validation**: We need to validate whether a given template meets applicable requirements—both top-down (from law to template) and bottom-up (does the template fulfill the required legal/data aspects). - **Standardization**: Standardized requirements enable interoperability across domains (also for SETU and SCSN) ## Objective Explore/develop how we can **standardize and publish legal sources and requirements** as specifications in Semantic Treehouse. ## Scope Designing and prototyping how **legislation and data requirements can be published and linked in Semantic Treehouse**. > :warning: **We do not focus (yet) on how to do the translation** from legislation → requirements, or from requirements → DPP templates. ## Approach - Investigate how RDF instances of legislation (e.g. ESPR in JSON-LD or Turtle) can be imported and visualized in STH (based on the "Source of Norms" ontology). - Design two new specs: **"Legislation Specification"** and **“Requirement Specification”** type in STH for managing lists of requirements and legislative articles. - Explore a standardized manner of described requirements (e.g., MEERP or MEES?), where our colleague Kartik is working on. - Explore visualizations and validation logic for cross-checking DPP templates against legal/data requirements. - Nice to have: Prototype mappings between requirements and DPP templates using existing STH mapping tools. ## Solutions/Designs  **Legislation Spec** Support for RDF-based legal documents as STH instances. See semantic-treehouse#1342 **Requirement Spec** Create a **requirements spec** in STH that is nothing more than a flat list of requirements, which we define by analyzing the CPR contents. * element label = requirement ID/name * definition = requirement in our own words * usage note = describing assumptions we had to make or anything else about our confidence in this requirement * Look into the possibility to import the CPR as a graph (We have a graph version of the **source CPR** thanks to the Norm Engineering people) so that we don't need usage notes but explicit, formal links to articles as entities in the graph. This opens up a interesting querying possibilities (e.g. "article 22.5 has been changed in the final CPR version, give me the requirements that were linked to this article") ## :link: Related input and references - DPP Canvas with focus on **2 and 4:** {width="480" height="270"} - Norm Engineering approach using the _Source of Norms Ontology_ to capture legalisation in a machine readable form.