ORDA: Research Access Ontology

Abstract

ORDA models the process by which researchers apply to obtain access to platform data under Article 40 of the EU Digital Services Act (Regulation 2022/2065), for the purpose of studying systemic risks. It covers the actors involved, the request lifecycle, the data made available, and the safeguards attached to it.

The ontology's organising distinction is between the two access routes that Article 40 creates: the Art. 40(4) route, in which a request for non-public data is mediated by a Digital Services Coordinator (DSC), and the Art. 40(12) route, in which publicly accessible data is requested directly from the platform without intermediation.

Status of this Document

Table of Contents

• 1. Abstract
• 2. Status of this Document
• 3. Introduction
• 3.1. The two access routes
• 4. Namespaces and Conventions
• 5. Model Overview
• 5.1. Axiomatic commitments
• 5.2. Deliberate non-disjointness
• 6. Vocabulary Index
• 7. Classes
• 8. Object Properties
• 9. Datatype Properties
• 10. Request Status Scheme
• 11. Designated Platforms
• 12. Reused Vocabularies
• 13. Example Data
• 14. Conformance Notes

3. Introduction

Article 40 of the Digital Services Act obliges providers of Very Large Online Platforms (VLOPs) and Very Large Online Search Engines (VLOSEs) to give researchers access to data for studying systemic risks in the European Union. Delegated Regulation 2025/2050 sets out the procedure for the non-public (40(4)) data route. The process spans several actors (researchers and their institutions, the Digital Services Coordinator of establishment, the coordinator of the researcher's own member state, and the platform), and moves through a sequence of assessments with defined outcomes.

ORDA gives that process a machine-readable vocabulary. It types the requests, the parties, the assessments and their statuses, the data catalogues platforms must publish, and the technical, legal and organisational safeguards attached to an access modality. It reuses established vocabularies wherever one already covers the existing concepts (listed in section 12), and defines new terms only for what is specific to the Article 40 regime.

This draft scopes the model to the application stage: submitting a request, assessing it, and issuing the reasoned request that obliges the platform to supply data. Decision records, procedural deadlines, dispute settlement and research outputs are named in the legislation but are not yet modelled.

3.1 The two access routes

4. Namespaces and Conventions

Terms are written throughout as prefixed names. Terms in the orda namespace are defined by this ontology; all others are reused from the vocabulary that defines them, and each such term carries an rdfs:isDefinedBy assertion naming its source. The table below lists only those prefixes for which terms actually appear.

5. Model Overview

The diagram traces a research project from its questions through to the data it receives, and from a systemic risk through to the measure taken against it. It is a summary, not a full rendering of the vocabulary; the term entries below are authoritative.

%%{init:{'theme':'base','themeVariables':{'background':'#ffffff','primaryColor':'#ffffff','primaryTextColor':'#000000','primaryBorderColor':'#000000','secondaryColor':'#ffffff','secondaryTextColor':'#000000','secondaryBorderColor':'#000000','tertiaryColor':'#ffffff','tertiaryTextColor':'#000000','tertiaryBorderColor':'#000000','lineColor':'#000000','textColor':'#000000','edgeLabelBackground':'#ffffff','nodeTextColor':'#000000','fontFamily':'sans-serif','fontSize':'14px'},'flowchart':{'htmlLabels':false,'useMaxWidth':true,'nodeSpacing':50,'rankSpacing':70,'padding':10}}}%%
flowchart TD
  RQ["ResearchQuestion"] --> RP["ResearchProject"]
  RP -->|investigates| SR["SystemicRisk"]
  SR -->|riskArisesOn| DP["DataProvider<br/>VLOP / VLOSE"]
  DP -->|hasMitigationMeasure| MM["SystemicRisk<br/>MitigationMeasure"]
  MM -->|mitigatesRisk| SR
  RP -->|assessesMitigationMeasure| MM
  RP --> R4["Art40_4_DataAccessRequest<br/>non-public data"]
  RP --> R12["Art40_12_DataAccessRequest<br/>public data"]
  R4 -->|includesResearcher| AR["ApplicantResearcher"]
  R4 -->|submittedVia| PT["DSADataAccessPortal"]
  R4 -->|assessedBy| DSC["DSCofEstablishment"]
  R4 -->|hasExpertConsultation| EC["ExpertConsultation"]
  R4 -->|resultsIn| RR["ReasonedRequest"]
  RR -->|issuedTo| DP
  RR -->|hasAccessModality| AM["AccessModality"]
  DP -->|hasDataCatalogue| CT["DSADataCatalogue"]
  CT -->|catalogueEntry| DI["Distribution"]
  R12 -->|requestedFrom| DP
  R4 -.->|hasStatusEvent| SE["StatusEvent"]
  SE -.->|eventStatus| SC["RequestStatusScheme"]

Figure 1. Core classes and relations. The left branch is the Art. 40(4) mediated route; the right branch is the Art. 40(12) direct route. The Art. 34 risk and the Art. 35 measure taken against it sit above both, as the object the access is sought to study.

5.1 Axioms

The vocabulary is axiomatised rather than left as a bare vocabulary. Six kinds of axiom carry most of that weight, and each term entry below records the ones that apply to it.

5.2 Deliberate non-disjointness

Four overlaps are intentional and should not be "fixed" by adding disjointness axioms.

• orda:DSCofEstablishment and orda:DSCofMemberState, where the researcher's institution and the platform are established in the same member state, one authority holds both roles.
• orda:LegalModality, orda:OrganisationalModality and orda:TechnicalModality: under Delegated ACT Art. 9 modalities combine. A secure enclave governed by a confidentiality undertaking is both technical and legal, and disjointness would force it to be split into two unrelated individuals.
• orda:ApplicantResearcher and orda:VettedResearcher: a researcher named on an application may already hold vetted status. orda:PrincipalResearcher is a sub-class of the former, so the principal researcher is always among the applicants.
• orda:NecessityStatement and orda:ProportionalityStatement: Art. 40(8)(e) states a single conjoint test, requiring the application to demonstrate that access and the time frames requested are "necessary for, and proportionate to" the research purpose. An application may discharge both limbs in one passage of text, so a single statement may carry both types; disjointness would force such a passage to be duplicated into two individuals.

6. Vocabulary Index

Classes (42)

AccessJustification, AccessModality, AmendmentRequest, ApplicantResearcher, Art40_12_DataAccessRequest, Art40_4_DataAccessRequest, CivicDiscourseRisk, CSVDistribution, DataAccessRequest, DataManagementPlan, DataProvider, DigitalServicesCoordinator, DSADataAccessPortal, DSADataCatalogue, DSCofEstablishment, DSCofMemberState, EthicalReview, ExpertConsultation, FundamentalRightsRisk, IllegalContentRisk, LegalModality, MethodologicalReview, NecessityStatement, OrganisationalModality, PlatformAccount, PrincipalResearcher, ProportionalityStatement, PublicWellbeingRisk, ReasonedRequest, ResearchActivity, Researcher, ResearchMethod, ResearchProject, ResearchQuestion, ResearchTopic, StatusEvent, SystemicRisk, SystemicRiskMitigationMeasure, TechnicalModality, VeryLargeOnlinePlatform, VeryLargeOnlineSearchEngine, VettedResearcher

Object Properties (60)

affiliatedWith, amendmentOutcome, amendsRequest, appliesMeasure, assessedBy, assessesMitigation, assessesMitigationMeasure, catalogueEntry, consultationRequestedBy, containsHistory, dataCatalogueOf, dataRequestedBy, employsMethod, eventActor, eventStatus, hasAccessJustification, hasAccessModality, hasAccount, hasActivities, hasAffiliatedResearcher, hasDataAccessRequest, hasDataCatalogue, hasDataManagementPlan, hasDirectRequest, hasExpertConsultation, hasMeasure, hasMethod, hasMitigationMeasure, hasParticipant, hasResearchActivity, hasResearchQuestion, hasReview, hasStatusEvent, hasSystemicRisk, hasTopic, includesResearcher, initiallyAssessedBy, investigates, isCatalogueEntryOf, isPartOf, issuedBy, issuedTo, isTargetOf, mitigatesRisk, participatesIn, publishedIn, questionInvestigates, referencesDataCatalogue, requestedBy, requestedFrom, requestsData, requestStatus, resultsFrom, resultsIn, riskArisesOn, submittedBy, submittedRequest, submittedVia, suggestsModality, targets

Datatype Properties (13)

accessEndDate, accessStartDate, amendmentGrounds, eventDate, hasPublicationCommitment, independenceDeclaration, projectEndDate, projectStartDate, projectTitle, publicationTimeline, requestDate, researcherEmail, researcherName

Individuals (32)

StatusAmendmentAccepted, StatusAmendmentRejected, StatusAmendmentRequested, StatusDataProvided, StatusInMediation, StatusReasonedRequestFormulated, StatusRejected, StatusSubmitted, StatusTerminated, StatusUnderAssessment, RequestStatusScheme, AliExpressVLOP, AmazonStoreVLOP, AppStoreVLOP, BingVLOSE, BookingVLOP, FacebookVLOP, GoogleMapsVLOP, GooglePlayVLOP, GoogleSearchVLOSE, GoogleShoppingVLOP, InstagramVLOP, LinkedInVLOP, PinterestVLOP, SnapchatVLOP, TikTokVLOP, WikipediaVLOP, XVLOP, YouTubeVLOP, ZalandoVLOP, StandardContractualClauses, TransferImpactAssessment

7. Classes

57 classes are defined by ORDA, listed alphabetically.

orda:AccessJustification

A statement made in a data access application justifying the access sought. DSA Art. 40(8)(e) requires an application to demonstrate that access to the data and the time frames requested are necessary for, and proportionate to, the purposes of the research.

orda:AccessModality

The technical, legal and organisational arrangement through which a VLOP or VLOSE provides data to vetted researchers, as determined by the DSC of establishment per DA Art. 9.

orda:AmendmentRequest

A request by a VLOP or VLOSE to amend a reasoned request under DSA Art. 40(5), submitted within 15 days of receipt. Grounds: (a) platform does not have access to the requested data, or (b) access would create significant vulnerabilities in service security or protection of confidential information.

orda:ApplicantResearcher

A researcher named on a data access application. Every application must name at least one. An applicant researcher may or may not also be the principal researcher, and may or may not already hold vetted researcher status.

orda:Art40_12_DataAccessRequest

A data access request under DSA Art. 40(12) for publicly accessible platform data. Submitted directly to the platform without DSC intermediation.

orda:Art40_4_DataAccessRequest

A data access application under DSA Art. 40(4) for non-public platform data.

orda:CivicDiscourseRisk

DSA Art. 34(1)(c): systemic risks of negative effects on civic discourse, electoral processes or public security.

orda:CSVDistribution

A dcat:Distribution in CSV format (dct:format = EU file-type/CSV) that carries a csvw:Schema via dct:hasFormat, describing column names, datatypes and constraints per the CSVW specification (https://w3c.github.io/csvw/syntax/).

orda:DataAccessRequest

A formal request by a researcher to access data from a VLOP or VLOSE under DSA Art. 40. Superclass for the two distinct processes: Art. 40(4) non-public data via DSC, and Art. 40(12) public data direct to platform. Every application must propose the period of access it seeks, via orda:accessStartDate and orda:accessEndDate, and must carry both limbs of the Art. 40(8)(e) demonstration via orda:hasAccessJustification. Both requirements sit on this superclass rather than on the Art. 40(4) sub-class because Art. 40(12) cross-references Art. 40(8) points (b) to (e), so the necessity and proportionality condition, and with it the demonstration of the time frames requested, binds on both routes.

orda:DataManagementPlan

A plan governing how accessed data is stored, protected and deleted. Retention, deletion and security requirements are expressed with DPV terms: dpv:StorageDuration and dpv:StorageDeletion via dpv:hasStorageCondition, and dpv:TechnicalOrganisationalMeasure via dpv:hasTechnicalOrganisationalMeasure. The only research-side safeguard given an ORDA class of its own: it is a named artefact of the Art. 40 vetting process and carries axioms of its own. Every other protective measure a researcher applies is documented directly with DPV terms under dpv:TechnicalOrganisationalMeasure rather than through an ORDA class hierarchy. Not to be confused with orda:SystemicRiskMitigationMeasure, which is a measure taken by a platform and studied by researchers, not one they are bound by.

orda:DataProvider

A superset including VLOPs and VLOSEs

orda:DigitalServicesCoordinator

A national authority designated under DSA Art. 49 to oversee DSA compliance and handle researcher data access applications under Art. 40.

orda:DSADataAccessPortal

The centralised digital infrastructure established under Delegated ACT Art. 3 through which Art. 40(4) applications are submitted, reasoned request overviews are published, and the data access process is managed. Operated by the European Commission.

orda:DSADataCatalogue

A catalogue of available data assets published by a VLOP or VLOSE per DA Art. 6(4), describing data structure, metadata, and suggested access modalities to help researchers formulate applications.

orda:DSCofEstablishment

The DSC of the member state where the VLOP or VLOSE is primarily established in the EU. Makes the final decision on vetting, formulates reasoned requests, and determines access modalities. Per DSA Art. 40(4) and (8). Deliberately NOT disjoint with orda:DSCofMemberState: where the researcher's institution and the platform are established in the same member state, one authority holds both roles. Do not add a disjointness axiom between them.

orda:DSCofMemberState

The DSC of the member state where the researcher's institution is based. Under Art. 40(9), conducts initial assessment and forwards to the DSC of establishment. Deliberately NOT disjoint with orda:DSCofEstablishment; the same authority can hold both roles.

orda:EthicalReview

Independent ethics committee or IRB review confirming the research design meets ethical standards before data access is granted. Distinct from orda:ExpertConsultation, which is the DSC-initiated consultation under Delegated ACT Art. 14: an ethical review is commissioned by the research side, not by the assessing authority.

orda:ExpertConsultation

An optional consultation with independent experts or advisory mechanisms during the assessment of an Art. 40(4) application, per DA Art. 14.

orda:FundamentalRightsRisk

DSA Art. 34(1)(b): systemic risks of negative effects on fundamental rights.

orda:IllegalContentRisk

DSA Art. 34(1)(a): systemic risks from dissemination of illegal content.

orda:LegalModality

An access modality whose character is primarily legal, e.g. contractual undertakings, confidentiality agreements, transfer mechanisms.

orda:MethodologicalReview

Review of research methodology to ensure data requested is necessary and proportionate to the stated research objectives.

orda:NecessityStatement

The Art. 40(8)(e) demonstration addressing necessity: that the applicant cannot answer the research question without the data and time frames requested.

orda:OrganisationalModality

An access modality realised through organisational measures, e.g. on-site-only access, mediation by a trusted third party.

orda:PlatformAccount

An account on a platform, held by a person, organisation, group or automated agent. ActivityStreams has no single class for this.

orda:PrincipalResearcher

The principal researcher who is the primary contact for a data access application and bears responsibility for the request. Per DA Art. 2 and 7.

orda:ProportionalityStatement

The limb of the Art. 40(8)(e) demonstration addressing proportionality: that the scope of the data and the time frames requested is no wider than the research purpose warrants. Deliberately not declared disjoint from orda:NecessityStatement; see that term.

orda:PublicWellbeingRisk

DSA Art. 34(1)(d): systemic risks of negative effects on public health, physical and mental wellbeing, or gender-based violence.

orda:ReasonedRequest

A formally reasoned request issued by the DSC of establishment to a VLOP or VLOSE under DSA Art. 40(4), triggering the platform's obligation to provide data. Legally distinct from the researcher's application. Content requirements specified in DA Art. 10. Published in the DSA Data Access Portal per DA Art. 11.

orda:ResearchActivity

The actions taken with the data used. (e.g data analysis, modeling, comparison, etc.)

orda:Researcher

A researcher who may participate in the DSA Art. 40 data access process. Broader class encompassing all researcher roles.

orda:ResearchMethod

No definition is given in the ontology.

orda:ResearchProject

A research project that processes data, defined as a subclass of dpv:Process. Under DSA Art. 40, may submit data access requests to investigate systemic risks or assess systemic risk mitigation measures within the EU.

orda:ResearchQuestion

No definition is given in the ontology.

orda:ResearchTopic

No definition is given in the ontology.

orda:StatusEvent

A timestamped event recording a status change in the lifecycle of a data access request. Captures who triggered the change, when, and what the new status is.

orda:SystemicRisk

A societal risk as defined under DSA Art. 34, stemming from the design or functioning of a VLOP or VLOSE within the EU. Distinct from dpv:Risk which covers data processing risks.

orda:SystemicRiskMitigationMeasure

A measure put in place by a VLOP or VLOSE under DSA Art. 35 to mitigate the systemic risks identified under Art. 34. Specialises dpv:RiskMitigationMeasure to the DSA systemic-risk setting, mirroring the way orda:SystemicRisk is kept distinct from dpv:Risk. Named for the risks it addresses, and so for the fact that it is an object of study: it is a measure taken by the platform, which a research project may investigate under Art. 40(4) for adequacy, efficiency and impact. It is not a safeguard the researcher is bound by. Those are documented with DPV terms under dpv:TechnicalOrganisationalMeasure, reached via orda:hasMeasure, orda:appliesMeasure and orda:DataManagementPlan.

orda:TechnicalModality

An access modality realised through technical controls, e.g. secure enclaves, restricted APIs, pseudonymisation, query-only access.

orda:VeryLargeOnlinePlatform

A platform designated as a VLOP under DSA Art. 33, with over 45 million monthly active users in the EU.

orda:VeryLargeOnlineSearchEngine

A search engine designated as a VLOSE under DSA Art. 33.

orda:VettedResearcher

A researcher vetted under DSA Art. 40(8) by a DSC to access non-public platform data under Art. 40(4). Must be affiliated with a research organisation per Dir. 2019/790 Art. 2(1). Not required to be based in the EU; the systemic risk being researched must occur within the EU.

8. Object Properties

55 object properties are defined by ORDA.

orda:affiliatedWith

Links a vetted researcher to the research organisation they are affiliated with. Art. 40(8)(a) DSA requires affiliation with a research organisation within the meaning of Dir. (EU) 2019/790 Art. 2(1); FRAPO has no single class for this, so the range is the union of its university, college and research-institute classes.

orda:amendmentOutcome

The outcome of an amendment request submitted under Art. 40(5) DSA.

orda:amendsRequest

Links an amendment request to the reasoned request it seeks to modify under Art. 40(5) DSA.

orda:appliesMeasure

Links an access modality to the technical, legal or organisational measures that constitute it, e.g. a technical modality applying pseudonymisation, or a legal modality applying standard contractual clauses.

orda:assessedBy

Links an Art. 40(4) data access application to the DSC of establishment that makes the final vetting decision and formulates the reasoned request.

orda:assessesMitigation

Links a research project to the VLOP or VLOSE whose systemic risk mitigation measures (under Art. 35 DSA) it assesses for adequacy, efficiency and impact. Shares domain with orda:investigates per Art. 40(4).

orda:assessesMitigationMeasure

Links a research project to the specific Art. 35 systemic risk mitigation measure whose adequacy, efficiency and impact it assesses. Refines orda:assessesMitigation, which names only the platform.

orda:catalogueEntry

Links a DSA data catalogue to a data asset it describes, per DA Art. 6(4). This is the property a researcher follows from a catalogue to the distributions they can then request via orda:requestsData.

orda:consultationRequestedBy

Links an expert consultation to the DSC that requested it.

orda:containsHistory

Links a dcat:Distribution to the collection of platform activity it serialises. This is what connects the request side of the ontology to the content side: a researcher follows orda:catalogueEntry to a distribution, requests it with orda:requestsData, and reads what it holds from the collection reached here. The range is the stock as:OrderedCollection: ORDA does not currently classify activity histories by the ActivityStreams type of their members, so the category of data a request concerns is carried by the members themselves rather than by a class over them.

orda:dataCatalogueOf

Links a DSA data catalogue to the VLOP or VLOSE that published it.

orda:dataRequestedBy

Links a dcat:Distribution to the data access requests that seek it. The reverse view matters to both assessing parties: a platform gauging the cumulative burden of the applications made against one dataset, and a DSC testing necessity and proportionality under Art. 40(8)(e) across the requests competing for the same data.

orda:employsMethod

Links a research activity to the research method it employs.

orda:eventActor

The entity (DSC, platform, researcher) that triggered this status change.

orda:eventStatus

Links a status event to the status it represents, drawn from orda:RequestStatusScheme.

orda:hasAccessJustification

Links a data access request to a statement in the application justifying the access sought. DSA Art. 40(8)(e) requires the application to demonstrate that the data and the time frames requested are necessary for, and proportionate to, the purposes of the research. Every data access request must carry at least one orda:NecessityStatement and at least one orda:ProportionalityStatement; a single statement addressing both limbs may be typed as both.

orda:hasAccessModality

Links a data access request (Art. 40(4) or Art. 40(12)), or the reasoned request formulated from it, to the access modality. At application stage the modality is researcher-proposed; for Art. 40(4) reasoned requests it is determined by the DSC of establishment per DA Art. 9.

orda:hasAccount

Links a real-world person to a platform account they hold. ActivityStreams has no term for this: it models accounts, not the people behind them, and as:Person is an account held by a human rather than the human themselves.

orda:hasActivities

Links a platform account to a collection of its activities.

orda:hasDataAccessRequest

Links a research project to the data access requests submitted in support of it.

orda:hasDataCatalogue

Links a VLOP or VLOSE to its published DSA data catalogue per DA Art. 6(4).

orda:hasDataManagementPlan

Links a research project to the data management plan that governs how accessed data will be stored, processed and protected.

orda:hasDirectRequest

Links a VLOP or VLOSE to the Art. 40(12) public data requests made directly to it, without DSC intermediation. Kept distinct from orda:isTargetOf, which reaches requests on the Art. 40(4) route through the DSC, so that a platform can separate the applications it receives and answers itself from those arriving as a reasoned request.

orda:hasExpertConsultation

Links an Art. 40(4) application to an expert consultation conducted during its assessment per DA Art. 14.

orda:hasMeasure

Links a dcat:Distribution to a technical, legal or organisational measure governing how the data it describes may be accessed and handled.

orda:hasMethod

Links a research project to the research methods it employs.

orda:hasMitigationMeasure

Links a VLOP or VLOSE to a systemic risk mitigation measure it has put in place under DSA Art. 35.

orda:hasParticipant

Links a research project to the researchers participating in it. A project may have many.

orda:hasResearchActivity

Links a research project to the research activities it comprises.

orda:hasResearchQuestion

Links a research project to the research questions it addresses.

orda:hasReview

Links a research method to the expert consultation (e.g. orda:MethodologicalReview) that reviews it for necessity and proportionality.

orda:hasStatusEvent

Links a data access request to a timestamped status change event in its lifecycle.

orda:hasSystemicRisk

Links a VLOP or VLOSE to the systemic risks stemming from the design or functioning of its service, per DSA Art. 34(1). The risk profile of a named platform is the question Art. 34 puts to the provider itself and the question Art. 40 research is commissioned to test, so it is reachable from the platform as well as from the risk.

orda:hasTopic

Links a research project to the research topics it covers.

orda:includesResearcher

Links a data access request to every researcher covered by it, including the principal researcher (orda:submittedBy is a sub-property of this). Per DA Art. 10, the reasoned request must identify all researchers. Deliberately has no inverse: reverse traversal from a person to the applications naming them is offered for the principal researcher alone, via orda:submittedRequest, because it is the principal who is the primary contact and bears responsibility under Delegated ACT Art. 2 and 7.

orda:initiallyAssessedBy

Links an Art. 40(4) application (submitted via the researcher's own member state under Art. 40(9)) to the DSC that conducted the initial assessment before forwarding to the DSC of establishment.

orda:investigates

Links a research project to the DSA systemic risk category it investigates under Art. 34(1). Distinct from dpv:hasRisk which covers data processing risks.

orda:isCatalogueEntryOf

Links a dcat:Distribution to the DSA data catalogue that lists it. Lets a dataset name the catalogue it was found in, which is what an applicant must cite when identifying the data sought and what a DSC checks the request against.

orda:isPartOf

Links a data access request to the research project it supports.

orda:issuedBy

Links a reasoned request to the DSC of establishment that formulated it.

orda:issuedTo

Links a reasoned request to the VLOP or VLOSE to which it is addressed.

orda:isTargetOf

Links a VLOP or VLOSE to the data access requests directed at it.

orda:mitigatesRisk

Links an Art. 35 mitigation measure to the Art. 34 systemic risk it is put in place to address. Closes the chain the DSA draws between the two articles: Art. 35(1) requires measures that are reasonable, proportionate and effective in mitigating the risks identified under Art. 34, so a measure is only assessable against the risk it names. Without it a research project could assess a measure via orda:assessesMitigationMeasure without the model ever recording what the measure was for.

orda:participatesIn

Links a researcher to a research project they participate in.

orda:publishedIn

Links a reasoned request to the DSA Data Access Portal where its overview is published per DA Art. 11.

orda:questionInvestigates

Links a research question to the DSA systemic risk it investigates. Distinct from orda:investigates whose domain is orda:ResearchProject. Research topics are attached at project level via orda:hasTopic.

orda:referencesDataCatalogue

Links a data access request to the platform data catalogue it references.

orda:requestedBy

Links an amendment request to the VLOP or VLOSE that submitted it under Art. 40(5) DSA.

orda:requestedFrom

Links an Art. 40(12) public data request directly to the platform, without DSC intermediation.

orda:requestsData

Links a data access request to the dcat:Distribution it requests from the platform.

orda:requestStatus

The current status of the request, drawn from orda:RequestStatusScheme. For full history, see orda:hasStatusEvent.

orda:resultsFrom

Links a reasoned request to the Art. 40(4) application it was formulated from.

orda:resultsIn

Links an Art. 40(4) data access application to the reasoned request formulated by the DSC of establishment. The reasoned request is the operative legal instrument that triggers the platform's obligation to provide data.

orda:riskArisesOn

Links a systemic risk to the VLOP or VLOSE from whose design or functioning it stems, per DSA Art. 34(1).

orda:submittedBy

Links a data access request to the principal researcher who submitted it. Per DA Art. 2 and 7, the principal researcher is the primary contact and bears responsibility for the application. Paired with orda:submittedRequest, and confined to the principal: reverse traversal from a researcher to their applications is deliberately not offered for the wider group named under orda:includesResearcher, which therefore has no inverse.

orda:submittedRequest

Links a principal researcher to the data access requests they submitted. Inverse of orda:submittedBy, and confined to the principal: a researcher merely named on an application under orda:includesResearcher is not reachable this way.

orda:submittedVia

Links an Art. 40(4) data access application to the DSA Data Access Portal through which it was submitted. Per DA Art. 3, all Art. 40(4) applications must be submitted through this portal.

orda:suggestsModality

Links a data access request to the access modality proposed by the researcher. Distinct from orda:hasAccessModality on the ReasonedRequest, which records the modality determined by the DSC of establishment per DA Art. 9.

orda:targets

Links a data access request to the VLOP or VLOSE from which data is requested.

9. Datatype Properties

13 datatype properties are defined by ORDA.

orda:accessEndDate

The date on which the period of access ends. Required on a data access request, where it is proposed by the researcher: DSA Art. 40(8)(e) requires the application to demonstrate that the data and 'the time frames requested' are necessary and proportionate, which presupposes that the application states them. Optional on a reasoned request, where per DA Art. 10 the DSC determines the period of access rather than proposing it, and on an amendment request, where a platform may propose a different period under DSA Art. 40(5).

orda:accessStartDate

The date from which the data is to be made available. Required on a data access request, where it is proposed by the researcher: DSA Art. 40(8)(e) requires the application to demonstrate that the data and 'the time frames requested' are necessary and proportionate, which presupposes that the application states them. Optional on a reasoned request, where per DA Art. 10 the DSC determines the period of access rather than proposing it, and on an amendment request, where a platform may propose a different period under DSA Art. 40(5).

orda:amendmentGrounds

The grounds for the amendment request per Art. 40(5) DSA: (a) platform does not have access to the data, or (b) access would create significant vulnerabilities.

orda:eventDate

The date on which this status change occurred.

orda:hasPublicationCommitment

Whether the researcher has committed to publishing results publicly and free of charge within a reasonable period, as required by Art. 40(8)(g) DSA.

orda:independenceDeclaration

A declaration by the researcher that they are independent from commercial interests in relation to the specific research project, as required by Art. 40(8)(b) DSA.

orda:projectEndDate

No definition is given in the ontology.

orda:projectStartDate

No definition is given in the ontology.

orda:projectTitle

No definition is given in the ontology.

orda:publicationTimeline

The planned timeline for making research results publicly available, e.g. 'within 12 months of completion'.

orda:requestDate

The date on which the data access request was submitted.

orda:researcherEmail

No definition is given in the ontology.

orda:researcherName

No definition is given in the ontology.

10. Request Status Scheme

The lifecycle of a data access request is tracked with a SKOS concept scheme. The current state is carried by orda:requestStatus, whose range is enumerated over exactly these concepts; the full history is a chain of orda:StatusEvent individuals, each carrying one date and one status.

orda:RequestStatusScheme

Controlled vocabulary for the lifecycle stages of a DSA Art. 40 data access request.

orda:StatusAmendmentAccepted

The DSC of establishment accepted the platform's amendment request under Art. 40(5) DSA and amended the reasoned request accordingly.

orda:StatusAmendmentRejected

The DSC of establishment rejected the platform's amendment request under Art. 40(5) DSA; the reasoned request stands as issued.

orda:StatusAmendmentRequested

The platform has submitted an amendment request under Art. 40(5) DSA within 15 days of receiving the reasoned request.

orda:StatusDataProvided

The platform has provided the requested data under the modalities specified in the reasoned request.

orda:StatusInMediation

The reasoned request is subject to dispute settlement per DA Art. 13, with up to 40 additional working days.

orda:StatusReasonedRequestFormulated

The DSC of establishment has formulated a reasoned request and issued it to the platform.

orda:StatusRejected

The application was rejected by the DSC of establishment.

orda:StatusSubmitted

Application submitted via the DSA Data Access Portal (Art. 40(4)) or directly to the platform (Art. 40(12)).

orda:StatusTerminated

Access has been terminated by the DSC under Art. 40(10) because the vetted researcher no longer meets Art. 40(8) conditions.

orda:StatusUnderAssessment

Application is being assessed by the DSC of establishment against Art. 40(8) prerequisites. The DSC has 80 working days to decide (DA Art. 7).

11. Designated Platforms

Individuals for the platforms and search engines designated under DSA Art. 33, each located in its member state of establishment. The list is illustrative rather than authoritative; the Commission maintains the definitive register.

orda:AliExpressVLOP

No definition is given in the ontology.

orda:AmazonStoreVLOP

No definition is given in the ontology.

orda:AppStoreVLOP

No definition is given in the ontology.

orda:BingVLOSE

No definition is given in the ontology.

orda:BookingVLOP

No definition is given in the ontology.

orda:FacebookVLOP

No definition is given in the ontology.

orda:GoogleMapsVLOP

No definition is given in the ontology.

orda:GooglePlayVLOP

No definition is given in the ontology.

orda:GoogleSearchVLOSE

No definition is given in the ontology.

orda:GoogleShoppingVLOP

No definition is given in the ontology.

orda:InstagramVLOP

No definition is given in the ontology.

orda:LinkedInVLOP

No definition is given in the ontology.

orda:PinterestVLOP

No definition is given in the ontology.

orda:SnapchatVLOP

No definition is given in the ontology.

orda:TikTokVLOP

No definition is given in the ontology.

orda:WikipediaVLOP

No definition is given in the ontology.

orda:XVLOP

No definition is given in the ontology.

orda:YouTubeVLOP

No definition is given in the ontology.

orda:ZalandoVLOP

No definition is given in the ontology.

Further individuals defined by ORDA:

orda:StandardContractualClauses

European Commission-approved Standard Contractual Clauses (SCCs) governing the transfer of personal data to a third country outside the EU/EEA under GDPR Art. 46(2)(c). Typed directly as a dpv:LegalMeasure: the transfer mechanism is a research-side safeguard, and ORDA documents those with DPV rather than through a class hierarchy of its own.

orda:TransferImpactAssessment

An assessment required before transferring personal data to a third country, evaluating whether the destination country's legal framework ensures adequate protection equivalent to EU standards. Typed as a dpv:RiskAssessment rather than a legal measure: what it produces is an appraisal of the destination framework, on which the choice of transfer mechanism then turns.

12. Reused Vocabularies

ORDA reuses 12 external vocabularies. Terms are listed here with the assertions ORDA makes about them. Where ORDA narrows an imported term, by giving it a domain, a range or a class restriction it does not carry in its source vocabulary, that is noted in the term's entry.

12.1 DPV: Data Privacy Vocabulary

dpv:Adult

A natural person that is not a child i.e. has attained the age of maturity.

dpv:Applicant

Data subjects that have applied for something.

dpv:AsylumSeeker

Data subjects that are asylum seekers.

dpv:Child

A natural person that has not attained the age of maturity.

dpv:Citizen

Data subjects that are citizens of a jurisdiction.

dpv:Client

Data subjects that are clients of a service.

dpv:Consumer

Data subjects that consume goods or services.

dpv:Customer

Data subjects that are customers of a service or product.

dpv:DataSubject

A natural person whose personal data is processed. In the Art. 40 context, these are platform users whose data researchers access. Being a dpv:NaturalPerson, an instance may be linked via orda:hasAccount to the platform accounts it holds; the account itself is an orda:PlatformAccount. The two are distinct (an account is not the person holding it), but ORDA does not assert disjointness between them, so keeping them apart is a modelling convention here rather than something a reasoner enforces. The DPV entity hierarchy and the ActivityStreams actor types are kept independent.

dpv:ElderlyDataSubject

Data subjects that are considered elderly (i.e. based on age).

dpv:Employee

Data subjects that are employees.

dpv:GuardianOfDataSubject

Guardian(s) of a data subject.

dpv:HumanSubject

A human that is the subject of a specific context, such as Data Subject for data or AI Subject for AI.

dpv:Immigrant

Data subjects that are immigrants.

dpv:JobApplicant

Data subjects that have applied for a job.

dpv:Justification

A form of documentation providing reasons, explanations, or justifications. ORDA places orda:AccessJustification beneath this so that the Art. 40(8)(e) demonstration is discoverable as a DPV justification, without asserting anything about the DPV term itself.

dpv:LegalEntity

No definition is given in the ontology.

dpv:Location

No definition is given in the ontology.

dpv:Member

Data subjects that are members of a group or organisation.

dpv:MentallyVulnerableDataSubject

Data subjects that are considered mentally vulnerable.

dpv:NaturalPerson

A human. ORDA uses this as the domain of orda:hasAccount rather than coining a class for the person behind a platform account. DPV already names the concept, so ORDA states only the relation. ORDA adds no axioms to the term itself: it is deliberately not declared disjoint from orda:PlatformAccount, so the term behaves exactly as DPV defines it.

dpv:NonCitizen

Data subjects that are not citizens of a jurisdiction.

dpv:ParentOfDataSubject

Parent(s) of a data subject.

dpv:Participant

Data subjects that participate in an activity or process.

dpv:Patient

Data subjects that receive medical attention, treatment, or care.

dpv:Student

Data subjects that are students.

dpv:Subscriber

Data subjects that subscribe to a service.

dpv:SupraNationalUnion

No definition is given in the ontology.

dpv:Tourist

Data subjects that are tourists.

dpv:User

Data subjects that use a service or product.

dpv:Visitor

Data subjects that visit a place or service.

dpv:VulnerableDataSubject

Data subjects which should be considered 'vulnerable' and therefore would require additional measures and safeguards.

12.2 ActivityStreams 2.0 Vocabulary

ORDA types the contents of platform data with W3C ActivityStreams 2.0. Terms are stubbed locally rather than imported: the ActivityStreams OWL file is non-normative and states deliberately loose domains and ranges, so only the terms ORDA actually uses are declared here, each carrying rdfs:isDefinedBy naming the source. ORDA coins no activity or collection types of its own at present: an account's activity and a distribution's contents are both reached as a stock as:OrderedCollection, and the classification of histories by the ActivityStreams type of their members is deferred. The one gap ORDA does fill is the relation between a person and the accounts they hold (orda:hasAccount, over DPV's dpv:NaturalPerson), since ActivityStreams defines no common actor class and orda:PlatformAccount supplies the union of its five actor types.

as:Application

A software application holding a platform account. Together with as:Service this covers automated or bot accounts, which have no dedicated ActivityStreams type.

as:Collection

A set of objects, linked by as:items. Retained as the domain of as:items and as the superclass of as:OrderedCollection, which ORDA uses as the container for platform activity.

as:Group

No definition is given in the ontology.

as:Object

The root of the ActivityStreams type hierarchy.

as:OrderedCollection

A collection whose members carry a defined order. ActivityStreams expresses the ordering in JSON-LD serialisation rather than through a distinct RDF property, so members are still reached via as:items.

as:Organization

No definition is given in the ontology.

as:Person

An account held by a natural person. Distinct from dpv:NaturalPerson: as:Person is the account, not the human behind it, and one human may hold several. The two are related by orda:hasAccount; ORDA does not assert disjointness between them.

as:Service

No definition is given in the ontology.

as:items

Links a collection to its members. This is how the as:OrderedCollection reached by orda:hasActivities and orda:containsHistory is populated. Note that ActivityStreams defines no 'orderedItems' property; ordering in an as:OrderedCollection is a JSON-LD serialisation concern, so as:items is used for both ordered and unordered collections.

12.3 FRAPO: Funding, Research Administration and Projects Ontology

frapo:College

No definition is given in the ontology.

frapo:Funding

An amount of money available to finance some project or activity. Within ORDA every instance must name the agency providing it, so that the funding disclosure required by Art. 40(8)(b) DSA is reachable from any funded research project.

frapo:FundingAgency

No definition is given in the ontology.

frapo:Grant

No definition is given in the ontology.

frapo:hasEndDate

No definition is given in the ontology.

frapo:hasFundingAgency

Links funding to the agency providing it. Every frapo:Funding instance in ORDA is required to carry one.

frapo:hasGrantNumber

No definition is given in the ontology.

frapo:hasStartDate

No definition is given in the ontology.

frapo:isEmployedBy

No definition is given in the ontology.

frapo:isFundedBy

Links a research project to the funding that finances it. FRAPO defines this property as polymorphic over both the funding and the agency providing it, so the range permits either, but ORDA requires a research project to name its frapo:Funding; the funding agency is reached from there via frapo:hasFundingAgency.

frapo:Project

No definition is given in the ontology.

frapo:ResearchInstitute

No definition is given in the ontology.

frapo:University

No definition is given in the ontology.

12.4 CSV on the Web (CSVW)

csvw:column

Links a csvw:Schema to a csvw:Column description specifying the name, datatype and constraints of one column in the CSV file.

csvw:Column

A description of a single column in a CSV file, specifying its name, datatype, title and constraints per the CSVW specification.

csvw:datatype

The datatype of values in this column, e.g. 'string', 'integer', 'dateTime'. Corresponds to the built-in CSVW datatypes or an XSD type name.

csvw:name

The name of the column as it appears in the CSV header row. Used as the column identifier in CSVW processing.

csvw:required

If true, every row in the CSV must have a non-null value for this column.

csvw:Schema

A schema describing the columns of a CSV file, linked to a dcat:Distribution via dct:hasFormat.

csvw:titles

A human-readable title for the column, used in documentation and display. May be language-tagged.

12.5 DPV Locations extension

loc:DE

No definition is given in the ontology.

loc:EU

The jurisdiction within which DSA systemic risks must occur to trigger Art. 40 data access rights.

loc:IE

No definition is given in the ontology.

loc:LU

No definition is given in the ontology.

loc:NL

No definition is given in the ontology.

12.6 DCMI Metadata Terms

dct:description

Free text supplied by a party to the process (an applicant, a platform or a DSC), as opposed to a value ORDA models structurally. ORDA uses this for descriptive text directly where a subject carries only one such text, as on orda:ResearchProject and on the orda:AccessJustification statements, and makes the narrower properties subproperties of it where a subject carries several, so that orda:independenceDeclaration, orda:publicationTimeline and orda:amendmentGrounds remain individually identifiable while still being reachable generically. Left without a domain deliberately, so that ORDA constrains nothing about the term for importers. Typed here as an owl:DatatypeProperty, which DCMI itself does not commit to.

dct:format

No definition is given in the ontology.

dct:hasFormat

Used here to link a dcat:Distribution to its format-specific schema description (csvw:Schema for CSV, or a foaf:Document URL for JSON Schema).

dct:identifier

The reference under which a data access request is registered, e.g. in the DSA Data Access Portal.

dct:MediaTypeOrExtent

No definition is given in the ontology.

12.7 SKOS Simple Knowledge Organization System

skos:closeMatch

No definition is given in the ontology.

skos:Concept

No definition is given in the ontology.

skos:ConceptScheme

No definition is given in the ontology.

skos:inScheme

No definition is given in the ontology.

12.8 EU Publications Office file-type authority table

filetype:CSV

No definition is given in the ontology.

filetype:JSON

No definition is given in the ontology.

filetype:PDF

No definition is given in the ontology.

12.9 FOAF (Friend of a Friend)

foaf:Agent

No definition is given in the ontology.

foaf:Organization

No definition is given in the ontology.

foaf:Person

No definition is given in the ontology.

12.10 Data Catalog Vocabulary (DCAT)

dcat:Distribution

No definition is given in the ontology.

12.11 European Legislation Identifier (ELI)

eli:LegalResource

A legal resource such as a law, regulation or treaty.

12.12 DPV EU legal extension

legal-eu:DSA

Regulation (EU) 2022/2065. Art. 40 grants vetted researchers access to platform data to investigate systemic risks within the EU.

13. Example Data

Illustrative instance data is distributed separately, in orda-examples.ttl: a worked Art. 40(4) application from a university researcher to a designated platform, with its status history, funding chain, and the CSV, JSON and PDF distributions returned.

It is kept out of the vocabulary file deliberately. Those individuals are described by ORDA rather than defined by it, so they carry no rdfs:isDefinedBy assertion and do not appear as terms in this document. The example file declares its own ontology IRI, https://w3id.org/orda/examples, and imports ORDA.

The example data satisfies every class restriction in this document concretely rather than vacuously: the worked application names a principal researcher who is affiliated with a university, the project names both its grant and the agency funding that grant, and the application carries the Art. 40(8)(g) publication commitment. It also proposes the period of access it seeks and carries both limbs of the Art. 40(8)(e) demonstration as separate orda:NecessityStatement and orda:ProportionalityStatement individuals, each with its text carried by dct:description. The reasoned request then carries a shorter access period than the application proposed, showing the distinction between a researcher proposing a period and the DSC determining one under Delegated ACT Art. 10.

It also exercises the account vocabulary: a dpv:NaturalPerson holds two accounts (one as:Person, one as:Application standing for an automated account), linked by orda:hasAccount. Activity-history instance data is not included while ORDA carries no history classes of its own; the collections reached by orda:containsHistory and orda:hasActivities are plain as:OrderedCollection instances.

14. Conformance Notes

Two limitations are worth stating plainly for anyone reusing this vocabulary.

Scoped out of this draft, and named here so their absence is not mistaken for an oversight: assessment decision records and rejection grounds; the procedural deadlines in DA Art. 7, Art. 40(5) and DA Art. 13; dispute settlement bodies; research outputs and publication records beyond the commitment flag.