This document presents good practices in developing, defining and making public an ODRL Profile.

Introduction

The Open Digital Rights Language (ODRL) 2.2 defines a data 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 data 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 data 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.

Identifiers and Annotations used in Examples

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

Namespaces:

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

Profile Identifiers:

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

Annotations:

What an ODRL Profile can define

This sections walks through the ODRL Profile Mechanism of the ODRL Data 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 seqence of additional specifications follows priorities of use expected by the ODRL Community Group.

Additional Actions for Rules

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:

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 .

Additional Constraint Left Operands

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:

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." .

Additional Constraint Operators

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 .

Additional Party Functions

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 .

Additional Asset Relationships

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.

Additional Constraint Right Operands

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:

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 .

Additional Logical Constraints operands

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 Constaints is satisfied"@en ;
  rdfs:label "Exactly Two"@en ;
  skos:note "This property MUST only be used for Logical Constraints."@en .

Additional Policy Conflict Strategy Preferences

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 .

Additional Rule Subclasses

The ODRL Data 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 subclasses; their definitions must comply with the design of the basic Rule Class:

A new Rule subclass must be defined as disjoint with all other Rule subclasses.

Defining a subclass of Rule allows:

How To Define a Subclass of the Rule Class

Option 1: As a direct subclass of the Permission class or the Prohibition class or the Duty class. It can be used in a Policy this way:

  • 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
  • AND/OR: 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
  • AND/OR: 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
  • It is not required to create a new subclass of Policy for this purpose. 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 a obligation property must be of type Duty (or a subclass of it) is fulfilled.

Option 2: As direct subclass of the Rule class. It can be used in a Policy this way only:

  • A new subclass of Rule must be defined by the Profile
  • A new subclass of Policy must be defined by the Profile ...
  • ... this new Policy subclass must include a new property, this property has as type this new Rule subclass

Use cases covered by subclasses defined by a Profile:

  • a) A policy uses the Policy class of the ODRL Recommendation, the property permission uses the Permission class or a subclass of it as defined by the Profile, the property prohibition uses the Prohibition class or a subclass of it as defined by the Profile, the property obligation uses the Duty class or a subclass of it as defined by the Profile.
  • b) A new subclass of Rule is defined and a corresponding property of a new subclass of Policy is defined for it, both is defined by the Profile. Be aware: The use of this new subclass of Policy requires to use at least one of the properties permission, prohibiton or obligation.

Design Consideration
Please check if a rule required by the to be covered use case can be expressed - in this sequence:
1) by the Permission, the Probition or the Duty class as defined by ODRL Recommendation (this does not need a definition by a Profile)
2) by subclass of the Permission or Prohibition or Duty class, as defined by the Profile (the new subclass(es) must be defined by the Profile)
3) 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 the new subclass of Policy must be defined by the Profile)

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 :Rule ;
  owl:disjointWith :Permission, :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 .

Additional Policy Subclasses

The ODRL Data 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 new Policy subclass must be defined as disjoint with all other Policy subclasses, except the Set subclass.

Defining a subclass of Policy allows:

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 .

How to use multiple Profiles in a single Policy

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:

What the Core Profile does not define

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

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!

What may be ignored, and what not

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.

Prerequisites for defining an ODRL Profile

A globally uniqe identifier of the Profile

Each Profile must have a globally unique identifer. 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 identifer of a namespace of concepts defined by the Profile as it would be hard to distingish if a profile or a namespace is identified when using this identifier.

The Profile as a stable web resource

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.

Generating additional specifications of this 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 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:

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.

 

Resources defining an ODRL Profile

Human readable specification

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

It should include:

OWL Ontology

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:

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 .

W3C Profile Vocabulary

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

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/>;
.

JSON-LD context document

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"}
    }
}

Making an ODRL Profile publicly available

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

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 of 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.

Registering a profile with the ODRL Community Group

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:

 

Informative references

[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/