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.
Introduction
The international legal framework on the protection of intellectual property1
See the Berne Convention for the Protection of Literary and Artistic Works (1886).
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
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.
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.
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.
Media Contract Ontology
This section describes the Media Contract Ontology, which is defined by a core model (described in
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.
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.
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.
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
The general overview of the MCO Core model is shown in Fig. 1.
The Media Contract Ontology defines an
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.
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
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
Any contract, as an exchange of promises, contains a set of deontic expressions: permissions, prohibitions and obligations. The MVCO defined the
The permission model revolves around the concept of deontic expression (i.e. a permission, obligation or prohibition) which can be issued by a user (
Permission model in MCO.
If the deontic expression (
A contract, thus, is in essence a set of DeonticExpressions, which implement one or more natural language contract clauses (see Fig. 4).
Deontic expressions are issued in contracts and implement textual clauses.
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
The boolean operators (represented by the class
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).
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
Figure 6 shows all the instances along with the main class they belong to.
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.
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
Diagram of mvco:Action hierarchy for exploitation rights. As before, dashed arrows depict subclassing relationships.
RDF serialization for Fig. 6
The media contracts on content usually convey permissions to execute one of the generic actions found in
The extensión RELE proposed in [39] covers this aspect.
The MCO extension for exploitation of intellectual property rights does not define any new class without a superclass from
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
Some of the exploitation conditions are expected to be related to other class individuals:
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
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
A particular policy of user access (
Eventually, it is possible to require that the time left to the final user for content fruition is limited or unlimited (by the facts
The model also covers the possibility of defining conditions related to the technology used in the delivery to the final user (
The fact
Another condition that was required to be modelled is that of
Other exploitation conditions are self-explaining. The
Finally, the class
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.
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.
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.
Turtle serialization for Fig. 8
Turtle serialization for Fig. 8
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.
Guidance to MCO aspects
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.
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.
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
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
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.
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.
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
Presto4U – European Tech. for Digital Audiovisual Media Preservation. Available at
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.
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
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
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.
Diagram representing the initial steps of creating a MCO contract document.
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.
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.
Turtle serialization for the created MCO contract
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.
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.
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.
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.
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)
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.
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.
Structure of Contract Check-with CEL reference software module.
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:
Structure of MCO-CEL converter reference software module.
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.
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
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.
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.