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:

• 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

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:

• 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

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

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.

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.

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:

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

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:

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

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

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

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 .

Additional Policy Subclasses

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.

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

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:

• 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 Profil 1 can also be adopted for another Profile, e.g., Example Profile 2. (Note: be aware that the identifier of a Profile and the identifer 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.

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.

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

A globally unique 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 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.

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

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:

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

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:

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

## 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:

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

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

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