This document specifies the SPECIAL usage policy language, which can be used to express both the data subjects’ consent and the data usage policies of data controllers in formal terms, understandable by a computer, so as to automatically verify that the usage of personal data complies with data subjects’ consent.

The ontology defined in this document is publicly available at

This specification was published by the SPECIAL H2020 EU project. It is not a W3C Standard nor is it on the W3C Standards Track. For additional details see the SPECIAL Deliverable D2.5 [[SPECIALD25]].

To participate in the development of this specification, please contact Sabrina Kirrane, the scientific coordinator of the SPECIAL H2020 EU project. If you have questions, want to suggest a feature, or raise an issue, please send a mail to the contact.


The European General Data Protection Regulation (GDPR) brings new challenges for companies, who must provide transparency with respect to personal data processing and sharing within their organisations. Additionally companies must be able to demonstrate that their systems and their business processes comply with usage constraints specified by data subjects.

This document presents the SPECIAL usage policy language developed within the SPECIAL EU H2020 project, which can be used to represent the consent provided by data subjects, and to verify that the real usage of personal data complies with data subjects’ consent.

What is a Usage Policy?

Conceptually, a usage policy is meant to specify a set of authorized operations. According to the GDPR, these policies shall specify clearly which data are collected, what is the purpose of the collection, what processing will be performed, and whether or not the data will be shared with others. Usage policies can consist then of the following five elements, referred to as the minimum core model (MCM):

That is, in abstract, mathematical terms a usage policy is just a set of tuples like:

<data item,purpose,operation,storage,recipient>

,which will be called authorizations, each of which specifies a permitted operation.

A data subject’s consent comprises a usage policy; the authorizations contained in that policy are the operations allowed by the data subject. Dually, the usage policy enforced by a data controller contains the operations that are permitted within the data controller’s organization.

Therefore, the usage policy adopted by the data controller (call it Pc) complies with the usage policy in the data subject’s consent (call it Ps) if and only if all the authorizations in Pc are also authorized by Ps, that is, Pc complies with Ps if and only if

Pc ⊆ Ps (Eq1)

Now we have to define a policy language where this kind of policies can be modelled precisely and unambiguously, possibly by representing large sets of authorizations (tuples) in a concise way. Such policy language should be equipped with an inference engine capable of checking reliably and exhaustively whether policy containments such as (Eq1) hold, whenever Pc and Ps are expressed with the policy language. These are the goals of the next sections.

Audience and scope

This document describes the SPECIAL usage policy language. It is aimed at companies wishing to express both the data subjects’ consent and the data usage policies of data controllers in formal terms. Mechanics of cross-format translation from other formats are not covered here.

Document conventions and namespaces

SPECIAL’s usage policies are encoded in OWL2 [[owl2-primer]]. The sets of aforementioned authorizations that conceptually constitute the policy are naturally represented by OWL2 classes, and single authorizations by class instances. In the following we illustrate the language and provide some examples. The full grammar of policy expressions in BNF format is provided in the BNF Section. The namespace for the SPECIAL Usage Policy Language is spl= A SPECIAL authorization is represented with a class spl:Authorization.

The namespace for the SPECIAL Policy Log Vocabulary is We write triples in this document in the OWL functional syntax [[owl2-syntax]], which is less verbose, using the following namespace prefixes:

PREFIX rdf: <>
PREFIX rdfs: <>
PREFIX spl: <>
PREFIX svd: <>
PREFIX svpr: <>
PREFIX svpu: <>
PREFIX svr: <>
PREFIX svl: <>
PREFIX svdu: <>

The SPECIAL’s Usage Policy Language

Basic Usage Policies

A usage policy is composed of one or more basic usage policies, each of which is an OWL 2 expression of the form (Eq2):

    ObjectSomeValuesFrom(spl:hasData SomeDataCategory)
    ObjectSomeValuesFrom(spl:hasProcessing SomeProcessing)
    ObjectSomeValuesFrom(spl:hasPurpose SomePurpose)
    ObjectSomeValuesFrom(spl:hasRecipient SomeRecipient)
    ObjectSomeValuesFrom(spl:hasStorage SomeStorage)

The important parts in this expression are the policy’s attributes highlighted in bold; the policy author shall decide for each of them a suitable range, that in the above text is highlighted in italics. The above policy authorizes all the operations that

  1. fall within the specified SomeProcessing category,
  2. operate only on data that belong to SomeData category,
  3. have any purpose covered by the SomePurpose category,
  4. disclose the results to any member(s) of the SomeRecipient category,
  5. store the results in any place belonging to the SomeStorage category.

Therefore, SPECIAL encodes the set of all authorizations that have (at least) the specified attributes, which match the minimum core model (MCM). SPECIAL defines auxiliary vocabularies providing a set of minimum classes for SomeDataCategory, SomeProcessing, SomePurpose, SomeRecipient, based on the elaboration of concrete policies for the SPECIAL pilots, feedback from all SPECIAL partners, and similar terms in related vocabularies (in particular, P3P [[P3P]] for data categories, purposes and recipients, and ODRL [[[odrl-model]]] for processing).

The following table shows a basic description of each category and concrete examples. The full specification can be found at the SPECIAL Deliverable D2.5 [[SPECIALD25]]. Note that these vocabularies try to cover initial use cases, and further terms may have to be added to the current lists to cover the particular needs of policy authors.

Storage location
Table 1. SPECIAL auxiliary vocabularies for usage policies
Category Namespace #Classes Concepts Superclass
Data svd 27 svd:Activity, svd:Anonymized, svd:AudiovisualActivity, svd:Computer, svd:Content, svd:Demographic, svd:Derived, svd:Financial, svd:Government, svd:Health, svd:Interactive, svd:Judicial, svd:Location, svd:Navigation, svd:Online, svd:OnlineActivity, svd:Physical, svd:PhysicalActivity, svd:Political, svd:Preference, svd:Profile, svd:Purchase, svd:Social, svd:State, svd:Statistical, svd:TelecomActivity, svd:UniqueId, spl:AnyData
Processing svpr 9 svpr:Aggregate, svpr:Analyze, svpr:Anonymize, svpr:Collect, svpr:Copy, svpr:Derive, svpr:Move, svpr:Query, svpr:Transfer spl:AnyProcessing
Purpose svpu 31 svpu:Account, svpu:Admin, svpu:AnyContact, svpu:Arts, svpu:AuxPurpose, svpu:Browsing, svpu:Charity, svpu:Communicate, svpu:Current, svpu:Custom, svpu:Delivery, svpu:Develop, svpu:Downloads, svpu:Education, svpu:Feedback, svpu:Finmgt, svpu:Gambling, svpu:Gaming, svpu:Government, svpu:Health, svpu:Historical, svpu:Login, svpu:Marketing, svpu:News, svpu:OtherContact, svpu:Payment, svpu:Sales, svpu:Search, svpu:State, svpu:Tailoring, svpu:Telemarketing spl:AnyPurpose
Recipient svr 6 svr:Delivery, svr:OtherRecipient, svr:Ours, svr:Public, svr:Same, svr:Unrelated spl:AnyRecipient
svl 7 svl:ControllerServer, svl:EU, svl:EULike, svl:ThirdCountries, svl:OurServers, svl:ProcessorServers, svl:ThirdParty spl:AnyLocation
Storage duration svdu 4 svdu:BusinessPractices, svdu:Indefinitely, svdu:LegalRequirement, svdu:StatedPurpose spl:AnyDuration

General Usage Policies

A general usage policy may contain any number of basic policies as in (Eq3):

ObjectUnionOf( BasicPolicy1 . . . BasicPolicyn )

where each BasicPolicy i is of the form (Eq2). The resulting policy is conceptually the union of all the authorizations supported by the basic policies, that is, an operation is authorized by the general policy if and only if the operation is authorized by at least one of its basic policies.

For instance, the following general usage policy states that personal data can only be used for non-commercial purposes and shall neither be stored nor disclosed to third parties, while pseudonymised data can be used freely (where SPECIAL auxiliary vocabularies define the terms PersonalData, NonCommercial, PseudonymizedData).

Note that general policies whose basic policies differ only in one attribute can be factorized using a logical equivalence (ObjectUnionOf) supported by OWL 2. The following example shows this feature, stating that the data can refer to NavigationData or LocationData.

Storage Expressions

The hasStorage policy attribute is a structured object itself, with two attributes, and is specified as follows (Eq3):

    ObjectSomeValuesFrom(spl:hasLocation SomeLocation)
    ObjectSomeValuesFrom(spl:hasDuration SomeDuration)
    DataSomeValuesFrom(spl:durationInDays Interval)

In this expression, SomeLocation and SomeDuration are expressed in terms of the corresponding storage location and duration auxiliary vocabularies. It is not necessary to include in the policy both hasDuration and durationInDays. However at least one of them should be specified. The Interval limiting storage duration in days is expressed with the integer facets of OWL2, that is (Eq4):

DatatypeRestriction( xsd:integer
xsd:minInclusive min duration          (optional)
xsd:maxInclusive max duration          (optional)

In this expression, min and max durations follow the syntax of xsd:integer. Note that here we are choosing days as the finest granularity for the shake of simplicity, but any standard mapping from dates to integers could be used, e.g. the one used in Unix-like systems.

Compliance Checking

Recall that a policy Pc complies with another policy Ps if and only if (Eq1) holds, that is, Pc ⊆ Ps. In OWL2 terminology, checking whether a general usage policy Pol1 complies with another general usage policy Pol2 amounts to checking whether the following axiom is entailed (implied) by the combined ontology O containing the SPECIAL policy language ontology plus the aforementioned auxiliary vocabularies:

SubClassOf( Pol1 Pol2 ).

Further details of the compliance checking mechanism can be found in the SPECIAL Deliverable D2.8 [[SPECIALD28]]

SPECIAL’s Usage Policy Language Grammar

The complete syntax of usage policies is specified by the following BNF grammar:

UsagePolicy :=’ObjectUnionOf’ ’(’ BasicUsagePolicy BasicUsagePolicy { BasicUsagePolicy } ’)’
            | BasicUsagePolicy
BasicUsagePolicy :=’ObjectIntersectionOf’ ’(’ Data Purpose Processing Recipients Storage ’)’
Data :=’ObjectSomeValueFrom’ ’(’ ’spl:hasData’ DataExpression ’)’
Purpose :=’ObjectSomeValueFrom’ ’(’ ’spl:hasPurpose’ PurposeExpression ’)’
Processing :=’ObjectSomeValueFrom’ ’(’ ’spl:hasProcessing’ ProcessingExpression ’)’
Recipients :=’ObjectSomeValueFrom’ ’(’ ’spl:hasRecipient’ RecipientExpression ’)’
Storage :=’ObjectSomeValueFrom’ ’(’ ’spl:hasStorage’ StorageExpression ’)’
DataExpression :=’spl:AnyData’ | DataVocabExpression
PurposeExpression :=’spl:AnyPurpose’ | PurposeVocabExpression
ProcessingExpression :=’spl:AnyProcessing’ | ProcessingVocabExpression
RecipientsExpression :=’spl:AnyRecipient’ | ’spl:Null’ | RecipientVocabExpression
StorageExpression :=’spl:AnyStorage’ | ’spl:Null’ |
                    ’ObjectIntersectionOf’ ’(’ Location Duration ’)’
Location :=’ObjectSomeValueFrom’ ’(’ ’spl:hasLocation’ LocationExpression ’)’
Duration :=’ObjectSomeValueFrom’ ’(’ ’spl:hasDuration’ DurationExpression ’)’
            | ’DataSomeValueFrom’ ’(’ ’spl:durationInDays’ IntervalExpression ’)’
LocationExpression :=’spl:AnyLocation’ | LocationVocabExpression
DurationExpression :=’spl:AnyDuration’ | DurationVocabExpression
IntervalExpression :=’DatatypeRestriction’ ’(’ ’xsd:integer’ LowerBound UpperBound ’)’
LowerBound :=’xsd:minInclusive’ IntegerLiteral
UpperBound :=’xsd:maxInclusive’ IntegerLiteral
IntegerLiteral := stringOfDigits ’^^’ ’xsd:integer’
stringOfDigits := a sequence of digits enclosed in a pair of " (U+22)
DataVocabExpression := as specified in Table 1
PurposeVocabExpression := as specified in Table 1
ProcessingVocabExpression := as specified in Table 1
RecipientVocabExpression := as specified in Table 1
LocationVocabExpression := as specified in the Storage section
DurationVocabExpression := as specified in the Storage section

Data Privacy Controls and Vocabularies

SPECIAL setup the W3C Data Privacy Vocabularies and Controls Community Group (DPVCG) in 2018, after organising a workshop for W3C on Data Privacy Controls and Vocabularies. The group launched on the 25th of May 2018, the official start date of the GDPR. The mission of the DPVCG is to develop a taxonomy of privacy terms, which include in particular terms from the new European General Data Protection Regulation (GDPR), such as a taxonomy of personal data as well as a classification of purposes (i.e., purposes for data collection), and events of disclosures, consent, and processing such personal data.

The vocabularies (and related ontologies) constituted one of the inputs for the development of the vocabularies of the DPVCG that constitute the reference vocabularies for SPECIAL's policy language.

In 2019, the group published two vocabularies:

  1. Data Privacy Vocabulary v0.1, (2019)
  2. DPVCG GDPR Legal Basis Vocabulary, (2019)

The group, which has its own home page on the W3C site, will continue even after the competion of the SPECIAL project, thus ensuring sustainability of project resources well beyond the project lifetime.

Extension for sticky policies

Policies governing data transfers may associate a sticky policy to the data being transferred (to specify the allowed usage of the data). This can be done by means of a suitable object property withStickyPolicy that qualifies the transfer operation.Here is an example of a transfer policy specifying a sticky policy, inspired by DTAG’s use case (namespaces are omitted to improve readability). The transfer policy allows to transfer personally identifiable location data to company X under the sticky policy <pol>, for the purpose of network quality improvement:

In this example, the auxiliary vocabularies need to be extended with three new classes: the class ex:ReartRate (as a subclass of svd:Health), ex:Profiling (a subclass of svpr:Analyze) and ex:Recommendation (a subclass of svpu:Marketing).

Here <pol> should be replaced with a policy written in SPECIAL’s language. Such policy may specify, for example, that the processing is Analyze and that it is carried out for the purpose of NetworkQualityImprovement, that there are no third-party recipients, et cetera.


The work is supported by the European Union's Horizon 2020 research and innovation programme under grant 731601 (SPECIAL).