Contract Metadata

Metadata about the contract is suggested to be expressed using the following properties based on [[DCTERMS]]:

• dct:title - Indicates title of contract
• dct:conformsTo - Indicates a standard or specification to which the contract conforms to e.g. a technical specification outlining which fields are present in the contract or a legal requirement or a standard for expressing contracts
• dct:created - Indicates date of contract creation. Date of creation is not the same as date of enforcement or when the contract becomes 'active', and only refers to when a contract was completed in terms of its drafting
• dct:issued - Indicates when the contract was issued or given to a party
• dct:creator - Indicates entity that created or drafted the contract. Creator refers to the entity that was responsible for determining the contents of the contract. For standard form contracts, only the parties involved in determining the terms and conditions should be listed as creators. In a negotiated contract, all parties will be listed as creators
• dct:modified - Indicates the date when the contract was modified e.g. as part of the negotiation process
• dct:dateAccepted - Indicates date when contract was accepted all parties. All parties may not accept the contract at the same date, in which case the date of the last party accepting the contract should be used
• dct:hasPart - Associates a contract with a contractual part. A contractual part can contain clauses or other elements and is a useful abstraction to create modular resources that can be independently used or reused across contracts
• dpv:hasIdentifier - Indicates the legally relevant identifier of the contract. Legally relevant here refers to an identifier that is relevant to legal obligations and investigations e.g. tax identifiers shared with the tax office. For other identifiers, use dct:identifier
• dct:language - Indicates the language used in the contract
• dct:provenance - Indicates the provenance of the contract e.g. previous versions in a negotiation process. The [[PROV-O]] ontology can be useful to represent provenance information associated with activities and artefacts
• dct:subject - Indicates the subject of the contract. The subject can be the description used in the contract as to its main topic or subject. To indicate specifics such as service, purpose, or technology - the relevant DPV concepts should be used
• dpv:hasDuration - Indicates the duration for validity of the contract
• dpv:hasEntity - Indicates a party to the contract. If the party has a specific role in the contract, e.g. Controller, Data Subject, Service Provider/Consumer - then the relevant DPV concept and property should be used instead

Contract Types

Contract types represent the vocabulary of contract types which reflects the way contracts are defined and interpreted towards specific purposes. For example, [=DataProcessingAgreement=] represents contract concepts typically used for processes involving (personal) data, [=ContractByEntityType=] represents contracts such as B2B (Business-to-Business), B2C (Business-to-Consumer), etc., and [=ContractByDomain=] represent contracts with specific interpretations such as for licensing agreements and employment.

Contract Status

To represent the status associated with a contract, the concept [=ContractStatus=] and the relation [=hasContractStatus=] are provided. A taxonomy of statuses representing the lifecycle of contract formation and use is provided, for example [=ContractDrafted=] to indicate the completion of contract drafting process, [=ContractUnderNegotiation=] to indicate the contents of the contract are being negotiated and that the contract is being accepted/signed by involved parties, [=ContractAccepted=] indicating all parties have accepted the contract, and [=ContractTerminated=] indicating the contract has been terminated.

[=ContractFulfilmentState=] represents the status associated with fulfilment of a contract in terms of its requirements and obligations. It is associated using the relation [=hasContractualFulfilmentStatus=]. Specific fulfilment states are provided, for example [=ContractFulfilled=] indicating all requirements of the contract have been fulfilled, [=ContractBreached=] indicating a breach of contract, and [=ContractUnfulfilled=] indicating the requirements have not been fulfilled (but it isn't a breach yet e.g. there is still time/opportunity to complete them).

Contractual Clauses

[=ContractualClause=] represents the contents of a contract, commonly referred to as 'clauses' or 'terms' or 'conditions'. They are associated with a contract using the relation [=hasContractualClause=]. A taxonomy is provided to represent commonly utilised clauses. The concept [=ContractualClauseFulfilmentState=] represents the fulfilment state of the contractual clause, and is indicated using the relation [=hasContractualFulfilmentStatus=].

Contract Controls

[=ContractControl=] represents a control for an entity to make or exercise a decision regarding a contract. A taxonomy of common controls is provided, for example [=AcceptContract=], [=OfferContract=], and [=TerminateContract=]. The relation [=hasContractControl=] is used to associate the control with a contract or clause. Controls can be used to indicate where specific actions can be taken, for example to indicate that accepting a contract can be done by sending a request or visiting the stated URL, or to express specific requirements which must be satisfied before the action can be completed, for example to state termination of a contract occurs over a duration.

Consent Types

By default, consent is expected to adhere to several requirements such as being informed, freely given, and so on - typically defined within law or other relevant guidelines, that determine how it is requested, expressed, and evaluated for validity. In DPV, these are referred to as types of consent.

DPV provides InformedConsent and UninformedConsent as two distinct concepts related to whether the consent is informed or not. For more types of informed consent, the concept ImpliedConsent specifies when consent is indirectly expressed or is assumed, and ExpressedConsent for when the individual specifically takes an action to (only) express their consent. The difference between the two can be better understood as follows: if the individual performs an action, and that action only relates to consent, then it is said to be expressed consent, whereas if that action also relates to other matters in addition to being about consent, then the interaction is said to be implied (form of) consent. Clicking a button on a consent notice is a direct action and is thus a form of expressed consent. Assuming consent based on continued scrolling of a web page is an indirect or assumed action, and is thus implied consent.

When the expressed action for consent only (and only) refers to matters related to consent, then such consent is represented by ExplicitlyExpressedConsent. For example, if a button for expressing consent relates to conveying decisions about consent, but also other things such as to navigate to the next page, then this is a clear and specific action for expressing consent. However, if such a button only relates to indicating consent, then it is explicitly about consent, and is thus an instance of Explicitly Expressed Consent.

Consent Status

The state or status of consent refers to the stage of information about a particular consent instance within its lifecycle. For example, (given) consent first starts with the identification of need to ask consent, then issuing a request (to the individual), making a decision (by the individual), and then following it up with further actions such as the individual withdrawing it. Keeping track of such information is necessary in order to determine whether the current stage of consent information is suitable for its use in justifying processing of personal data governed by that consent, as well as to fulfil obligations such as to keep records of consent. To assist with such consent information management, DPV provides Consent Status as a way to represent the lifecycle and usefulness of an instance towards processing personal data.

DPV's Consent Statuses are represented by ConsentStatus and indicated using hasConsentStatus relation. The statuses are segregated into two categories based on their interpretation towards processing: ConsentStatusValidForProcessing and ConsentStatusInvalidForProcessing. There are (currently) only two statuses that are valid for processing: ConsentGiven representing the individual has consented, and RenewedConsentGiven where an earlier given consent is renewed, refreshed, or reaffirmed.

The rest of (currently) 8 statuses refer to various stages that are considered invalid for processing. These are: ConsentUnknown for when information about the status is unknown or unconfirmed, ConsentRequested for when a request to obtain or give consent has been made, ConsentRequestDeferred for when the request was opted to be dismissed or delayed without a decision, ConsentRefused for when consent was refused, ConsentExpired for when the validity (temporal or otherwise) associated with a given consent instance has lapsed, ConsentInvalidated for when a given consent instance is found invalid e.g. by a court, ConsentRevoked for when a given consent instance is revoked or terminated such as when a service provider stops providing the service, and ConsentWithdrawn for when the individual withdraws a previously given consent.

Consent Indication

To indicate which entity is responsible for a specific consent stage (e.g. individual for given consent, requestor for consent requested), the relation isIndicatedBy is provided. It can be used with any Entity such as DataSubject or its subtypes such as User or specific instances of these to record information regarding who was responsible for the indicated status and consent action. To indicate the method by which an entity has indicated the specific consent, the relation hasIndicationMethod is provided. To indicate the time (or similar temporal information), the relation isIndicatedAtTime is provided.

To specify consent provided by delegation, such as in the case of a parent or guardian providing consent for/with a child, the isIndicatedBy relation can be used to associate the parent or guardian responsible for providing consent (or its affirmation). Since by default the consent is presumed to be provided by the individual, when such individuals are associated with their consent, i.e. through hasDataSubject, the additional information provided by isIndicatedBy can be considered redundant and is often omitted.

To indicate how consent is to be provided or withdrawn e.g. how should an individual express or withdraw their consent, DPV provides Consent Controls as: ProvideConsent for the individual to provide or give their consent, ObtainConsent for the organisation to obtain or collect consent from the individual, WithdrawConsent for the individual to withdraw their given consent, and ReaffirmConsent for entities to re-affirm their previously provided or obtained consent. To indicate how to implement the action e.g. provide consent, the relation isExercisedAt should be used.

Duration of Consent

To indicate the duration or validity of a given consent instance, the existing contextual relation hasDuration along with specific forms of Duration can be used. For example, to indicate consent is valid until a specific event such as account closure, the duration subtype UntilEventDuration can be used with additional instantiation or annotation to indicate more details about the event (in this case the closure of account). Similarly, UntilTimeDuration indicates validity until a specific time instance or timestamp (e.g. 31 December 2022), and TemporalDuration indicates a relative time duration (e.g. 6 months). To indicate validity without an end condition, EndlessDuration can be used.

While the above information considered duration as determining the validity of given consent, there are also other uses of duration associated with consent. For example, the duration information is intended to be a trigger to confirm or renew consent instead of rendering it invalid immediately. Or, the duration associated with ConsentRequested could be used to indicate when consent should be requested again.

Consent Controls

1. [=ObtainConsent=] for controllers to obtain consent
2. [=ProvideConsent=] for data subjects to provide consent
3. [=WithdrawConsent=] for data subjects to withdraw consent
4. [=ReaffirmConsent=] for controllers and data subjects to reaffirm consent (use with [=ObtainConsent=] or [=ProvideConsent=])

Classes