Overview of the MPEG-21 Media Contract Ontology

Abstract

The MPEG-21 Media Contract Ontology (MCO), a part of the standard ISO/IEC 21000, is an ontology to represent contracts dealing with rights on multimedia assets and intellectual property protected content in general. A core model provides the elements to describe the permissions, obligations and prohibitions exchanged in the clauses of a contract. Specific vocabulary is defined in a model extension to represent the most common rights and constraints in the audiovisual context. Design principles, a methodology and a comparative analysis are given, as well as the practical guidelines to use the standard. A thorough description of the contract creation workflow from an original contract is given, including a sample contract text, the RDF version, the detailed mapping of the most relevant clauses and the reconstructed version. A set of MCO-related tools is described, including (i) the reference software to create and edit MCO contracts; (ii) modules to identify, store, search, validate and deliver MCO contracts and (iii) a tool to convert between the akin Contract Expression Language (CEL) contracts and the MCO contracts and (iv) the actual use of MCO in the Rightsdraw family of services.

Keywords

Standards knowledge representation contracts multimedia

1. Introduction

The international legal framework on the protection of intellectual property1

¹
See the Berne Convention for the Protection of Literary and Artistic Works (1886).

distinguishes between exploitation rights and moral rights. The creator of a work has some unwaivable and inalienable moral rights (like the right to be identified as the author) plus some exploitation rights (like the right to distribute copies to the public), which are transferable and of limited duration. The exploitation rights can be transferred with exclusivity or not in exchange of an economic compensation, and their exercise can be limited by different constraints and conditions, typically specified in written contracts.

A media contract is an agreement between business parties for the deal of exploitation rights on audiovisual works.

Although the contractual relationships play a central role in the commerce of media assets, they are still largely managed with old-fashioned paradigms, in contrast with other areas of media asset management such as ingestion, annotation, cataloguing, storage, retrieval and distribution, which have begun to benefit from a knowledge representation based on ontologies (see the BBC case [34]). The representation of contracts as RDF documents supported by facilitates achieving better metadata interoperability and systems integration. Unfortunately, many contracts are still created, signed and kept in a paper form or, if in digital form, in a non-machine-readable environment.

This paper describes and analyzes the MPEG-21 Media Contract Ontology (MCO) [23], a standard based solution for representing contracts – and whose editors are authors of this paper.

MPEG-21 MCO is part of the MPEG-21 specification, formally known as ISO/IEC 21000. MPEG-21 is devoted to the definition of a framework for multimedia delivery and consumption across different networks and devices. In particular, MPEG-21 defines a generic content encapsulation called Digital Item, capable of identifying, structuring and storing different types of digital content (Part 2: Digital Item Declaration and Part 3: Identification). This content can be reliably managed and protected across networks (Part 4: Intellectual Property Management and Protection), and it can be adapted to the heterogeneous usage environment with different networks, terminals and users (Part 7: Digital Item Adaptation). MPEG-21 also defines an expression language for declaring licenses (Part 5: Rights Expression Language) along with a dictionary of terms (Part 6: Rights Data Dictionary), and an ontology (Part 19: Media Value Chain Ontology (MVCO) [24]), capable of representing the intellectual property objects along its life cycle as well as the actors performing any intellectual property-related action over the resources. However, no specific formats had been defined for representing contracts.

The MPEG initiative on specifying formats for media contracts started with the definition of an XML-based expression language: the Contract Expression Language (CEL), which eventually became Part 20 of MPEG-21 [25] and is well described in [37]. In parallel, a complementary work was carried out towards an ontology-based representation: the Media Contract Ontology, now Part 21 of MPEG-21. Parts of CEL and MCO reflect the results produced in the European project PrestoPRIME2

FP7-ICT 231161 http://www.prestoprime.eu.

and its audiovisual rights ontology [9], defined as extension of MVCO. CEL and MCO are not competing but complementary and aligned languages, simultaneously conceived to satisfy needs in different contexts, and whose interoperation is possible.

This paper describes the Media Contract Ontology, starting by the design principles, requirements and methodology in Section 2. After Section 3 (related work), Section 4 describes the main elements of the ontology and Section 5 details some practical aspects, illustrated with examples and guidance for its use. Section 6 describes the MCO standard Reference Software and some basic applications. Future work and conclusions are outlined in Section 7.

2. Design principles, and requirements and methodology

The choice of the design principles as well as the methodology to develop the ontology have been determined by the working framework, i.e., one standardization body with well established procedures, standard timelines, control mechanisms and conflict resolution strategies. Traditional methodologies to develop ontologies (like Methontology [12], which has been applied to the legal domain [5]) cannot be adopted in this rigid context. For example, while most methodologies recommend an iterative life-cycle, requirements are formally collected once and no iterations are foreseen in the MPEG development workflow.

The International Organization for Standardization (ISO), together with the International Electrotechnical Commission (IEC), develops and publishes international standards, by means of Technical Committees (TC) or Joint Technical Committees (JTC), further structured in SubCommittees (SC) and Working Groups (WG) of experts of the various specific areas. The Moving Picture Experts Group (MPEG), officially identified as ISO/IEC JTC1 SC29 WG11, is one of such groups and it sets standards for audio and video compression and transmission as well as for metadata. The following features of the MPEG working framework strongly influenced the design principles and the development methodology for the ontology:

High consensus. The positive vote of at least 5 countries is needed for a standard to be approved and debate is promoted so that differences are solved inasmuch as possible – much appropriated for the development of ‘ontologies’, which are generally understood as the representation of consensual knowledge.

Formal procedure. The standardization process is a well-defined procedure with fixed stages. These steps, which start with a call for requirements, matches well other ontology development methodologies and forces every step to be profusely documented.

Working groups. Any expert can participate in the working groups for the standard edition, which are convened and supervised by the systems group. In practice, heterogeneous domain and technology experts work together.

Evolution. Formal procedures for corrigenda and amendments exist, being also possible second editions. This also favors the continuous development of ontologies.

Closed specifications. ISO standards, in general, are not free documents. This feature clashes with the general practice of publishing and disseminating ontologies, however, electronic documents such as an OWL file are typically disclosed freely.

Self-containment. ISO standards are planned to last for years, and introducing dependencies from other sources is discouraged. Consequently, self-contained solutions are preferred over documents making references to external, possibly mutable, resources. This feature goes also against the common practice in the semantic web of reusing others’ resources.

The well-established procedures in the standardization process force the adoption of good practices in the ontology development. In particular, the MCO was designed to cover a set of requirements formally specified in 2010 [28] and further refined after a core experiment for mapping text contracts into machine readable documents [29].

The requirements in [28] were not directly imposed on the contract format, but on the functionalities that contract-based services had to provide. The list included 13 functionalities, namely: authenticate contract (confirm the identity of the signatories), check with contract (verify if a usage request is within a contract), create contract, deliver contract (possibly adapted with MPEG-21 DIA), identify contract (with MPEG-21 DII), negotiate contract (MPEG-M orchestration), post contract (possibly with MPEG-U), present contract (possibly with MPEG-V), process contract (editing the contents) and request, search, revoke and verify contract. This specification of contract-based services was translated into requirements for the contract language. It is remarkable that the requirements did not include any provision for contract breaches and remedies, nor included advanced reasoning tasks beyond the support to the check with operation (if a requested action under certain conditions falls under the clause of a contract or not). Twelve of the thirteen requirements handled with managing the contract (identifying, storing, etc.), and the “check with” one was a simple operation to be implemented by a service and not to be calculated by means of an ontology reasoner: the most important needs were the preservation of contracts in a structured manner, the easy SPARQL querying of some of the contract features and the easy mapping to existing enterprise systems within the MPEG-21 framework.

Five institutions participated in the experiment, which consisted of the following steps: (i) a set of contracts was selected with the criteria of including different media types, concerning different parties from different business models and of different length and complexity; (ii) the set of contracts was analyzed in their context by legal experts in the area; (iii) a mapping for these contracts to a candidate machine readable format, first XML then RDF, was made by hand and (iv) the mappings were evaluated with determined criteria.

These criteria included (i) the technical soundness of the output documents (syntactic and semantic); (ii) a comparison of the defined entities with the definition of the referred concepts; (iii) the ability to preserve the contract, granting that reconstructed contracts conveyed sufficient information; (iv) ability to satisfactorily structure and present the contract and (v) ability to link the contract to other external entities (parties, assets). The results of these experiments gave rise to both an XML representation (CEL, Part 20 of MPEG-21) and an RDF representation (MCO, Part 21 of MPEG-21) of the contract; the latter being described in this paper.

3. Related work

The MPEG-21 MCO is not an academic work intending to improve the state of the art. On the contrary, as any standard it sets the recommended practice in its domain and innovations are discouraged. This section describes the related work coming from different areas, collecting the perspective of legal experts, computer scientists and logicians alike.

The community of experts in computation and law has produced a number of legal ontologies (an extensive enumeration is given by Casellas [3]) following different approaches [42], derived from the legal theory perspective, from the cognitive sciences view, from the socio-legal studies or from the computational perspective.

Some ontological resources in the legal domain have originated in the framework of European projects. ESTRELLA (Standardized Transparent Representations in order to Extend Legal Accessibility) produced in the last decade several ontologies of reference in the area, like the ontology of fundamental legal concepts [40] or the interchange format for legal knowledge systems, LKIF [18]. Other projects have fostered the development and use of legal ontologies in different contexts, like DALOS (Drafting Legislation with Ontology-based Support Project), to support legislative drafting [13] or ALIS (Automated legal intelligent System), which produced an ontology for the intellectual property rights [4] and comparable to the analogous ontology IPROnto [7].

Some legal ontologies are directly related to the contracting domain. Yan’s ontology [43] was designed with the mere objective of clarifying the concepts and relations in the domain of business contracts and contract management. Kabilan’s Multi Tier Contract Ontology [30] also tried to fixate the conceptual meanings and interpretations of the contractual obligations inherent in a business contract. Kabilan described three levels for contract ontologies, the upper one being the core contract ontology, the middle one being the specific domain contract ontology and the lower one being the template level contract ontology, suitable for a very specific contract type. The MPEG-21 MCO shares this multi-tier view, defining a core ontology plus a number of extensions.

The legal ontologies presented so far have a long tradition, are well founded and some of them are supported by subsequent reasoning and argumentation tools; however, the implied meaning of their concepts goes beyond the scope and purpose of the MCO contracts, whose compactness was a design goal: MCO was required not to depend on upper ontologies and it is not related at all with these legal ontologies.

In some computer applications, Rights Expression Languages (RELs) and policy languages (like XACML) have played a role governing the access to digital resources. These languages not only allow describing conditions verifiable by a machine, but also declaring permissions and restrictions that cannot be computed. Their structure is suitable for representing contracts as well, with the addition of new vocabulary. In fact, the possible use of RELs for representing contracts has been suggested for ODRL (Open Digital Rights Language [17]) and MPEG-21 REL [8]. However, these extensions do not capture well the structure of the contract nor the relation between the clauses in the text and the operative elements in the electronic contract.

Alternative efforts have focused on making a better logical grounding towards advanced reasoning, possibly using (standard and non-standard) deontic logic systems (see Gabbay [14] for a recent formulation of different possibilities). The representation of contracts can be done in terms of a formal logic, like the Business Contract Language [16], with powerful reasoning capabilities that include the management of contradictions and conflict resolution procedures. Prisacariu and Schneider propose another contract logic [33], combining deontic logic with a propositional logic of actions to handle complex sequences of actions and tackling contract violations. Daskalopulu [6] also analyzes and represents obligation and business exchange transition states through deontic logic.

Other systems have been described with less logical abilities but better expressivity, like Cosmos [31], a contract format described in a well detailed UML object model. A Cosmos contract comprised structures to describe the parties, a fixation (signature) and the performance of activities to be done by the parties, including payments and the provision of goods and services with a given quality of service. Similar elements can be found in the OASIS eContracts [32] specification, which describes a general-purpose, XML-based language. Being a lightweight model, support is given in eContracts for structuring the document in clauses, declaring the relationship with other contracts and signing or encrypting the documents or parts thereof; further refinements being left for specific extensions. MCO is the latest in this tradition, with the narrower scope of representing contracts in the particular domain of the media contracts.

4. Media Contract Ontology

This section describes the Media Contract Ontology, which is defined by a core model (described in http://purl.org/NET/mco-core), and a first extension for the exploitation of intellectual property rights, (described in http://purl.org/NET/mco-ipre). Other extensions, proposed by institutions different from those in the original editing working group, are in the path of standardization but so far they have only working draft status.

4.1. Overview

The Media Contract Ontology (MCO) is an OWL ontology formalizing a vocabulary to represent business contracts in the media content industry. MCO contracts are RDF documents using that vocabulary.

The media contract defines what the parties agree to exchange in terms of rights and obligations. A contract is not bound to deal with a single work nor to constrain the parties to a single role between “licensor” and “licensee”, although this is the most frequent situation. The most complex part in a typical media contract is the definition of conditions related to the transfer of the exploitation rights. This transfer of rights may be done in exclusivity or not, and may refer to the totality of the exploitation rights or to a part thereof – the latter case being the most common, as it fosters the profitability of the market. Sublicensing is very often explicitly permitted or prohibited, allowing thus the licensee to subsequently grant licenses or not to third parties.

Fig. 1.

Main classes and object properties of the MCO. Classes are represented with ellipses, object properties with arrows (linking domain and range classes). Prefixes, either mvco or mco-core have been omitted in this figure.

A complex statement defining some exchanged rights, with conditions, on some content or service is also named hereafter an “operative clause”, as it defines in which operative context a given action is allowed, prohibited or obligated. The set of operative clauses is called the “operative part” of the contract. The fulcrum of an operative clause is the “deontic expression”, which encompasses the concepts of permission, prohibition and obligation. As the parties freely agree on the terms of the contract, they actually exchange the promise to respect the rules they defined in the operative clauses. While this kind of assertions are studied by the deontic logic, and such expressions can be object of reasoning (as in some of the systems described in Section 3), the MCO representation does not aim at matching any specific formal system. The RDF statements of the MCO contract are thus limited to represent the operative clauses in a machine-readable form.

The MPEG-21 MCO standard foresees electronic contracts directly created in RDF as well as electronic contracts derived from existing ones in natural language. For this reason, being able to declare mappings between the digital and the narrative forms is an important requirement, and for any deontic expression in the digital form it is possible to declare the textual clauses whence it came from.

Contract clauses are identified as well as the contract itself and any other relevant entity. The relationship between contracts in MCO is as important as in any business agreement, and the standard comprises the means for declaring prevalence, cancellations and amendments among other relationships.

The MCO consists of a core model, which provides the elements to make generic deontic statements, and an extension which provides the vocabulary to describe the commercial exchange of exploitation rights of intellectual property assets. More extensions might be envisaged for other kinds of objects, like specific types of content, raw data, etc. For example, as of March 2015, a second edition of the MCO standard has started to be discussed, including a new extension for payments and notifications and a new extension for the expression of rights expression language (MPEG-21 REL) acts [27].

The MCO core ontology consists of 666 OWL2 axioms of moderate complexity. OWL2 is needed, as some negative object properties have been asserted, but the ontology does not fall under any of the RL/QL/EL profiles – one of the reasons being the use of DisjointClasses axioms.

MCO adds relatively few semantics over the CEL XML (and some information using CEL is not expressible using MCO), but it favors the publication of contracts as linked data and it enables SPARQL queries over RDF – also integration with other domains is favored.

4.2. The MCO Core model

The MCO Core model, whose URI3

³
As MCO is OWL2, identifiers are IRIs instead of URIs (IRI – Internationalized Resource Identifier: a generalization of URI permitting use of Unicode characters), although the standard makes reference to both indistinctly.

is urn:mpeg:mpeg21:mco:core:2012 and its preferred prefix is mco-core, provides the elements for the expression of permissions, obligations and prohibitions – the general terms that a contract usually handles. These statements are the promises that are exchanged in the contract between the parties. In fact those patterns are also tackled in various languages for rights expressions, as shown in the comparison made in [39].

Given that MCO is imbricated in the MPEG-21 framework, the description of these parties as well as some of the clauses tying them, is done in terms of elements which are already defined in (or derived from) other parts of the standard, mostly the Media Value Chain Ontology (MVCO [24]). Class instances of the classes in MVCO, whose URI is https://purl-oclc-org.web.bisu.edu.cn/NET/mvco.owl, can represent the transformation of one entity of a kind of intellectual property object (an mvco:IPEntity) into another one, as well as the required permissions to execute these transformations.

The general overview of the MCO Core model is shown in Fig. 1.

4.2.1. Contract and parties

The Media Contract Ontology defines an mco-core:Contract class, whose instances represent the actual documents – a contract is thus uniquely identified by an IRI. Contracts can be referred from other contracts to be superseded, altered or extended.

Contracts have parties, which can be natural or legal persons (e.g. people, organizations, etc.), and they are ultimately signed with the digital signature of actual users representing themselves or their organizations, as shown in Fig. 2.

Fig. 2.

Contracts, organizations and users.

Some of these elements are expected to be further described with metadata attributes, i.e. users can get a vCard by using the hasVCard property (see [21]) or be attributed with standard Dublin Core elements.4

⁴

The ISO standard 15836, which establishes a standard for cross-domain resource description, is known as “Dublin Core Metadata Element Set”.

Contracts can be totally or partially encrypted by using the XML Encryption Syntax and Processing [10] and linked to the Contract instance by the mco-core:encryptedContractPart object property.

4.2.2. Contract clauses

Any contract, as an exchange of promises, contains a set of deontic expressions: permissions, prohibitions and obligations. The MVCO defined the mvco:Permission class, from which the rest could have been expressed – the three deontic modalities can be simplified by using a single one. However, to ease the use of MVCO, specific classes complement the permission: mco-core:Prohibition and mco-core:Obligation.

The permission model revolves around the concept of deontic expression (i.e. a permission, obligation or prohibition) which can be issued by a user (mvco:User), and permits an action (mvco:Action) having as required zero or more facts to hold (mvco:Fact). The action can be further described as being acted by a certain user or set of users over zero or more IP Entities (see Fig. 3).

Fig. 3.

Permission model in MCO.

If the deontic expression (mco-core:DeonticExpression) is an Obligation or a Prohibition (mco-core:Obligation and mco-core:Prohibition respectively), the object property mvco:permitsAction is replaced by mco-core:obligatesAction and mco-core:forbidsAction respectively.

A contract, thus, is in essence a set of DeonticExpressions, which implement one or more natural language contract clauses (see Fig. 4).

Fig. 4.

Deontic expressions are issued in contracts and implement textual clauses.

4.2.3. Expression of conditions

In standard contracts, permissions are seldom given in exchange of nothing, and conditions are present in almost every contract. To express conditions, the set of facts that must hold is given. However, the actual conditions are not declared by the MCO core language, but by its extension presented in Section 4.3 (or other possible extensions). The MCO uses the class mvco:Fact (any sentence with truth value) and the boolean operators to join atomic Facts into more complex facts.

The boolean operators (represented by the class mco-core:FactComposition) are mco-core:FactUnion (∨), mco-core:FactIntersection (∧) and mco-core:FactNegation (¬), following the pattern used in the privacy ontology PPO [41]. The arguments of these logical functions are given by means of the object property mco-core:hasFact, as illustrated in Fig. 5. No rule (SWRL, SPIN etc.) maintains the consistency of the truth values in the fact compositions, being this task left to contract management software implementers.

Fig. 5.

Boolean operators with Facts. Non prefixed terms are in the mco-core namespace. The dashed line represents the subClassOf property, going from subject to object. The DeonticExpression can be any of its subclasses (Permission, Obligation, Prohibition) as well as the FactComposition (which can be FactIntersection, FactUnion or FactNegation).

4.2.4. Example

If Alice wants to allow Bob to make a derivative work of one of her works, called MyWork, the minimal set of class instances to be defined would be:

A class instance representing the contract.

Two class instances for the parties, representing Alice and Bob.

A class instance representing Alice’s Work.

A class instance representing the permission.

A class instance of the Action, in this case instance of the mvco:MakeAdaptation class.

Figure 6 shows all the instances along with the main class they belong to.

Fig. 6.

Set of instances to represent a permission from Alice to Bob to make adaptations of her work. Class individuals are represented in boldface (empty brackets meaning ‘blank node’). Arrows are also connecting the class individuals.

The equivalent code for the Fig. 6 is shown in Table 1.

4.3. Extension for exploitation of intellectual property rights

This extension is intended to represent the most relevant information in media contracts both for content and services on content based on MPEG-21 technologies.

This is implemented using some specific vocabulary of the MPEG-21 MVCO classes and extensions thereof to represent the main information in media contracts, including specific elements to address the most relevant information found in those contracts for permitting the exploitation of intellectual property rights. Its URI is urn:mpeg:mpeg21:mco:ipre:2012 and the preferred prefix is mco-ipre.

Fig. 7.

Diagram of mvco:Action hierarchy for exploitation rights. As before, dashed arrows depict subclassing relationships.

Table 1

RDF serialization for Fig. 6

The media contracts on content usually convey permissions to execute one of the generic actions found in mco-ipre, like Duplication or Broadcasting, without going into the particularities of the MPEG-21 REL rights (for example a particular Enlarge operation would be better represented with ISO/IEC 21000-55

⁵

The extensión RELE proposed in [39] covers this aspect.

). This MCO extension for Media Contracts is able to represent the most common rights in contracts in the media field and the most frequent conditions in those documents, expressed as Facts which can be required on Permissions or in Deontic Expressions in general.

4.3.1. Description

The MCO extension for exploitation of intellectual property rights does not define any new class without a superclass from mco-core, and it fully conforms to the contract model defined by the Media Contract Core. A number of new classes is defined as a hierarchy of sub-classes of mvco:Action, in order to reflect the exploitation actions as defined by the common protection of the intellectual property. The root of such hierarchy is the Action named mco-ipre:ExploitIPRights, which encompasses all the actions specified by its sub-classes. The defined organization of actions into a hierarchy allows any deontic expression to apply to an action at the desired level of generality/specificity. Granting a general right allows permitting all its specializations. The mentioned hierarchy is depicted in Fig. 7.

Another set of classes allows reflecting the various dimensions which form the space of conditions and restrictions. The root of such hierarchy is a sub-class of Fact named mco-ipre:ExploitationCondition.

Some of the exploitation conditions are expected to be related to other class individuals: mco-ipre:AccessPolicy, mco-ipre:DeliveryModality, mco-ipre:Device, mco-ipre:Means, mco-ipre:ServiceAccessPolicy, and mco-ipre:UserTimeAccess.

The specification of these terms and others in the MCO-IPRE was not derived from the initial list of requirements but from the experience in contract management of the institutions in the working group.

Other sub-classes of mco-ipre:ExploitationCondition, like: mco-ipre:Language, mco-ipre:Length, mco-ipre:Run, mco-ipre:SpatialContext, and mco-ipre:TemporalContext, are expected to be described with the appropriate datatype properties. The MCO-IPRE extension is indeed completed with the definition of a number of these data properties. Most of them are grouped as sub-properties of the generic data property mco-core:factProperty and are defined for allowing a full specification of the exploitation conditions. Finally, other properties, grouped as sub-properties of mco-core:deonticProperty, are attributable to a mvco:Permission.

It can be observed that many conditions on the exploitation of rights are actually related to the modalities of content fruition by the final users. An example is the hierarchy under mco-ipre:DeliveryModality. The legacy communication-to-the-public acted by the broadcasters is “linear”, with a time-schedule over which the viewers have no control. Conversely the modality is “non-linear” if a catalogue is offered to the viewers for independent selection. If the exploitation is constrained over this dimension, one Fact of this hierarchy (i.e. mco-ipre:Linear, mco-ipre:NonLinear or one of its sub-classes) has to be required. Another dimension of this kind is mco-ipre:AccessPolicy, which deals with the possible payment charged to the final user for the content fruition. If the exploitation requires that no payment can be subsequently asked (except for the governmental fees or taxes related to the public service), the Fact mco-ipre:FreeOfCharge, is used. The opposite condition is mco-ipre:Pay that can be further specified withmco-ipre:PayPerView and mco-ipre:Subscription. Two other classes of conditions relate to the modality of making the content available to the final users.

A particular policy of user access (mco-ipre:ServiceAccessPolicy) can be constrained to a media service provider by requiring either mco-ipre:Open, with which all consumers must be allowed to access the service without need of approval, or mco-ipre:Restricted, with which it is required that service provider had explicitly registered the consumers. Notice that a restricted service is not necessarily a pay service.

Eventually, it is possible to require that the time left to the final user for content fruition is limited or unlimited (by the facts mco-ipre:Limited and mco-ipre:Unlimited respectively; being both sub-classes of mco-ipre:UserTimeAccess). For the former case, the condition can be refined by specifying for how long with the mco-ipre:hasValidity data property.

The model also covers the possibility of defining conditions related to the technology used in the delivery to the final user (mco-ipre:Means) and related to the type of equipment intended to be used for the fruition by the final user (mco-ipre:Device). The delivery channel can be specified to be broadcasting, mobile (broadcast or telecommunications), Internet and other. The device can be specified to be a television set, a computer, a mobile device or others.

The fact mco-ipre:Length can be used to constraint the maximum duration of the material actually resulting from the exploitation action. This is typically required when permitting the use of excerpts.

Another condition that was required to be modelled is that of mco-ipre:IPEntityContext, that restricts the exploitation action to a specified editorial context. This condition is frequently originated by the will of performers or organizations contributing to a production for keeping the use of the created material limited to the context of the production.

Other exploitation conditions are self-explaining. The mco-ipre:SpatialContext is used for specifying the territory of the exploitation, while mco-ipre:TemporalContext gives the license period. The language, e.g. for dubbing or subtitles, can be constrained with mco-ipre:Language. Eventually mco-ipre:Run is in the domain of a number of data properties, that specify how to take into account the permitted number of executions of an action along time.

Finally, the class mco-core:ActionRelatedFact, sub-class of mvco:Fact, represents the status of accomplishment of the related action, further refined with mco-core:ActionStarted and mco-core:ActionDone. These classes permit to model the definition of secondary-rights,6

⁶
The term “secondary-rights” is used by buyers (of rights) of some organizations (e.g. RAI) for cases in which an exploitation action (secondary) is only permitted when combined to another exploitation action (primary), that is permitted independently.

an example of which is often mentioned in narrative contract text as “CatchupTV”, which is when content can be made available through the web, but only in combination with (e.g. the day after) linear broadcast over a TV channel. In such cases, the secondary exploitation action (e.g. make available on the web) is permitted only during a time interval specified by the occurrence of a primary exploitation action (e.g. TV broadcast).

Fig. 8.

Expression of a permission, extracted from a real contract. Literals are represented in boxes, and ellipses represent class individuals (URI in boldface and main class below, with brackets denoting ‘blank node’). Arrows represent object or datatype properties relating the resources. Prefix has been omitted for the properties.

4.3.2. Example

The example in Fig. 8 depicts a more complex situation, derived from a real contract, where the permission to make a broadcast is given, subject to certain restrictions (spatial, temporal and of policy of access). The equivalent code for Fig. 8 is given in Table 2.

Table 2
Turtle serialization for Fig. 8

5. Practical aspects and examples of use

This section deals first with some practical aspects related to handling MCO contracts. In particular, it discusses the role of the original textual contracts, the specific relationship with content, the procedure to follow with encrypted contracts, and the cases in which an MCO contract document can be binding. Second, a detailed sample contract in the context of audiovisual preservation is examined. Finally, the workflow for creating a MCO contract from an original textual one is also presented and actually followed for the real example.

5.1. Guidance to MCO aspects

5.1.1. Textual contracts and MCO contracts

MCO can be used for representing pre-existing narrative contracts. The process of converting a textual contract into an electronic contract starts with an analysis that identifies the most important terms in the contract and the related deontic elements. Each of the permissions, obligations, and permissions is translated one by one, irrespective of the number of clauses it was spanning in the textual version. Each deontic expression can point to the precise narrative text excerpts which it implements. In addition, the complete textual version can be embedded in the MCO contract.

For new contracts, it is reasonable to directly create them as MCO, with unambiguous and machine-readable deontic expressions. Professional users of the legal domain can verify the semantics by means of graphical user interfaces of software tools. However these users might be interested in having the possibility to read the equivalent narrative text (a similar approach was described in [38]). Such text can be derived, as the diagrams are, from MCO statements, according to the user’s language, and it is not necessary to have it persistently associated to the contract.

RAI for instance has made a proof of concept in which MCO contract documents, serialized as OWL/XML, are filtered by means of an XSL stylesheet which to produce text/html output with English text. The stylesheet itself includes text portions, derived from the text of the standard, that are used appropriately according to the class to which the individuals of the contract document belong. RAI internal evaluation has shown that, although the result doesn’t always replicate the narrative style of textual contracts, the text is clear and understandable enough, more than the diagrams that in contrast are found arduous by non-technical people.

5.1.2. Referencing MPEG content

Similarly to the contract entity, also the IP-entities object of the contract can be uniquely identified by their IRI. However, two additional identification mechanisms can be used for referencing content from MCO. First, in the case of MPEG content, a Digital Item Identifier (Part 3 of MPEG-21) can be used as data property of the IP-Entity. Besides, it is possible to annotate the IP-Entity with Dublin Core identifiers for referencing identifications possibly used in other environments and/or legacy systems; for example the ISWC (International Standard Musical Work Code), defined by ISO 15707, or the ISAN (International Standard Audiovisual Number), ISO 15706.

5.1.3. Encrypting the contract

In some cases there is the need to keep part or the whole contract encrypted, as it may be considered confidential. For addressing this need, MCO defines a specific data property of the contract class itself, that is named mco-core:encryptedContractPart and has as range a XMLLiteral.

The unencrypted version of the contract can be obtained by decrypting the value of the data property and merging the result with the unencrypted part of the contract. In practice, this process is almost straightforward in the case of XML serialization of the MCO contract.

Partial encryption of RDF documents has been well studied [15]. The suggested procedure for encrypting parts of an MCO contract is the following:

Identify the contract subgraph for which encryption is necessary (for example, an obligation instance and related properties).

Encrypt the subgraph (serialized as XML) using XML Encryption and a symmetric key. Include it in the contract document as an XML literal under mco-core:encryptedContractPart.

The result is a single self-describing RDF-compliant graph containing both, encrypted data and plaintext data. To obtain the unencrypted version of the contract, the value of the data property should be unencrypted and merged with the rest of the unencrypted contract.

5.1.4. Contract templates

For a contract to be binding, it requires the signatures of all parties. If this is not the case, it means that the contract is falling in one of the possible situations in which it is not finally agreed. For instance, one party might have defined an offer that is ready for being proposed to potential parties, who might accept it “as is” or begin a negotiation with subsequent modifications before final common approval.

Another case is that of templates which are used by large organizations or in specific contexts as the basis of rights negotiations and trades. In this context, the parties know very well the terms already defined in the templates and they only have to discuss and agree on the differences, that will include identification of the other party, the object of the contract, and usually the conditions related to spatial and temporal contexts and other details. Deontic expressions defined in the template but not applicable to the particular case will be simply removed.

5.2. Creation of MCO contracts from text documents

The creation of MCO contracts from text documents, possibly resulting from a paper contract digitalization, is a frequent case – as in the long term audiovisual preservation scenarios of the PrestoPRIME7

⁷
PrestoPRIME – Keeping Audiovisual Content Alive – Available at http://www.prestoprime.eu. Accessed Dec. 2015.

[2] and Presto4U8

⁸

Presto4U – European Tech. for Digital Audiovisual Media Preservation. Available at http://presto4u.eu. Accessed Dec. 2015.

projects. A real example of contract, from which sensible or confidential information has been removed, is presented in Table 3.

Table 3

Example of an original paper contract

The process for contract creation from a text contract described hereinafter is the one followed by using the Rightsdraw editing service [1] described in Section 6.2. Figure 9 (which is not part of the standard) shows the contract creation workflow.

Fig. 9.

Contract creation workflow from an original contract.

Having the text of the original contract, the process starts by creating a new MCO document with its own IRI, importing the appropriate extension of MCO, such as mco-ipre, indicating all the required prefixes, and containing a NamedIndividual of class mco-core:Contract, which will represent the contract itself.

The contract is then identified by its IRI. Dublin Core annotation can be used for establishing a title and for setting the contract date. The narrative textual version of the contract can be inserted immediately as a data property of the contract individual.

The second step consists of identifying the parties of the contract, and inserting them into the MCO document with all the desired details, with the help of Dublin Core annotations. Each party is identified by its IRI, but other information can be found in the narrative text that can be inserted in the MCO document. In this example we use dc:title for the name of the organization, dc:identifier for providing its international VAT (Value Added Tax) Number, and the data property mco-core:Address.

If the party is an Organization, as in this case, it will be necessary to indicate a signatory User, in order to let the contract to be binding.

The third step introduces Intellectual Property Entities according to its definition in the Media Value Chain Ontology permission model.

Thus, the person analyzing the narrative contract will have to identify in the text the parts that originate the permissions. This can be a difficult task in the case of complex narrative contracts, because a preliminary sentence that might indicate a single permission can be later developed in different cases in which the particular conditions are defined, so that several distinct permissions have to be created.

The subsequent step is to ensure that all the object properties are properly declared. In particular, for each permission it has to be known exactly: in which contract it is issued, which party is the issuer, and which party can act the permitted action; eventually, but mostly important, over which object (content or service) the action can be acted. A similar procedure applies to obligations and prohibitions.

Fig. 10.

Diagram representing the initial steps of creating a MCO contract document.

Fig. 11.

Diagram representing the permission resulting contract document.

Optionally, it is possible to indicate for each deontic expression which is the part of narrative contract text that is implemented, in order to provide evidence about the validity of the mapping process from the original paper contract.

The purpose of a last step for validation is twofold. On the one hand, it is required to ensure that all terms have been covered. On the other hand, it is required that each deontic expression is faithfully represented. For this task, a service deriving a synthetic narrative text from the MCO contract can be very useful. Figures 10 and 11 show diagrams of the MCO document in the various editing steps.

The signatories indicated above were not identified in the original available contract sample, although the placeholders were explicitly provided.

Table 4

Contract text derived by parsing the MCO contract

Once with the contract represented as a MCO RDF document, it is possible to parse the entities and generate natural text from it. Table 4 presents the text possibly derived by parsing the MCO contract entities, while Table 5 provides the RDF serialization of the same MCO contract.

Table 5

Turtle serialization for the created MCO contract

6. Developments

Fig. 12.

MCO Reference Software: form for Check-with activity with example of input and its result.

The reference software of an MPEG standard is an implementation which demonstrates the use of the standard. This section describes first some software modules that are now part of the MCO and CEL reference software (those modules are very much related since the Contract Expression Language was developed in parallel with MCO, as explained in Section 1). Then, a complete system for creation and management of MCO contracts (Rightsdraw) is also presented.

6.1. CEL and MCO reference software

This section describes the software developed for media contracts management, focusing on preservation of digital rights and intellectual property protection. First, it presents the modules specifically implemented for the creation, search and permission based authorization of MCO contracts. Then, it presents the modules developed for the identification, storage, validation, authorization, search and delivery of CEL (Contract Expression Language) contracts. Finally, the integration of MCO and CEL modules is presented taking advantage of the MCO-CEL converter, which justifies the use of CEL software in a MCO environment.

6.1.1. Native MCO software modules

The native MCO reference software modules have been implemented by RAI, and are derived from a version of the Rightsdraw software presented below in Section 6.2. The main module implements the basic CRUD (create, read, update, delete) functionalities. The user of the software can work through an editing interface in which the MCO document is presented by a diagram from which a number of HTML forms are served to the user for active interaction. Another module implements the “check with” and “search” functionalities described in the requirements document [28].

“Check-with” creates a query, in terms of target exploitation and compares it with the indexed Permissions returning the list of MCO documents having Permissions matching the target exploitation. The Permission does not need to be exactly the same, but must be compatible with the target one, i.e. it must have less or equal conditions, or conditions with wider boundaries, and same or more general permitted actions.

The example of contract presented in Figs 10 and 11 was created by using the editing modules of the MCO reference software. The same example is used here for describing the Check-with interface and presenting the result of its use. The application interface is shown in Fig. 12.

Fig. 13.

Diagram representing the target permission used in the Check-with example.

The query form is filled with values matching the conditions required in the contract example: the target “Means” is one out of the three options required in the FactUnion; the time of context of the exploitation falls in the contract license period, as well as the territory; the number of target runs is lower than the maximum allowed; the two other conditions as “FreeOfCharge” and “Language” match exactly, as well as the User, the IPEntity, and its digital item identifier. Figure 13 shows in more detail the diagram of the target permission used in this query example.

The MCO reference software uses OWL/XML serialization as default, however it can import and export from/to RDF/XML serialization as well. Moreover, it integrates the MCO-CEL converter module (see Section 6.1.3), allowing import of contracts expressed in CEL and export of MCO contracts as CEL documents.

6.1.2. CEL software modules

The CEL reference Java software modules include:

Contract Identification: allows a user to obtain a unique identifier for a contract.

Contract Storage: stores a contract expressed in MPEG-21 CEL format.

Contract Validation: validates syntactically an MPEG-21 CEL contract, determining if the contract is valid or not and the reasons why.

Contract Delivery: allows a service provider to deliver a contract to one user.

Contract Search: searches contracts according to a set of terms and conditions provided by a user. The search can be performed by matching the parameters Text in the contract, Contract Identifier, Party and IPEntity against the contract to which they apply. The input query format is defined in MPEG Query Format (ISO/IEC 15938-12) [22].

Contract Check-with: verifies if a requested action against a contract matches with its content. The result of the operation includes one of these values: (i) OK, if the action can be performed; (ii) USER_NOT_FOUND, if the service invoker is different from one of the contract parties; (iii) DEONTIC_EXPRESSION_NOT_FOUND, if a deontic expression is missing or incomplete; (iv) CONDITION_NOT_SATISFIED, if the deontic expression is present but there is at least one condition that is not satisfied or (v) UNKNOWN_ERROR, if any unknown error occurs.

The modules Contract Identification, Contract Storage, Contract Validation and Contract Delivery share a common structure, having a contract as input and a response to the corresponding operation, as shown in Fig. 14. The response indicates if the operation is successful or not.

Fig. 14.

Common structure for Contract Identification, Storage, Validation and Delivery CEL reference software modules.

The Contract Search module does not receive a contract as input, but a query expressed in MPEG Query Format. The result of the operation is the response to the query. The structure of the module is very similar to the one in Fig. 14 as it only receives an input and provides an output.

Finally, the Contract Check-with module has a slightly different structure, as shown in Fig. 15. In this case, the inputs are a contract, an authorization context, the action to be authorized and the content over which the action will be performed. The output of this module is the result of the contract based authorization.

Fig. 15.

Structure of Contract Check-with CEL reference software module.

6.1.3. MCO-CEL converter

As the work in MPEG-21 around CEL and MCO was carried out in the same time span and in a collaborative environment, both support the same contract elements and concepts. This entails the possibility to select between the two of them, depending on criteria related to the technical environment and context of use. Besides, it is possible to conceive services for conversion from CEL to MCO and vice-versa, on limited and tested scenarios.

Since not all the reference software modules have been implemented for both CEL and MCO in the same environment, the use of this module permits the conversion between the two expressions of the contract in order to apply the corresponding reference software module. For instance, if we want to perform the Contract Check-with operation over a contract expressed in MCO, we could first convert from MCO to CEL and then use the result of this operation as an input for the CEL’s Contract Check-with module. This way of working can be applied to all the reference software modules implemented for CEL and MCO when the input contract is not expressed in the supported language.

Figure 16 shows the structure of the software modules implemented for both conversions.

The conversion is performed differently in both directions. In the rest of the sub-section we briefly describe the workflow of CEL-MCO conversion and MCO-CEL conversion.

The CEL to MCO conversion involves the following steps:

A CEL contract is parsed from an input file.

CEL parties are parsed and converted into MCO ontology elements. The parsing is aware if the party is a Person or an Organization and creates the proper properties for the party.

Contract metadata is parsed. Contract identifier and parties’ references are considered.

The clauses’ metadata and its elements are parsed. Regarding the constraints, only fact intersections, unions and negations are considered in order to create the hierarchical constraint structure.

An MCO contract containing the contract elements is returned (namely, instances of the MCO ontology and their relations).

The MCO to CEL conversion is done in the following steps:

Fig. 16.

Structure of MCO-CEL converter reference software module.

Fig. 17.

Rightsdraw interface for editing rights on the basis of user defined patterns.

The RDF MCO contract is parsed and a memory model generated.

Contract identifier is set in the CEL contract.

MCO parties are converted to CEL format. The parsing is aware if the party is a Person or an Organization and creates the proper related class to the party.

The clauses are converted. The following clause elements are considered (i) Issuer; (ii) Object; (iii) Subject and (iv) Resultant Object. Constraints and acts are not considered

The XML CEL contract is generated from the memory model.

6.1.4. How to use MCO and CEL reference software together

The MCO and CEL reference software can be considered all together as a larger set of modules, using the MCO-CEL converter as pivot.

Assuming that a specific contract will be finalized either in CEL or in MCO, the conversion between the two formats can be helpful during the contract lifecycle, such as for editing or validation, or afterwards for Check-with operations or for delivery to systems operating in the other format. The MCO-CEL conversion is therefore a critical component, as it bridges simple XML applications with semantically enabled tools.

As a use case example, an operator who has just edited our contract example by using the MCO reference software editing modules is informed that the contract must also be delivered to a system expecting CEL documents. The form for exporting the document also accepts CEL as input, in addition to OWL serialization options.

The implementation of the converter module is limited to the main elements. The MCO party entities are mapped to CEL using the IRIs as IDs of the CEL party elements and the related Dublin Core annotation assertions are also found and mapped. The MCO Permission goes into the operativePart element of CEL, as a deonticStructuredClause element, having the ID derived from the Permission IRI, in which the two MCO triples (Action, actedBy, Organization) and (Action, actedOver, IPEntity) are mapped into CEL by means of the elements: subject, act, and object. The required facts are only partially supported by the converter.

6.2. Rightsdraw

Rightsdraw is a set of services for creating and handling MCO documents [35], developed in the framework of European funded project PrestoPRIME as a proof of concept rights management system [1].

Each user of the service can create and work on MCO documents stored on the repository. The editing activity can be done by means of forms. The Check-with service can be used for finding Permissions matching a target exploitation. It is also possible to update rights holding information, i.e. the set of Permissions which hold over a certain IP Entity, with the application of a new contract, implementing thus purchases and sales scenarios.

Rightsdraw also supports the definition and use of “key patterns”, which are templates of recurrent permissions, the use of which is partially shown in Fig. 17: the permission related to a content item is checked against the defined patterns, recognized by a simple title, without considering conditions specified by data properties. The user of the service can see those details for each permission, obtain a derived text, delete a permission, and add a new one based on the selected pattern. The patterns themselves can be edited using the diagram based interface.

7. Conclusions and future work

The MPEG Standard committee has been working on the specification of two ways of representing contracts, which have been finalized as two new parts of MPEG-21, namely CEL (ISO/IEC 21000-20) and MCO (ISO/IEC 21000-21). The paper describes the contract model and key elements in MCO, such as the parties in the contract and the relevant clauses conveying permissions, obligations and prohibitions.

Other initiatives have tried to represent contracts, as described in Section 2. However, MCO addresses the needs related to the deal of media rights, based on the legal framework on the protection of the intellectual properties and characterized by complex multi-dimensional conditions: to identify the main contract entities and have a machine-readable operative part to support the media industry operations. One example is that of rights clearance work, which is related to planning of production, broadcast events, and archive repurposing. Another case is that of purchase and sale of media rights.

Besides, other metadata standards and initiatives, such as MPEG-7 [26] or EBU-Core [11], are established regarding the media content description to support the content publication and content search and retrieval. Such formats have found big difficulties in covering rights aspects, because of the complexity of the rights domain, with its need to resolve the truth of any evaluation of rights, and typically these formats leave placeholders for undetermined rights statements or plain text (not machine readable). The MCO can cover this gap or missing link, in RDF, as the content description standards can point to the IRIs of media contracts or even to the deontic expressions related to their content of interest, while from the rights management environment the IP-Entities can have links to their descriptive information.

The other main contributions of the paper are related to the creation process of a contract (to be represented in MCO) and the tools needed to achieve that. The different examples provided, all of them verified and implemented, confirm the usefulness of MCO and how to use it.

The authors of this paper have been the main contributors to the specification of the standard and have developed the tools (and Reference Software) described. Future work on this topic includes improving the software tools by rationalizing the contract process creation. In fact, the MCO standard has already been corrected (a first “corrigendum” has been approved [36]) to fix some minor issues discovered during software development.

Another line for future research revolves around the ODRL (Open Digital Rights Language) that is a well-established standard for representing rights expressions, whose version 1.1 issued in 2002 [19] was based in XML. The ODRL 2.1 specification [20] defines a OWL ontology for its Core Model, much in line with the Media Contract Ontology, with the intention of representing the rights expressions also with RDF statements. The alignment of the MCO and the ODRL 2.1 Core Model ontologies looks as a logical next step towards gaining interoperability and better acceptance in the Linked Data community. Due to its inherent private character, contracts are unlikely to join the linked open data cloud, however they may well constitute internal enterprise linked data.

Footnotes

Acknowledgements

Part of this work has been funded by the Spanish Ministerio de Economía y Competitividad (4V: Volumen, Velocidad, Variedad y Validez en la gestión innovadora de datos, TIN2013-46238-C4-2-R) and Ministerio de Ciencia e Innovación (Protección Búsqueda e interoperabilidad de contenidos multimedia: Nuevas técnicas y aplicaciones, TEC2011-22989) and also by the European Commission (PrestoPRIME, FP7-ICT-2007-3 231161 and Presto4U, ICT-2011-4.3. 600845). The authors thank Annarita Di Carlo (RAI / Teche) for providing the contract example and verifying the mapping.

References

[1]

Boch and

Di Carlo, Proof of Concept Rights Management System, PrestoPRIME Deliverable D4.0.6, 2013, available at https://prestoprimews.ina.fr. Accessed Dec. 2015.

[2]

Boch,

Di Carlo and

Gallo, Model, format and services for audiovisual rights management, in: Proc. of the 1st Int. Conf. on Inf. Tech. for Performing Arts, Media Access and Entertainment, Firenze Univ. Press, 2012, pp. 89–94.

[3]

Casellas, Legal ontologies, in: Legal Ontology Engineering: Methodologies, Modelling Trends, and the Ontology of Professional Judicial Knowledge,

Casellas, ed., Law, Governance and Technology Series, Vol. 3, Springer, 2011, pp. 109–169.

[4]

Cevenini,

Contissa,

Laukyte,

Riveret and

Rubino, Development of the ALIS IP Ontology: Merging legal and technical perspectives, in: Federation for Information Processing, Vol. 277, Springer, 2008, pp. 169–180.

[5]

Corcho,

Fernández-López,

Gómez-Pérez and

López-Cima, Construcción de ontologías legales con la metodología METHONTOLOGY y la herramienta WebODE, in: Law and the Semantic Web. Legal Ontologies, Methodologies, Legal Information Retrieval, and Applications, Springer, 2005, pp. 142–157.

[6]

Daskalopulu,

Dimitrakos and

Maibaum, Evidence based electronic contract performance monitoring, The INFORMS J. of Group Decision and Negotiation (2002) 469–485, Special Issue on Formal Modeling in ECommerce, Kluwer Academic.

[7]

Delgado,

Gallego,

Llorente and

García, IPROnto: An ontology for digital rights management, in: Legal Knowledge and Information Systems,

Bourcier, ed., Frontiers in Artificial Intelligence and Applications, IOS Press, 2003, pp. 111–120.

[8]

Delgado,

Rodríguez,

Rodríguez-Doncel,

Baldinato and

Bixio, Use of MPEG-21 REL for the expression of Audiovisual Contracts, 2008, ISO/IECJTC1/SC29/WG11M15430.

[9]

Di Carlo, Common Rights Ontology, 2010, PrestoPRIME Deliverable ID4.0.5B, https://prestoprimews.ina.fr/public/deliverables/PP_WP4_ID4.0.5b_RightsOntology_R0_v1.11.pdf.

10.

[10]

Eastlake and

Reagle (eds), XML Encryption Syntax and Processing, W3C Recommendation, 4 March 2002.

11.

[11]EBU Tech 3293 version 1.6, EBU Core Metadata Set, 2015, available at https://tech.ebu.ch/publications/tech3293, accessed Dec. 2015.

12.

[12]

Fernández,

Gómez-Pérez and

Juristo, METHONTOLOGY: From ontological art towards ontological engineering, in: Proc. of the AAAI97 Spring Symposium Series on Ontological Engineering, Stanford, USA, 1997, pp. 33–40.

13.

[13]

Francesconi and

Tiscornia, Building semantic resources for legislative drafting: The DALOS project, in: Computable Models of the Law, Casanovas et al., eds, LNCS (LNAI), Vol. 4884, Springer, 2008, pp. 56–70.

14.

[14]

Gabbay,

Horty and

Parent, Handbook of Deontic Logic and Normative Systems, College Publications, 2013, ISBN 9781848901322.

15.

[15]

Giereth, On partial encryption of RDF-graphs, in: The Semantic Web-ISWC 2005, Springer, 2005, pp. 308–322.

16.

[16]

Governatori and

Milosevic, A formal analysis of a business contract language, Int. J. Cooperative Inf. Syst.15 (2008), 659–685. doi:10.1142/S0218843006001529.

17.

[17]

Guth and

Strembeck, A proposal for the evolution of the ODRL information model, in: Proc. of the International Workshop on the Open Digital Rights Language (ODRL), 2004, pp. 87–106.

18.

[18]

Hoekstra,

Breuker,

M.D.

Bello and

Boer, The LKIF core ontology of basic legal concepts, in: Proc. of the W. on Legal Ontologies and Artificial Intelligence Techniques,

Casanovas,

M.A.

Biasiotti,

Francesconi and

M.T.

Sagri, eds, 2007.

19.

[19]

Ianella (ed.), Open Digital Rights Language v.1.1, Technical Report, W3C, 2002, 19 September 2002.

20.

[20]R. Ianella, S. Guth and A. Kasten (eds), ODRL2.1 Core Model Specification, W3C Community Group Specification, 2015.

21.

[21]

Ianella and

McKinneym (eds), vCard Ontology, W3C Working Draft, 24 September 2013.

22.

[22]ISO/IEC IS 15938:12, Information technology – Multimedia content description interface – Part 12: Query format, 2008.

23.

[23]ISO/IEC 21000-21:2013, Information technology – Multimedia framework (MPEG-21) – Part 21: Media Contract Ontology, 2013.

24.

[24]ISO/IEC 21000-19:2010, Information technology – Multimedia framework (MPEG-21) – Part 19: Media Value Chain Ontology, 2010.

25.

[25]ISO/IEC 21000-20:2013, Information technology – Multimedia framework (MPEG-21) – Part 20: Contract Expression Language, 2013.

26.

[26]ISO/IEC 15938, Information technology – Multimedia content description interface.

27.

[27]ISO/IECJTC1/SC29/WG 11 Systems Group, N15194 Text of ISO/IEC CD, 2nd edn, 21000-21 Media Contract Ontology (MCO), 2015.

28.

[28]ISO/IECJTC1/SC29/WG11 Systems Group, N11228 – Requirements for Advanced IPTV Terminal (AIT), 2010.

29.

[29]ISO/IECJTC1/SC29/WG11 Systems Group, N11386 – Core Experiment for Contracts mapping, 2010.

30.

[30]

Kabilan and

Johannesson, Semantic representation of contract knowledge using Multi Tier Ontology, in: Proc. of SWDB’03, the First International Workshop on Semantic Web and Databases, Co-Located with VLDB 2003, Humboldt-Universität, Berlin, Germany, September 7–8,

I.F.

Cruz,

Kashyap,

Decker and

Eckstein, eds, 2003, pp. 395–414.

31.

[31]

Kobryn,

Atkinson and

Milosevic, Electronic contracting with COSMOS – how to establish, negotiate and execute electronic contracts on the Internet, in: Proc. of the 2nd Int. Enterprise Distributed Object Computing, IEEE, 1998, pp. 46–55. doi:10.1109/EDOC.1998.723241.

32.

[32]

Leff and

Meyer, eContracts. Version 1.0, Technical report, OASIS, 2007, http://docs.oasis-open.org/legalxml-econtracts.

33.

[33]

Prisacariu and

Schneider, A dynamic deontic logic for complex contracts, J. of Logic and Algebraic Programming81(4) (2012), 458–490, Elsevier.

34.

[34]

Raimond,

Scott,

Oliver,

Sinclair and

Smethurst, Use of Semantic Web technologies on the BBC web sites, in: Linking Enterprise Data,

Wood, ed., Springer US, 2010, pp. 263–283. doi:10.1007/978-1-4419-7665-9_13.

35.

[35]RightsDraw, Technical report, available at http://www.crit.rai.it/EN/attivita/opensource/Rightsdraw_en_2013.pdf, accessed Dec. 2015.

36.

[36]

Rodriguez,

Boch and

Delgado, Material for a first Corrigendum for ISO/IEC 21000-21, ISO/IEC/JTC1/SC29/WG11 M31429, 2013.

37.

[37]

Rodríguez,

Delgado,

Boch and

Rodríguez-Doncel, Media contract formalization using a standardized contract expression language, IEEE MultiMedia22 (2015), 64–74. doi:10.1109/MMUL.2014.

38.

[38]

Rodríguez,

Delgado and

Rodríguez, From narrative contracts to electronic licenses: A guided translation process for the case of audiovisual content management, in: Proc. of 3rd Int. Conf. on Automated Production of Cross Media Content for Multi-Channel Distribution, IEEE Computer Society, 2007, pp. 171–178.

39.

[39]

Rodríguez,

Suarez,

Gomez and

Poveda, License Linked Data resources pattern, in: Proc. of the 4th Int. Workshop on Ontology Patterns, Gangemi et al., eds, CEUR, Vol. 1188, 2013.

40.

[40]

Rubino,

Rotolo and

Sartor, An OWL ontology of fundamental legal concepts, in: JURIX,

T.M.

van Engers, ed., Frontiers in Artificial Intelligence and Applications, IOS Press, 2006, pp. 101–110.

41.

[41]

Sacco and

Passant, A Privacy Preference Ontology (PPO) for Linked Data, in: Proc. of the Linked Data on the Web, Bizer et al., eds, CEUR, Vol. 813, 2011.

42.

[42]

Sartor,

Casanovas,

Biasiotti and

Fernndez-Barrera, Approaches to Legal Ontologies: Theories, Domains, Methodologies, Springer, 2013. doi:10.1007/978-94-007-0120-5.

43.

[43]

Yan,

Zhang and

Yan, Ontology modeling for contract: Using OWL to express semantic relations, in: EDOC, IEEE Computer Society, 2006, pp. 409–412.

Overview of the MPEG-21 Media Contract Ontology

Abstract

Keywords

1. Introduction

1 See the Berne Convention for the Protection of Literary and Artistic Works (1886).

3. Related work

4. Media Contract Ontology

4.1. Overview

3 As MCO is OWL2, identifiers are IRIs instead of URIs (IRI – Internationalized Resource Identifier: a generalization of URI permitting use of Unicode characters), although the standard makes reference to both indistinctly.

6 The term “secondary-rights” is used by buyers (of rights) of some organizations (e.g. RAI) for cases in which an exploitation action (secondary) is only permitted when combined to another exploitation action (primary), that is permitted independently.

Table 2 Turtle serialization for Fig. 8

5.1. Guidance to MCO aspects

5.1.1. Textual contracts and MCO contracts

5.1.2. Referencing MPEG content

5.1.3. Encrypting the contract

5.1.4. Contract templates

5.2. Creation of MCO contracts from text documents

7 PrestoPRIME – Keeping Audiovisual Content Alive – Available at http://www.prestoprime.eu. Accessed Dec. 2015.

6.1.1. Native MCO software modules

6.2. Rightsdraw

7. Conclusions and future work

Footnotes

Acknowledgements

References

¹
See the Berne Convention for the Protection of Literary and Artistic Works (1886).

³
As MCO is OWL2, identifiers are IRIs instead of URIs (IRI – Internationalized Resource Identifier: a generalization of URI permitting use of Unicode characters), although the standard makes reference to both indistinctly.

⁶
The term “secondary-rights” is used by buyers (of rights) of some organizations (e.g. RAI) for cases in which an exploitation action (secondary) is only permitted when combined to another exploitation action (primary), that is permitted independently.

Table 2
Turtle serialization for Fig. 8

⁷
PrestoPRIME – Keeping Audiovisual Content Alive – Available at http://www.prestoprime.eu. Accessed Dec. 2015.