ODRL V2.2 Profile Best Practices

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, and MUST NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

The Open Digital Rights Language (ODRL) 2.2 defines an Information Model for expressing policies which requires classes and concepts for its assertions. A basic set of classes and concepts is defined by the ODRL Core Vocabulary and the information model permits users of ODRL to define their own subclasses and concepts for a specific use.

Specific sets of classes and concepts are named as ODRL Profile and a full chapter of the information model recommendation covers its purpose, required conformance and a mechanism for creating new ones.

This document walks users through the ODRL Profile chapter, explains how to implement a Profile and provides some examples. A user planning to create an ODRL Profile should start with reading the section about the purpose of an ODRL Profile.

This section lists namespaces, other identifiers and annotations used in examples of the following chapters.

Prefix	Namespace	Description
:	http://www.w3.org/ns/odrl/2/	ODRL Vocabulary (default namespace)
odrl	http://www.w3.org/ns/odrl/2/	ODRL Vocabulary
exns1	https://example.com/ns/ex1/	Used by Example Profile 1
exns2	https://example.com/ns/ex2/	Used by Example Profile 2
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#	Resource Description Framework (RDF)
rdfs	http://www.w3.org/2000/01/rdf-schema#	RDF Schema
owl	http://www.w3.org/2002/07/owl#	OWL
skos	http://www.w3.org/2004/02/skos/core#	SKOS
dcterms	http://purl.org/dc/terms/	Dublin Core Terms

Prefix	Identifier	Description
expf1	https://example.com/odrlprofile/ex1	Example Profile 1
expf2	https://example.org/odrlprofile/ex2	Example Profile 2

In the header of an example, indicating the used syntax
- TTL = the RDF syntax Turtle is used
- JSON-LD = the RDF syntax JSON-LD 1.0 is used

This section walks through the ODRL Profile Mechanism of the ODRL Information Model. All items below, except the last one, are about adding an ODRL-related specification. Such a specification does not become part of the ODRL 2.2 Recommendation but an ODRL Processor processing ODRL Policies with a specific Profile must be able to understand this Profile's specification.

The sequence of additional specifications follows priorities of use expected by the ODRL Community Group.

An instance of ODRL Action is used as value of the mandatory property action of the Rule class, and all its subclasses Permission, Prohibition and Duty (and ones defined by a Profile). The Recommendation defines only two instances of Action: use, covering any use of an asset while the ownership of the asset does not change, and transfer, covering the transfer of the ownership of an asset in perpetuity.

If these two core Actions are sufficient, a Profile does not need to add more. But in most cases, additional Action instances are required, and the example shows how to add two to the Example Profile 1:

digitize is an Action already defined by the ODRL Common Vocabulary. But this Common Vocabulary is not part of the ODRL Recommendation; therefore, Actions defined by it must be adopted by the Example Profile 1.
Note: an Action defined by the ODRL Common Vocabulary does not have to be included into the specification of a Profile, it is only required to express that it is included into the Profile. Find more about that in Resources defining an ODRL Profile.
changecolours is an Action defined for and by this Example Profile 1

Example 1 (TTL)

odrl:digitize
  a :Action, skos:Concept ;
  rdfs:isDefinedBy odrl: ;
  rdfs:label "Digitize"@en ;
  :includedIn odrl:use ;
  skos:definition "To produce a digital copy of (or otherwise digitize) the Asset from its analogue form."@en ;
  skos:scopeNote "Non-Normative"@en .

exns1:changecolours
  a :Action, skos:Concept ;
  rdfs:isDefinedBy expf1: ;
  rdfs:label "Change Colours"@en ;
  :includedIn odrl:use ;
  skos:definition "For using a graphics asset its colours are changed."@en .

An ODRL Constraint is a class for applying a constraint to a Rule. One of its mandatory properties is leftOperand and instances of Left Operand are used as values of this property, the Recommendation does not define any instances.

If any Constraint will be used for a Policy using a specific Profile, at least one Left Operand must be defined for the mandatory leftOperand property. The example shows how to define two for the Example Profile 1:

elapsedTime is a LeftOperand already defined by the ODRL Common Vocabulary. But this Common Vocabulary is not part of the ODRL Recommendation; therefore, LeftOperands defined by it must be adopted by the Example Profile 1
Note: a LeftOperand defined by the ODRL Common Vocabulary does not have to be included into the specification of a Profile, it is only required to express that it is included into the Profile. Find more about that in Resources defining an ODRL Profile.
aggregatedTime is a LeftOperand defined by the Example Profile 1

Example 2 (TTL)

odrl:elapsedTime
  a :LeftOperand, owl:NamedIndividual, skos:Concept ;
  rdfs:isDefinedBy odrl: ;
  rdfs:label "Elapsed Time"@en ;
  skos:definition "A continuous elapsed time period which may be used for exercising of the action of the Rule. Right operand value MUST be an xsd:duration as defined by [[xmlschema11-2]]."@en ;
  skos:note "Only the eq, lt, lteq operators SHOULD be used. See also Metered Time. Example: elpasedTime eq P60M indicates a total elapsed time of 60 Minutes." ;
  skos:scopeNote "Non-Normative"@en .

exns1:aggregatedTime
  a :LeftOperand, owl:NamedIndividual, skos:Concept ;
  rdfs:isDefinedBy expf1: ;
  rdfs:label "Aggregated Time"@en ;
  skos:definition "A aggregation of elapsed time periods which may be used for exercising of the action of the Rule. Right operand value MUST be an xsd:duration as defined by [[xmlschema11-2]]."@en ;
  skos:note "Only the eq, lt, lteq operators SHOULD be used. See also Metered Time. Example: aggregatedTime eq P800M indicates aggregated elapsed time of 800 Minutes." .

An ODRL Constraint is a class for applying a constraint to a Rule. One of its mandatory properties is operator and instances of Operator are used as values of this property, the Recommendation defines 12 instances.

The example show how to define an Operator instance for Example Profile 1

Example 3 (TTL)

exns1:doubleof
	a :Operator, owl:NamedIndividual, skos:Concept ;
	rdfs:isDefinedBy expf1: ;
	skos:definition "Indicating that a given value is the double of the right operand of the Constraint."@en ;
	rdfs:label "Double of"@en .

An instance of ODRL Party Function is used as value of the property function of the Rule class, the Recommendation defines 14 instances. function sets the relationship between a subclass of a Rule (Permission, Prohibition, Duty, ...) and a Party or a PartyCollection.

The example shows how to define the Party Function toBeNotifiedParty for the Example Profile 1, a party which must be notified in the context of executing the action of a Rule.

Example 4 (TTL)

exns1:toBeNotifiedParty
  a rdf:Property , owl:ObjectProperty, skos:Concept ;
  rdfs:isDefinedBy expf1: ;
  rdfs:subPropertyOf :function ;
  rdfs:label "To Be Notified Party"@en ;
  skos:definition "The Party which must be notified."@en;
  skos:note "May be specified as part an action requiring the notification of a Party."@en .

An ODRL Asset Relationship is a relationship between a subclass of a Rule (Permission, Prohibition, Duty, ...) and an Asset, the Recommendation defines only target as sub-property of relation.

The example shows how to define the asset relationship input for the Example Profile 1, an asset required as input for the action of a Rule.

Example 5 (TTL)

exns1:input
  a rdf:Property , owl:ObjectProperty, skos:Concept ;
  rdfs:isDefinedBy expf1: ;
  rdfs:subPropertyOf :relation ;
  rdfs:label "Input"@en ;
  skos:definition "The input property specifies the Asset which is used as input of the Action."@en ;
  rdfs:domain :Rule ;
  rdfs:range :Asset.

An ODRL Constraint is a class for applying a constraint to a Rule. One of its mandatory properties is rightOperand (or its alternative rightOperandReference) and instances of RightOperand are used as value of this property, the Recommendation does not define any.

If any Constraint will be used for a Policy using a specific Profile, it may be required to define one or more RightsOperands. The example shows how to define one for the Example Profile 1:

policyUsage is a RightOperand already defined by the ODRL Common Vocabulary. But this Common Vocabulary is not part of the ODRL Recommendation; therefore, RightOperands defined by it must be adopted by the Example Profile 1.
Note: a Right Operand defined by the ODRL Common Vocabulary does not have to be included into the specification of a Profile, it is only required to express that it is included into the Profile. Find more about that in Resources defining an ODRL Profile.

Example 6 (TTL)

odrl:policyUsage
  a :RightOperand, owl:NamedIndividual, skos:Concept ;
  rdfs:isDefinedBy odrl: ;
  rdfs:label "Policy Rule Usage"@en ;
  skos:definition "Indicates the actual datetime the action of the Rule was exercised."@en ;
  skos:note "This can be used to express constraints with a LeftOperand relative to the time the rule is exercised. Operators indicate before (lt, lteq), during (eq) or after (gt, gteq) the usage of the rule. Example: 'event lt policyUsage' expresses that the identified event must have happened before the action of the rule is exercised."@en ;
  skos:scopeNote "Non-Normative"@en .

An ODRL Logical Constraint is a class for applying a constraint to a Rule. One of its properties must be a sub-property of the operand property, the Recommendation defines four of them: or, xone, and, andSequence.

For a Logical Constraint with another operand sub-property a new one must be defined by a specific Profile. The example shows how to define one for the Example Profile 1:

Example 7 (TTL)

exns1:xtwo
  a rdf:Property , owl:ObjectProperty, skos:Concept ;
  rdfs:isDefinedBy expf1: ;
  rdfs:subPropertyOf :operand ;
  skos:definition "The relation is satisfied when only two, and not less or more, of the Constraints is satisfied"@en ;
  rdfs:label "Exactly Two"@en ;
  skos:note "This property MUST only be used for Logical Constraints."@en .

An instance of ODRL Conflict Strategy Preference is used as value of the property conflict of the Policy class, the Recommendation defines three instances: perm, prohibit and invalid.

The example shows how to define the Conflict Strategy Preference ignore for the Example Profile 1 (may not be of real help ...).

Example 8 (TTL)

exns1:ignore
  a :ConflictTerm, owl:NamedIndividual, skos:Concept;
  rdfs:isDefinedBy expf1: ;
  rdfs:label "Ignore Conflicts"@en ;
  skos:definition "Ignore conflicts."@en ;
  skos:note "Used to determine policy conflict outcomes."@en .

The ODRL Information Model Recommendation defines the Rule Class and three subclasses of it: the Permission Class, the Prohibition Class and the Duty Class. The ODRL Profile Mechanism permits to create additional subclassesof the Rule Class or of one of these defined subclasses; their definitions must comply with the design of the basic Rule Class.

A Rule MUST have one action property value of type Action.
A Rule MAY have none or one relation sub-property values of type Asset.
A Rule MAY have none, one or many function sub-property values of type Party.
A Rule MAY have none, one or many failure sub-property values of type Rule.
A Rule MAY have none, one or many constraint property values of type Constraint/LogicalConstraint.
A Rule MAY have none or one uid property values (of type IRI [rfc3987]) to identify the Rule so it MAY be referenced by other Rules.

Defining a subclass of Rule or of Permission or of Prohibition or of Duty allows:

If the cardinality of a property is defined by its superclass as "MAY have none or one" a "MUST have one" or a "MUST NOT have one" can be defined.
If the cardinality of a property is defined by its superclass as "MAY have none, one or many" a "MUST have one" or a "MUST NOT have one" or a "MUST have many" can be defined.
One or more additional properties may be defined. For a property its name (identifier), its occurrence and its value type must be defined.

Note

Design Strategy

The ODRL Community Group highly recommends for Profiles to stick to the basic design of Rule subclasses as defined by the ODRL Information Model: the Rule subclasses Permission, Prohibition and Duty cover the key use cases of an ODRL policy and therefore an ODRL Profile should either adopt any of these three classes as they are or define subclasses of the Permission Class, or the Prohibition Class or the Duty Class. Defining a subclass of Rule should be avoided as this may infringe the information model of ODRL.

Design Consideration
Please check if a rule required by the use case covered by the Profile can be expressed - in this sequence:
1) By the Permission, the Prohibition or the Duty class as defined by ODRL Recommendation (this does not need a definition by a Profile)
2) By a new subclass of the Permission or Prohibition or Duty class (the new subclass(es) must be defined by the Profile)
3) As a last resort: by a subclass of the Rule class as defined by the ODRL Recommendation as none of the items above fits the needs of the use case. (The new subclass(es) of Rule and a new subclass of Policy with a property for each new Rule subclass must be defined by the Profile.)

For the definitions of the following Rules below: it is not required to create a new subclass of Policy. The requirements that the value of a permission property must be of type Permission (or a subclass of it) and that the value of a prohibition property must be of type Prohibition (or a subclass of it) and that the value of an obligation property must be of type Duty (or a subclass of it) is fulfilled.
Only the requirement to use one of the properties permission, prohibition or obligation needs to be fulfilled.

How To Define a Subclass of the Permission Class

A new subclass of Permission is defined by the Profile ...
... this new subclass can be used with the permission property of the Policy class as defined by the ODRL Recommendation
The generic rules of the Rule class for the use of properties are refined by specific rules of the Permission Class:
- A Permission MUST have one target property value of type Asset. (Other relation sub-properties MAY be used.)
- A Permission MAY have none or one assigner and/or assignee property values (of type Party) for functional roles. (Other function sub-properties MAY be used.)
- A Permission MAY have none, one, or more duty property values of type Duty.
The ODRL Profile Mechanism requires to define this new (sub-)class as disjoint with the Prohibition and Duty class

Example definition:

ex:myPermission rdfs:subClassOf odrl:Permission ;
owl:disjointWith odrl:Prohibition, odrl:Duty .

How To Define a Subclass of the Prohibition Class

A new subclass of Prohibition is defined by the Profile ...
... this new subclass can be used with the prohibition property of the Policy class as defined by the ODRL Recommendation
The generic rules of the Rule class for the use of properties are refined by specific rules of the Prohibition Class:
- A Prohibition MUST have one target property value of type Asset. (Other relation sub-properties MAY be used.)
- A Prohibition MAY have none or one assigner and/or assignee property values (of type Party) for functional roles. (Other function sub-properties MAY be used.)
- A Prohibition MAY have none, one, or more remedy property values of type Duty.
The ODRL Profile Mechanism requires to define this new (sub-)class as disjoint with the Permission and Duty class

Example definition:

ex:myProhibition rdfs:subClassOf odrl:Prohibition ;
owl:disjointWith odrl:Permission, odrl:Duty .

How To Define a Subclass of the Duty Class

A new subclass of Duty is defined by the Profile ...
... this new subclass can be used with the obligation property of the Policy class as defined by the ODRL Recommendation
The generic rules of the Rule class for the use of properties are refined by specific rules of the Duty Class:
- A Duty MAY have none or one target property values (of type Asset) to indicate the Asset that is the primary subject to which the Duty directly applies. (Other relation sub-properties MAY be used.)
- A Duty MAY have none or one assigner and/or assignee property values (of type Party) for functional roles. (Other function sub-properties MAY be used.)
- A Duty MAY have none, one or many consequence property values of type Duty only when the Duty is referenced by a Rule with the duty or obligation properties.
The ODRL Profile Mechanism requires to define this new (sub-)class as disjoint with the Permission and Duty class

Example definition:

ex:myDuty rdfs:subClassOf odrl:Duty ;
owl:disjointWith odrl:Permission, odrl:Prohibition .

The example shows how to define of a subclass StraightPermission1 for the Example Profile 1

Example 9 (TTL)

exns1:StraightPermission1
  a rdfs:Class , owl:Class, skos:Concept ;
  rdfs:isDefinedBy expf1:
  rdfs:subClassOf :Permission ;
  owl:disjointWith :Prohibition, :Duty ;
  rdfs:label "Straight Permission 1"@en ;
  skos:definition "A Rule permitting the use of an Asset"@en ;
  skos:note "A Straight Permission 1 Rule must not contain any property for expressing a duty."@en .

The ODRL Information Model Recommendation defines the Policy Class and three subclasses of it: the Set Class, the Offer Class and the Agreement Class. The ODRL Profile Mechanism permits to create additional subclasses; their definitions must comply with the design of the basic Policy Class:

A Policy MUST have one uid property value (of type IRI [rfc3987]) to identify the Policy.
A subclass must adopt this rule.
A Policy MUST have at least one permission, prohibition, or obligation property values of type Rule.
A subclass can combine any set of one permission, prohibition, or obligation property values as long as this basic rule is satisfied.
Examples:

Only permission property values
Only permission property values, five as maximum
Only permission or prohibition property values
Only at least 1 permission and at least 1 prohibition property value

A Policy MAY have none, one, or many profile property values.
This is an implicitly met requirement: if a Profile is defined it must be expressed by a profile property values to become effective.

A new Policy subclass must be defined as disjoint with all other Policy subclasses, except the Set subclass.

Defining a subclass of Policy allows:

If the cardinality of a property is defined by the Policy class as "MAY have none or one" a "MUST have one" or a "MUST NOT have one" can be defined.
If the cardinality of a property is defined by the Policy class as "MAY have none, one or many" a "MUST have one" or a "MUST NOT have one" or a "MUST have many" can be defined.
If the Policy class defines "MUST have at least one" with a list of properties to select from a restricted set of properties and/or a specific combination of properties can be defined. (See the examples for permission, prohibition, or obligation property values above.)
One or more additional properties may be defined. For a property its name (identifier), its occurrence and its value type must be defined.

Note

Read the note of the Additional Rule Subclasses section. It describes in which cases a new subclass of Policy is required and in which not.

The example shows a basic definition of a subclass SpecialOffer1 for the Example Profile 1

Example 10 (TTL)

exns1:SpecialOffer1
  a rdfs:Class , owl:Class, skos:Concept ;
  rdfs:isDefinedBy expf1:
  rdfs:subClassOf :Policy ;
  owl:disjointWith :Agreement, :Privacy, :Request, :Ticket, :Assertion, :Offer ;
  rdfs:label "Special Offer 1"@en ;
  skos:definition "A Policy offering a permission of using an asset"@en ;
  skos:note "A Special Offer 1 Policy MUST contain at least one Permission and a Party with Assigner function (in the same Permission or Prohibition). The Offer Policy MAY contain either a specific Party or a Collection of Parties with Assignee function."@en .

An ODRL Constraint is a class for applying a constraint to a Rule. The ODRL Profile Mechanism permits to create additional subclasses of the Constraint Class; its definition must comply with the design of the basic Constraint Class.

A Constraint MAY have none or one uid property value (of type IRI [rfc3987]) to identify the Constraint.
A Constraint MUST have one leftOperand property value of type LeftOperand.
A Constraint MUST have one operator property value of type Operator.
A Constraint MUST have either:
- one rightOperand property value of type:
  - literal, or IRI [rfc3987], or RightOperand; or
  - for set-based operators; list of literals, or list of IRIs [rfc3987], or list of RightOperands;
- one rightOperandReference property value of type:
  - IRI [rfc3987]; or
  - for set-based operators; list of IRIs [rfc3987];
  for a reference to a right operand value.
A Constraint MAY have none or one dataType property value for the data type of the rightOperand/Reference.
A Constraint MAY have none or one unit property value (of type IRI [rfc3987]) to set the unit used for the value of the rightOperand/Reference.
A Constraint MAY have none or one status property value for a value generated from the leftOperand action or for a value related to the leftOperand set as the reference for the comparison.

Defining a subclass of Constraint allows:

If the cardinality of a property is defined by its superclass as "MAY have none or one" a "MUST have one" or a "MUST NOT have one" can be defined.
If the cardinality of a property is defined by its superclass as "MAY have none, one or many" a "MUST have one" or a "MUST NOT have one" or a "MUST have many" can be defined.
One or more additional properties may be defined. For a property its name (identifier), its occurrence and its value type must be defined.

The example shows a basic definition of a subclass SpecialConstraint for the Example Profile 1

Example 11 (TTL)

exns1:SpecialConstraint
        a rdfs:Class , owl:Class, skos:Concept ;
        rdfs:isDefinedBy expf1:
        rdfs:subClassOf :Constraint ;
        rdfs:label "Special Constraint"@en ;
        skos:definition "A Constraint which requires the unit to be always present."@en ;
        skos:note "A Special Constraint MUST contain the unit."@en .

The Policy class defines for the profile property that none, one or many profile identifiers can be applied. This raises the question: what should be considered if more than one Profile is applied to an instance of a Policy:

First it should be considered that applying only one profile identifier to the profile property means that two profiles are in use: the default ODRL Core Profile and this explicitly defined profile.
Subclasses, sub-properties or instances of a class included into a Profile are defined in either a specific namespace or in the ODRL namespace if this thing is defined already by the ODRL Common Vocabulary.
Subclasses, sub-properties or instances of a class defined in a namespace used for e.g., Example Profile 1 can also be adopted for another Profile, e.g., Example Profile 2. (Note: be aware that the identifier of a Profile and the identifier of a namespace used by it does not have to the same.)
If a subclasses, sub-properties or instances of a class is defined in a namespace with an identifier different from the identifier of the Profile this thing can be used by multiple Profiles (with identifiers different from the namespace) but they MUST be defined by each Profile in exactly the same way. E.g., a Rule subclass exns1:StraightPermission defined by Example Profile 1 as not having any property expressing a Duty must not have in a definition of Example Profile 2 a property expressing a Duty.
Note: for this purpose this Best Practices document uses the term "adopt" for including the definition of a thing which may be included by other Profiles. In particular, this term was used for things defined by the ODRL Common Vocabulary is a use of things defined by it by other Profiles has to be expected.
For using a thing defined by Example Profile 1 by a Policy using Example Profile 2 it is not strictly required to adopt this thing of Example Profile 1 for Example Profile 2; formally it is sufficient to apply the identifiers for Example Profile 2 and of Example Profile 1 to the profile property of the Policy.
If multiple identifiers of Profiles are applied to the profile property of the Policy all the things defined by all of them are valid for this Policy. If only subsets of the things defined by multiple Profiles should be applied to a Policy, a new Profile should be created adopting only the things of this subset.
If Party A defines a Profile with things defined by (and in a namespace of) Party B, the adoption must comply with the copyright of these things.

The ODRL Profile Purpose section of the ODRL Information Model defines the roles of profiles:

The ODRL Core Profile defines a vocabulary of all the terms defined by the ODRL Information Model 2.2. Recommendation
All other profiles defined by the rules of an ODRL Profile must be considered as a definition of additional terms

But it is not mandatory to use all terms of the ODRL Core Profile and of a referenced additional profile in an ODRL Policy instance.
Based on this basic rule, a profile may suggest to ignore a term defined by the ODRL Core Profile, e.g. a specific subclass of Policy or Rule, a specific instance of Action, a specific Logical Constraint Operand ... and others, which is not relevant for the use case covered by this profile as long as the ODRL Information Model does not define its use as mandatory, as a MUST. (Check the terms defined by the ODRL Core Vocabulary.) But a profile must not declare an ODRL Core Profile term as prohibited, as MUST NOT be used!

The ODRL Information Model claims the use of properties of a class as a MUST (= as mandatory) or that an ODRL Validator MUST support the use of specific sub-properties of a defined property. A validator supporting the ODRL Core Profile and a specific additional profile MUST NOT ignore mandatory ODRL Core requirements but in reverse it may ignore optional ODRL Core requirements.

Regarding Policy: a subclass of Policy must be used, but it is not mandatory to use a subclass defined by the ODRL Core Profile if a related profile defines one. Therefore, the subclasses of Policy defined by the ODRL Core Profile may be ignored if the related profile defines a new subclass of Policy.
Regarding the Rule(s) of a Policy:
A Policy must use at least one of the properties permission, prohibition or obligation with a corresponding subclass of Rule - Permission Class, or a subclass of it; Prohibition Class, or a subclass of it; Duty Class or a subclass of it - as type, this cannot be omitted.
Regarding Action: the ODRL Core Profile defines only two instances of Action: use and transfer. A profile may ignore them as using them and their narrower terms is not defined as mandatory by the Rule Class or the Action Class.
Regarding Party Functions: The Rule Class defines the use of sub-properties of function as optional, it may be ignored. But if a sub-property of the function property is used, the two terms defined by the ODRL Core Profile, assigner and assignee, must not be ignored.
Regarding Asset Relationship: The Rule Class defines the use of sub-properties of relation as optional, it may be ignored. But if a sub-property of the relation property is used the single term defined by the ODRL Core Profile, target, must not be ignored.

Each Profile must have a globally unique identifier. Such an identifier must be of type IRI [rfc3987] which is in short a URI [rfc3986] with an extended, internationalized character set.

Be aware that this Profile identifier should not be used for other purposes like the identifier of a namespace of concepts defined by the Profile as it would be hard to distinguish if a profile or a namespace is identified when using this identifier.

If a Profile should be used publicly, its definition and optional usage guidelines should be publicly accessible web resources. Consider defining the unique identifier of the Profile as URL of a web resource providing information about the Profile.

This section covers the procedure of generating specifications in addition to the ODRL Core Profile, details of documents resulting from this procedure are covered in section 5, and section 6 covers how to make them publicly available.

A Profile should have a semantic technology specification using a SKOS Collection [skos] and making all concepts adopted or created by this Profile a member of this Collection. Use the IRI of the Profile as identifier of this Collection.

Section 3 explains what a new ODRL Profile can define in addition to the Core Profile. Walking through this section should result in this output:

If a concept from the ODRL Common Vocabulary is adopted, it should not be specified by this Profile, but it must be made a member of the Profile's Collection.
If an existing concept conforming to ODRL 2.2 specifications from a source different from this Profile is adopted: check first if a specification of this concept is publicly accessible. If this is the case this concept should be adopted by adding it as member to the Profile's Collection. If this is not the case it has to be specified like a new concept defined by this Profile, see next item.
If a new concept is created for this Profile, it must be specified by the documents of this Profile and made a member of the Profile's Collection.
If a concept is adopted or created as ODRL Action, it should be made a member of a SKOS Collection of all Actions defined by this Profile.
If a concept is adopted or created as ODRL Constraint Left Operand, it should be made a member of a SKOS Collection of all Constraint Left Operands defined by this Profile.
If a concept is adopted or created as ODRL Constraint Operator, it should be made a member of a SKOS Collection of all Constraint Operators defined by this Profile.
If a concept is adopted or created as ODRL Party Function, it should be made a member of a SKOS Collection of all Party Functions defined by this Profile.
If a concept is adopted or created as ODRL Asset Relationship, it should be made a member of a SKOS Collection of all Asset Relationships defined by this Profile.
If a concept is adopted or created as ODRL Constraint Right Operand, it should be made a member of a SKOS Collection of all Constraint Right Operands defined by this Profile.
If a concept is adopted or created as ODRL Logical Constraint, it should be made a member of a SKOS Collection of all Logical Constraints defined by this Profile.
If a concept is adopted or created as ODRL Policy Conflict Strategy Preference, it should be made a member of a SKOS Collection of all Policy Conflict Strategy Preferences defined by this Profile.
If a subclass is adopted or created as ODRL Rule subclass, it should be made a member of a SKOS Collection of all Rule subclasses defined by this Profile.
If a subclass is adopted or created as ODRL Policy subclass, it should be made a member of a SKOS Collection of all Policy subclasses defined by this Profile.

Finally: create a W3C Profile Vocabulary [dx-prof] document. This document sets the normative part of the ODRL Profile - the ODRL 2.2 Information Model and the ODRL 2.2 Core Profile - and lists all documents used for defining this Profile.

Humans taking a decision on using a specific ODRL Profile or not like to read a human-readable document about it.

It should include:

The name and the globally unique identifier of the Profile
The party creating and maintaining the Profile
The latest version of the Profile and its date of release
The purpose(s) of the Profile
A list of all member concepts of the Profile ...
... and a human-readable specification of at least all new concepts defined by the Profile ...
... if for adopted concepts of other sources a reasonable human-readable specification is available, their documentation can be referenced. Else a specification created by the owner of this Profile may be created for this document.
For each concept or subclass of this Profile, its type as listed in section 3 should be indicated.
For any type of concept or subclass as listed in section 3 a list of its additional concepts or subclasses defined by this Profile may be included.
A list of all used identifiers of namespaces, other ODRL Profiles, vocabularies of ODRL concept and other relevant resources.
A list of all standards used by this Profile.
This document may show or refer to examples of ODRL Policies using this Profile, they are liked by many users.

An OWL [owl] Ontology should define all concepts defined by a Profile, each one's properties and relationships. Different formats can be applied, these are the most widely used: RDF Turtle, RDF/XML, RDF N-Triples, JSON-LD.
This ontology should include:

A definition of all used prefixes, if the used syntax supports or requires that.
A definition of the ontology as a whole. As identifier of the ontology, the identifier of the Profile must be used.
A SKOS [skos] Collection of all concepts defined by this Profile, either a concept specified by this ontology or a concept defined by another source.
A SKOS Collection for each type of additional concepts or subclasses (see section 3) if at least one concept is defined for it.
A declaration of all used annotation properties to keep this ontology within OWL DL.

See below an example ontology of the (virtual) ODRL Profile Example Profile 1.
It adopts a small set of concepts defined by the ODRL Common Vocabulary and specifies a single concepts on its own.

OWL Ontology Example 1 (TTL)

## Definition of used or common namespaces
@base <http://www.w3.org/ns/odrl/2/> .
@prefix : <http://www.w3.org/ns/odrl/2/> .
@prefix odrl: <http://www.w3.org/ns/odrl/2/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix schema: <http://schema.org/> .
@prefix cc: <http://creativecommons.org/ns#> .
@prefix exns1: <https://example.com/ns/ex1/> .
@prefix exprof1: <https://example.com/odrlprofile/exprof1/> .

## Definition of the Profile as OWL Ontology
exprof1:
    a owl:Ontology ;
    rdfs:label "Example Profile 1"@en ;
    rdfs:label "Beispiel Profil 1"@de ;
    owl:versionInfo "0.1" ;
    dct:creator "Joe Doe, Jane Miller";
    dct:contributor "The Global ODRL Profile Working Group - GOPWG" ;
    dct:description "The Example Profile 1 Vocabulary defines a set of concepts required by the Any-Industry."@en ;
    rdfs:comment "This is the RDF ontology for Example Profile 1 as of 2019-08-22"@en ;
    dct:license <http://creativecommons.org/licenses/by/4.0/> .


## SKOS Collection of all concepts defined by this Profile
<https://example.com/odrlprofile/exprof1/>
    a skos:Collection ;
    skos:prefLabel "Example Profile 1 Vocabulary"@en ;
    skos:scopeNote "All terms of the GOPWG Example Profile 1"@en ;
 ## all members below are from the ODRL Common Vocabulary, a specification exists
    skos:member :archive ;
    skos:member :compensate ;
    skos:member :display ;
    skos:member :grantUse ;
    skos:member :count ;
    skos:member :dateTime ;
    skos:member :compensatedParty ;
    skos:member :compensatingParty ;
    skos:member :output ;
## the member below is a concept created for this Profile
##   it needs to be specified in this ontology
    skos:member exns1:compensationValue .


## SKOS Collection of all Action concepts defined by this Profile
<https://example.com/odrlprofile/exprof1/#actions>
    a skos:Collection ;
    skos:prefLabel "Actions for Rules"@en ;
    skos:scopeNote "Example Profile 1 Terms"@en ;
    skos:member :archive ;
    skos:member :compensate ;
    skos:member :display ;
    skos:member :grantUse .

## SKOS Collection of all Left Operand concepts defined by this Profile
<https://example.com/odrlprofile/exprof1/#constraintLeftOperand>
    a skos:Collection ;
    skos:prefLabel "Constraint Left Operands"@en ;
    skos:scopeNote "Example Profile 1 Vocabulary Terms"@en ;
    skos:member :count ;
    skos:member :dateTime ;
	skos:member exns1:compensationValue .

## SKOS Collection of all Party Function concepts defined by this Profile
<https://example.com/odrlprofile/exprof1/#partyFunctions>
    a skos:Collection ;
    skos:prefLabel "Party Functions"@en ;
    skos:scopeNote "Example Profile 1 Vocabulary Terms"@en ;
    skos:member :compensatedParty ;
    skos:member :compensatingParty .

## SKOS Collection of all Asset Relation concepts defined by this Profile
<https://example.com/odrlprofile/exprof1/#assetRelations>
    a skos:Collection ;
    skos:prefLabel "Asset Relations"@en ;
    skos:scopeNote "Example Profile 1 Common Vocabulary Terms"@en ;
    skos:member :output .

## Concept(s) specified by this Profile. 

exns1:compensationValue
	a :LeftOperand, owl:NamedIndividual, skos:Concept ;
	rdfs:isDefinedBy exprof1: ;
	rdfs:label "Compensation Value"@en ;
	skos:definition "The value of a compensation expressed as a monetary amount. Right operand value MUST be an xsd:decimal. "@en ;
	skos:note "May be used for other compensations than payments, e.g. barter agreements."@en ;
  skos:scopeNote "Non-Normative"@en .



## Declaration of annotation properties to keep this ontology within OWL DL
	skos:member rdf:type owl:AnnotationProperty .
	skos:note rdf:type owl:AnnotationProperty .
	skos:scopeNote rdf:type owl:AnnotationProperty .
	skos:prefLabel rdf:type owl:AnnotationProperty .
	skos:definition rdf:type owl:AnnotationProperty .
	dct:contributor rdf:type owl:AnnotationProperty .
	dct:license rdf:type owl:AnnotationProperty .
	dct:issued rdf:type owl:AnnotationProperty .
	dct:subject rdf:type owl:AnnotationProperty .
	dct:creator rdf:type owl:AnnotationProperty .
	dct:description rdf:type owl:AnnotationProperty .
	dct:isVersionOf rdf:type owl:AnnotationProperty .
	dct:format rdf:type owl:AnnotationProperty .
	skos:Collection a owl:Class .
	skos:Concept a owl:Class .
	skos:ConceptScheme a owl:Class .

A W3C Profile Vocabulary [dx-prof] asserts all resources - named as artifacts - which are relevant for a Profile:

The base of any ODRL Policy, the W3C ODRL 2.2 Recommendation and its resources:
- the specification (HTML) document
- the Core Profile
The Profile and its resources:
- the specification (HTML) document
- the OWL ontology

This provides a quick overview like the example below for the (virtual) ODRL Profile Example Profile 1.

Profile Vocabulary Example 1 (TTL)

## Definition of used or common namespaces
@prefix dct:  <http://purl.org/dc/terms/> .
@prefix dc:   <http://purl.org/dc/elements/1.1/> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix odrl: <http://www.w3.org/ns/odrl/2/> .
@prefix profile: <http://www.w3.org/ns/dx/prof/> .
@prefix role: <http://www.w3.org/ns/dx/prof/role/> .
@prefix exprof1: <https://example.com/odrlprofile/exprof1/> .

# Declare the ODRL Core Profile artifacts

<http://www.w3.org/ns/odrl/2/core>
    a dct:Standard ;
    dct:title "The ODRL Core Profile Version 2.2" ;
    profile:hasResource _:1 _:2 .
   
_:1  # The normative W3C ODRL Information Model
    a profile:ResourceDescriptor ;
    profile:hasRole role:specification ;
    profile:hasArtifact <https://www.w3.org/TR/odrl-model/> ;
    dct:title "ODRL Information Model 2.2" ;
    dct:issued "2018-02-15"^^xsd:date ;
    dct:publisher "W3C" ;
    dct:format <https://www.iana.org/assignments/media-types/text/html> ;
    dct:conformsTo <https://www.w3.org/TR/html/> .

_:2  # The ODRL Core Profile vocabulary terms
    a profile:ResourceDescriptor ;
    profile:hasRole role:vocabulary ;
    profile:hasArtifact <tbd> ;
    dct:title "ODRL Core Profile Version 2.2" ;
    dct:issued "tbd"^^xsd:date ;
    dct:publisher "W3C" ;
    dct:format <https://www.iana.org/assignments/media-types/text/turtle> ;
    dct:conformsTo <https://www.w3.org/TR/turtle/> .

## Declare the artifacts of the Example Profile 1

exprof1: # Properties of the Example Profile 1
    a profile:Profile ;
    dct:title "Example Profile 1 - ODRL Profile" ;
    dct:description "An ODRL Profile focusing on rights and licensing requirements from the Any-Industry" ;
    profile:isProfileOf <http://www.w3.org/ns/odrl/2/core> ;
    profile:hasResource
        exprof1:ProfileSpec-html ,
        exprof1:ProfileVocabulary-ttl ;
    dct:publisher "Global ODRL Profile Working Group - GOPWG" ;
    dc:creator "Global ODRL Profile Working Group - GOPWG" ;
    owl:versionInfo "0.1"^^xsd:string ;    
    dct:issued "2019-08-23"^^xsd:date ;
.

exprof1:ProfileSpec-html # The Example Profile 1 specification HTML document
    a profile:ResourceDescriptor ;
    profile:hasRole role:specification ;
    profile:hasArtifact <https://example.com/odrlprofile/exprof1/ExaProf1_0.1.html> ;
    dct:title "Example Profile 1 version 0.1" ;
    owl:versionInfo "0.1.1"^^xsd:string ;    
    dct:issued "2019-08-22"^^xsd:date ;
    dct:format <https://www.iana.org/assignments/media-types/text/html> ;
    dct:conformsTo <https://www.w3.org/TR/html/> ;
.

exprof1:ProfileVocabulary-ttl  # The Example Profile 1 Profile vocabulary terms using RDF Turtle syntax
    a profile:ResourceDescriptor ;
    profile:hasRole role:vocabulary ;
    profile:hasArtifact <https://example.com/odrlprofile/exprof1/ExaProf1_0.1-ontology.ttl> ;
    dct:title "Example Profile 1 version 0.1" ;
    owl:versionInfo "0.1.0"^^xsd:string ;    
    dct:issued "2019-08-22"^^xsd:date ;
    dct:publisher "Global ODRL Profile Working Group - GOPWG" ;
    dct:format <https://www.iana.org/assignments/media-types/text/turtle> ;
    dct:conformsTo <https://www.w3.org/TR/turtle/>;
.

Whether the OWL Ontology of a Profile uses JSON-LD [JSON-LD] as format or if an ODRL Policy is expressed as JSON-LD, the uses of a JSON-LD Context is highly recommended. It is used for mapping short-term aliases of concept identifiers to the original identifier.

The Example below covers the concepts of the (virtual) ODRL Profile Example Profile 1.

JSON-LD Context Example 1 (JSON-LD)

{
 "@context": {
    "exns1":                 "https://example.com/ns/ex1/",
    "compensationValue":     "exns1:compensationValue",

    "odrl":                  "http://www.w3.org/ns/odrl/2/",
    "archive":               "odrl:archive",
    "attribute":             "odrl:attribute",
    "compensate":            "odrl:compensate",
    "display":               "odrl:display",
    "grantUse":              "odrl:grantUse",
    "count":                 "odrl:count",
    "dateTime":              "odrl:dateTime",
    "compensatedParty":     {"@type": "@id", "@id": "odrl:compensatedParty"},
    "compensatingParty":    {"@type": "@id", "@id": "odrl:compensatingParty"},
    "output":               {"@type": "@id", "@id": "odrl:output"}
    }
}

If an ODRL Profile should be used by a public audience, it is highly recommended to make its specifications publicly accessible:

A human-readable specification as an HTML web document
An OWL Ontology as resource using a common Semantic Web format, like RDF/Turtle, RDF/XML, RDF/N-Triples, or JSON-LD
A resource using the W3C Profile Vocabulary in a common Semantic Web format, like RDF/Turtle, RDF/XML, RDF/N-Triples, or JSON-LD
If the JSON-LD form should be supported for ODRL Policies, a JSON-LD Context resource.

All these resourced can be made accessible by URLs.

An alternative option is based on http request-based content negotiation; this feature must be supported by the web server delivering the documents. In this case, a generic URL is defined for the human-readable HTML document and the OWL Ontology in Semantic Web formats. Depending on the IANA Media Type expressed by the accept-header of the http(s) request the corresponding resource is delivered by the http(s) response.

The URL(s) used for such resources should be persistent over time. The publisher of a Profile should consider whether to reflect the version of the Profile in the URL or to use version-agnostic URLs.

The ODRL Community Group provides a list of registered ODRL 2.2 Profiles at https://www.w3.org/community/odrl/profile/

Contact this group by email public-odrl@w3.org and provide these details of the profile:

Business name of the profile
Name and web URL of the party having created and planning to maintain the profile
Identifier of the profile
URL of the human-readable specification document
URL of the OWL Ontology and the name of the used format (e.g., RDF/Turtle, RDF/XML, JSON-LD)
Optional: URL of the JSON-LD context resource
Optional: URL of the W3C Profile Vocabulary resource

[dx-prof]: The Profiles Vocabulary. R. Atkinson, N.J. Car. W3C, April 2019, W3C Working Draft. URL: https://www.w3.org/TR/dx-prof/
[json-ld]: JSON-LD 1.0. M. Sporny, G. Kellogg, M. Lanthaler, W3C, January 2014, W3C Recommendation. URL: https://www.w3.org/TR/json-ld/
[owl]: OWL 2 Web Ontology Language Document Overview (Second Edition). W3C OWL Working Group, W3C, December 2012, W3C Working Draft. URL: https://www.w3.org/TR/owl-overview/
[rfc3986]: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter, IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[rfc3987]: Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987
[skos]: SKOS Simple Knowledge Organization System Reference. A. Miles, S. Bechofer, W3C. August 2009. W3C Recommendation. URL: https://www.w3.org/TR/skos-reference/

[RFC2119]: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174

ODRL V2.2 Profile Best Practices

Abstract

Status of This Document

1. Conformance

2. Introduction

3. Identifiers and Annotations used in Examples

3.1 Namespaces:

3.2 Profile Identifiers:

3.3 Annotations:

4. What an ODRL Profile can define

4.1 Additional Actions for Rules

4.2 Additional Constraint Left Operands

4.3 Additional Constraint Operators

4.4 Additional Party Functions

4.5 Additional Asset Relationships

4.6 Additional Constraint Right Operands

4.7 Additional Logical Constraints operands

4.8 Additional Policy Conflict Strategy Preferences

4.9 Additional Rule Subclasses

4.10 Additional Policy Subclasses

4.11 Additional Constraint Subclasses

4.12 How to use multiple Profiles in a single Policy

5. What the Core Profile does not define

5.1 What may be ignored, and what not

6. Prerequisites for defining an ODRL Profile

6.1 A globally unique identifier of the Profile

6.2 The Profile as a stable web resource

6.3 Generating additional specifications of this Profile

7. Resources defining an ODRL Profile

7.1 Human-readable specification

7.2 OWL Ontology

7.3 W3C Profile Vocabulary

7.4 JSON-LD context document

8. Making an ODRL Profile publicly available

9. Registering a profile with the ODRL Community Group

10. Informative references

A. References

A.1 Normative references