[Paper Overview] [DRM-Workshop Homepage]
Norman Paskin
International DOI Foundation
(n.paskin@doi.org)
ref: 001219IDFDRMposition paper
The International DOI Foundation (IDF) created, and is further developing, the Digital Object Identifier System (DOI) as an interoperable identifier system for items of intellectual property ("Creations") in the digital environment. Such identification schemes are a prerequisite for automated rights management of intellectual property. This paper states some of the assumptions and conclusions from the DOI work relevant to digital rights management.
IDF uses the axioms of the indecs logical analysis of requirements for interoperable data in E-commerce and is developing DOI further in accordance with the indecs conclusions (principles):
DRM may imply "Digital Management of [all] Rights"; or "Management of Digital Rights". The former, wider, definition is preferable for a rights infrastructure scheme: practical rights management encompasses both digital and non-digital rights. Similarly, DOI = digital identifier of objects (creations), not simply identifier of digital objects. A rights infrastructure model should be an abstract model applicable to non-Web internet and non-internet settings as well as Web environments.
Transactions need automation. Automation requires disambiguity. Current (non or partly automated) systems can accommodate ambiguity which automated systems find difficult. (Example: the word "book" may designate an individual volume, an edition (ISBN), a work, etc. yet we use it easily and need not disambiguate usages which are "obviously" different: "Stephen King sold his latest book at Frankfurt Book Fair" versus "I bought this book at Frankfurt airport"). In attempting to remove ambiguity in systems we need to elucidate definitions, distinctions and relationships more precisely and in far more detail than has been the case until now: (1) this may not be easy; and (2) this can lead to the knowledge representation "trap" whereby constructing any extensible model of a transaction seems to require a complete model or ontology of the world, leading to prolonged design discussions at the expense of developing some workable framework for disambiguity which can be put into practical applications even if not complete. Meanings must be consistent in context, and contexts must be recognisable.In the example here, what is needed is not a single definition of "book" which can be correctly interpreted in each circumstance; but a specification by defined namespace such as "in the context of ISBN, book means..."; "in the context of bookshop SKU, book means..." etc.
Separate areas where data has been developed to suit one particular sector are now being required to inter-operate because of media convergence; e.g. consider the data needed to manage rights in an E-book containing text, a music clip, a video, and a link to a dynamically updated web site. Individual sectors must pay heed to interoperability concerns; they may fail to see why they should support initiatives which apparently offer their sector little advance on what they have; when they do see the need, they require these initiatives to deliver immediately. No single metadata data model will be accepted (or is appropriate) across all entities; each sector may have existing models. Some key principles are applicable (indecs) such as the requirement for structured ontologies (FRBR, ONIX, SMPTE, etc). The data model appropriate to one sector can then be mapped to another, with various degrees of difficulty; the existence of a common interoperable semantic framework (as proposed in indecs) will facilitate this.
The separation of "descriptive" and "rights" metadata cannot be sustained beyond simple applications. Any item of descriptive metadata could be a term used in a rights transaction; e.g. in the agreement "I sell you reproduction rights in all wildlife photographs taken by John in the last five years" the term "wildlife" is a descriptive categorisation (as is photograph, etc). An infrastucture for metadata about Creations is not separable from that for users and transactions.
Almost all terms used in a rights transaction (and hence in a rights infrastructure) need unique identifiers; in the example above the term "wildlife" requires a precise functional definition (not simply a dictionary definition) or, more pragmatically, the assignment of each relevant entity to such a classification. There is a need for a set of standardised comprehensive controlled vocabularies (on the same basis as ISO language, territory, currency and time codes), and hence registries for key descriptive terms such as contributor roles (author, composer, translater, remixer etc), derivation types, creation forms and measures. Unique identifiers should by preference be dumb or unintelligent identifiers, separate from but linked to metadata, rather than including intelligence and thereby "hardwiring" some metadata which cannot be changed. Identifiers should be persistent; persistence is ultimately a function of institutions but may be aided by technology.
Metadata related to an entity is potentially infinite; a metadata set "description" of an entity is a view, using some metadata for some purpose (e.g. consider the possible metadata associated with a person for various roles). Many different views of an entity are possible. Views must not be confused for digital content and rights management; mistaken identity can be catastrophic. Increasingly views need to be interoperable (e.g. production workflow, rights, marketing within one business; supply chain transfer; etc.); the need for automated interoperable views in digital commerce will be enormous. Some elements of metadata about an entity are likely to be useful in many views (applications) and may be usefully associated with the entity e.g. by linkage via an identifier assertion or service. In the DOI system we define this set as a "kernel" of metadata elements. A "view" is an application profile built on this kernel.
A Web-based rights infrastructure should allow separate or class identification, if necessary, of multiple copies at multiple locations (etc.). Trivially, at a sufficient level of abstraction all names (= identifiers) are addresses: a name is a location within a defined namespace. In practice the distinction between the name (identifier) of a digital object and two locations where it is available is a functional one; it is useful to be able to distinguish between two copies for some purposes; to be able to name all copies as a class for other purposes; and to use a persistent name when a location changes for good reason. Current usage of URLs does not allow sufficiently flexible designation of classes (e.g. multiple copies at different URLs). The current usage and definitions of UR*s within W3C - which the URI Activity is intended to address - fails to make this distinction sufficiently clear and appears to compound the potential for misunderstanding by simple re-labelling URLs as URIs. The issue is not one of semantics or URI design issues, but one of functional granularity of naming: "The same abstract forms may be represented or embodied in many different physical entities. Therefore, physical or digital objects of widely divergent natures could be characterized by the name of the same abstract form. The name of the book War and Peace, for example, could refer to an abstract form conceived by Tolstoy or to an embodiment of that form in a physical object made of paper and ink. When computers are used to represent such things, the number of entities, both physical and abstract, is multiplied....William of Ockham admonished philosophers to avoid multiplying entities, but computers multiply them faster than his razor can shave." [Sowa, ch.2]. It follows that no single URI can be sufficient to facilitate all possible rights transactions of an entity. A practical example is the identifier assigned to E-Books [see workshop position paper of Stephen P Mooney]: for some in the E-Book supply chain it is important to identify at the level of the class of all editions; for others, identification of an individual format is necessary and requires separate identifiers.. A single given entity may instantiate several identified entities (X may be an example of the abstraction War and Peace, of the Random House E-Book War and Peace, and of the Glassbook format of the Random House E- book War and Peace, etc.) Different players in the transaction chain require identification at various levels. Resolution and metadata mechanisms which can express class/member relationships will be useful. This issue appears to be a common stumbling block in discussions about URIs/URNs; disagreements may often be traced to different views about what is being identified. This is a particularly vulnerable area for DRM, as the rights in the various different related creations are often controlled by different people, and many works (such as a musical composition) are "abstractions" which cannot be referenced directly but only through related expressions or as metadata.
Total disintermediation will not succeed; there will always be new intermediary services, so identifiers and rights metadata must be usable in the distributed environment outside the environment of the assigner. Assignment of an identifier should be accompanied by a declaration of metadata sufficient to provide critical minimum metadata for basic recognition, in a form which can interoperate with other metadata. Identifiers are useful in a rights transaction (supply chain) context when they can be used all the way down the supply chain, not only by the assigner; this requires an identifier of an entity to be associated with consistent, extensible metadata schemes and elements which must be declared and readily available. Some tools are available for declaration of schemes (ISO11179); it is important to distinguish between publishing for human consumption and publishing for machine consumption.
The actions appropriate to services available on an entity for a given transaction will depend on the context (including rights context) of the user in relation to the entity and the transaction. (e.g: locating the "appropriate copy". Embodying this in net architecture is a concern recognised as "contextualisation". The current generalized architecture for resolution of identifiers such as URIs works well when a (software) client wants or needs to dynamically determine the explicit authoritative delegation of resolution. However, there are times when it is desirable to incorporate other elements of contextual control information in determining, for example, the "appropriate copy" of a resource - preferentially finding a "local" copy of a journal rather than (re)purchasing one from the authoritative publisher. This is generally applicable to all URI resolution, but it is more specific than "web caching". Software systems being built to solve this in today's deployed systems are using specialized, non-interoperable, non- scalable approaches. A recent IETF workshop reviewed interest in a standard vehicle to process contextualized resolution that is not application- or protocol-specific and ties in with global resolution systems in order to preserve authoritative resolution chains, where applicable. Beyond the "appropriate copy" scenario, this should equally be applicable in non-document contexts -- e.g. IP-telephony (enterprise dialing schemes taking precedence over, but linked to, global numbering).
Rights transactions are events. Rights agreements are events which sanction or prohibit other events A rights infrastructure model requires a metadata view which is centred on events; a move from a static view ("a creation") to a dynamic view ("A created B"). Static views may remain useful as a simplified view for some applications. "During the 1960s the need to treat events as first-class entities was independently re-discovered in linguistics, philosophy and artificial intelligence" (Sowa, chapter 4). This has been re-discovered in metadata work in rights e.g. in the Harmony project [see the preliminary "Strawman" document at http://www.ilrt.bris.ac.uk/discovery/harmony/docs/abc/abc_draft.html] and the indecs project.
Rights agreements exist in complex, multiple forms in which one agreement is commonly dependent upon another. Rights are commonly passed along "chains": for example, an author assigns certain rights to a publisher, who reassigns to a sub-publisher for a territory or purpose, who then licences certain activities which in turn may result in further exploitation. Many people commonly have interests in many rights in a single creation. This is not new, but its impact is much more obvious (eg Napster) in the global, persistent environment of the Web, where a copy of a creation exists and may be accessed indefinitely by anyone. Changes (such as a new owner) higher up the "chain" cause a "chain reaction" which affects the status of those further down the chain (and therefore the flow of rights or payments). An effective Web-based DRM infrastructure needs to be capable of supporting "automated chain reactions" which can pass on the impacts of such changes through the chain. Human-driven administration of such changes, as typically occurs in pre-digital rights management, is untenable in the Web environment.
Media convergence is mirrored in community convergence. A wide group of interests and backgrounds are colliding in this space. Explanations and proposals should recognise this and avoid unexplained jargon or assumptions of common tools which may not be readily understood outside one community. Formalisms will be essential for rigorous in-depth development but readily accessible explanations should be encouraged for wider readership and to encourage adoption.
The DRM infrastructure must be capable of supporting simple, user-friendly browser-based tools which can enable non-experts to declare their ownership of rights and the agreements and licences which they have sanctioned in appropriate standard forms. A DRM infrastructure cannot be dependent on centralised specialised services, although these will undoubtedly play a major role. This does not imply that the tools should be limited to those currently supported in browsers.
The workshop documentation names several W3C initiatives which are relevant. It would be a significant step forward to have a coherent architectural view which describes the semantic web activity; URI activity; RDF, etc using precise common terminology in an accessible manner.
W3C would be an inappropriate forum to carry out all the semantic analysis and development relevant to rights infrastructure. It should recognise that there are existing efforts underway. There is an explosion of metadata activity; all schemes likely to be of interest for a generic rights management infrastructure are: granular (capable of identifying parts, versions, etc); modular (support creations within creations); multimedia; multifunctional; multilingual; multipurpose. Among these are EPICS/ONIX; DOI; SMPTE; MPEG21.
The DOI is an integrated system made up of a number of interacting components that depend on one another for their value. The four components are:
A fundamental design principle is that each of these components is extensible: the enumeration syntax allows the maximum flexibility of assignment using newly created or existing identifier sequences; the descriptive metadata follows an extensible framework; the resolution system is part of a wider overall Digital Object Architecture scheme; and policies are designed to maximise interoperability and provide a basis for interaction with metadata in a rights infrastructure. The DOI system's development to date is in three parallel tracks:
DOI: International DOI Foundation web site [http://www.doi.org/]
Rust, Godfrey & Bide, Mark: The <indecs> metadata framework - Building Blocks: principles, model and data dictionary. June 2000 [http://www.indecs.org/project.htm#finalDocs]
Sowa, John F. Knowledge Representation: Logical, Philosophical and Computational Foundations Brooks/Cole, 2000 [http://www.bestweb.net/~sowa/krbook/]