The <indecs> metadata framework
Principles, model and data dictionary
June 2000
WP1a-006-2.0
Godfrey Rust, MUZE Inc
Mark Bide, EDItEUR
Metadata framework: principles, model and basic dictionary
Contents
1 Introduction
page 4
1.1 A model of commerce
1.2 Axiom 1: Metadata is critical
1.3 Axiom 2: Stuff is complex
1.4 Axiom 3: Metadata is modular
1.5 Axiom 4: Transactions need automation
1.6 Interoperability
1.7 Types of interoperability
1.8 The limits of technology
1.9 Intellectual property metadata
1.10 Characteristics of the <indecs> framework
1.11 Directory of Parties: outline specification
2 Principles
page 8
2.1 The principle of Unique Identification
2.2 The principle of Functional Granularity
2.3 The principle of Designated Authority
2.4 The principle of Appropriate Access
2.5 A Definition of Metadata
3 Semantics
page 11
3.1 Basic terms
3.2 Metadata elements
3.3 <indecs> element identifier (iid)
3.4 Element roles
4 Entities
page 12
4.1 Different views, common structure
4.2 The general view
4.3 The commerce view
4.4 The intellectual property (legal) view
4.5 One model, three views
5 Attributes
page 16
5.1 Generic attributes
5.2 Characteristics of generic attributes
6 Relations
page 18
6.1 Relation types
6.2 Relation structure
6.3 Roles
6.4 Events
6.5 Situations
7 Parties
page 25
8 Creations
page 25
8.1 A model of making
8.2 Creation types
8.3 Creation identifiers
8.4 Creation qualities
8.5 Creation-to-creation relation roles
9 Intellectual Property
page 30
10 IPR Transactions
page 30
10.1 Overview
10.2 Integrating rights and commerce metadata
WP1a-006-2.0
2
June 2000
Metadata framework: principles, model and basic dictionary
10.3 iprStatements
10.4 Agreements
10.5 Offers
11 Assertions
page 35
12 Non-textual metadata
page 36
13 Transformations
page 36
14 Framework Metadata Dictionary
page 36
14.1 Element names
14.2 Element definitions
14.3 Genealogy and syntax
14.4 Complex element iids
14.5 Dictionary
Acknowledgments
This model represents the synthesis of ideas and material from many sources over a number of
years, so it is not possible to give credit to everyone who has made contributions, direct or
indirect. During the project period (November 1998-March 2000) we especially acknowledge
those of David Bearman, Dan Brickley, Eliot Christian, Tom Delsey, Beth Dulabahn, Brian
Green, Jane Hunter, Carl Lagoze, David Martin, Paul Miller, Benoît Müller, Sally Morris,
Norman Paskin and Bill Schmitt to the ideas and material contained here.
Title
Identifier
Description
Author, Organisation
Copyright Owner
Origination Date
Format
Completion
Confidentiality
Related Documents
Dissemination
©
WP1a-006-2.0
<indecs> metadata framework: principles, model and dictionary
<indecs> WP1a-006-2.0
Summary of key elements of <indecs> framework
Godfrey Rust, MUZE Inc; Mark Bide, EDItEUR
© Indecs Framework Ltd
26.2.2000
.doc
Final
Open
Re-titled revision of WP1a-006-1.0, “INDECS metadata schema: building blocks”
Open
Not to be reproduced in any form without permission
3
June 2000
Metadata framework: principles, model and basic dictionary
1
Introduction
This document summarises the technical work of the <indecs> project. It describes the
<indecs> metadata framework, a reference model
It is compiled in part from material from the original <indecs> metadata model description
(WP2a-004-3.1). This document supersedes all earlier published versions of the model.
The <indecs> project, and its successor the not-for-profit Indecs Framework Ltd, was created
to address the need, in the digital environment, to put different creation identifiers and their
supporting metadata into a framework where they could operate side by side, especially to
support the management of intellectual property rights. The background and objectives of the
1
<indecs> project are documented elsewhere , but to put this document in context this
introduction deals with the question of interoperability: what does interoperabilityt mean in
practice?
1.1
A model of commerce
People make stuff. People use stuff. People do deals about stuff.
The stuff and the deals may come in any order, but neither come before the people.
This is the basic model of commerce that underlies the <indecs> framework and models.
While the approach described here may be usefully applied in many domains, the main focus
of <indecs> is on the use of what is commonly (if imprecisely) called content or intellectual
property.
The model applies in many contexts, but is particularly useful in the digital and Internet
environments where the problems of metadata interoperability are becoming especially acute.
Commerce is used here in its broadest sense, not necessarily having financial gain as its
object. The model applies equally to cultural transactions in places such as libraries in which
people “make deals” that enable others to have free access to “stuff”.
The <indecs> schema rests on certain fundamentals, or axioms, about electronic commerce.
1.2
Axiom 1: Metadata is critical
“Metadata is the lifeblood of e-commerce” (a phrase coined by John Erickson, then of Yankee
Book Peddler). Electronic trading depends to a far greater extent than traditional commerce on
the way in which things are identified (whether they are people, stuff or deals) and the terms
in which they are described (metadata, or data about data).
E-commerce requires the linking of identifiers that connect people with goods and services:
stuff. In dealing with intellectual property these identifiers form complex and dynamic chains.
All kinds of metadata elements find their way into them. Where there is a gap or an ambiguity
in these elements, it is likely that the chains will be broken, or misrouted, and the required
transaction will not happen, or will have the wrong results. As e-commerce grows, reliance on
metadata chains grows with it.
1.3
Axiom 2: Stuff is complex
The second axiom on which <indecs> rests is that, when dealing with intellectual property,
stuff is complex. The generic <indecs> term for a piece of stuff which may carry intellectual
property rights is a creation. While an apple bought at a market stall is a single physical entity
owned entirely by one person, a single digital audiovisual creation may contain hundreds or
even thousands of separate pieces of intellectual property. These may include moving
pictures, recorded audio, still photographs, graphics, text and software applications, some only
in part or in modified form. Each of these separate manifestations of intellectual property may
have rights.
WP1a-006-2.0
4
June 2000
Metadata framework: principles, model and basic dictionary
These manifestations are normally expressions of abstract works or abstractions in which
there may be further rights; and those expressions may come into being be through the
medium of statio-temporal performances in which yet further rights may exist. All of these
rights may be owned or controlled by different people for different places and different
periods of time. The trading of one digital creation may involve rights transactions affecting
thousands of people and companies, from whom permissions may be required and to whom
payment may be due.
To take an example from music, an audio CD "greatest hits" compilation containing twenty
tracks is in fact a manifestation, owned (say) by a record company. It contains twenty sound
recordings, each of which embodies an expression or performance perhaps owned by different
record companies or artists and in which, in some territories, each contributing performer has
certain rights. Each performance in turn expresses one or more songs (abstractions) in which
the composer(s) and publisher(s) have rights. Through deals that have been made, various
payments are required whenever the CD is bought or used. These deals (agreements) may be
brokered individually or by collective licensing arrangements.
While this example is taken for music, similar kinds of complex relationship can be found in
any other creation type. From type to type, the importance and quantity of different elements
may vary (for example, in text-based creations the performance element is often unimportant)
but the functional requirements are the same, in structure if not scale.
1.4
Axiom 3: Metadata is modular
Because stuff is complex, metadata is modular. e-commerce metadata is made up of
connecting pieces created by different people.
Each of the basic entities (parties, creations, transactions) must have its own metadata set if
stuff is to be found and used, and rights are to be protected and rewarded. If the rights in a
complex creation come from many different people, so inevitably must the metadata.
Constraints of cost, time and knowledge ensure that the multimedia producer is dependent on
his suppliers of content also to provide the metadata on which future management depends.
The same dependency is increasingly true for others in the chain, including non-profit-driven
organisations such as libraries and academic institutions.
Metadata in the digital environment can therefore be viewed as a set of "modules", produced
in different places and for different purposes, which must link together easily into complex
forms to create new metadata modules for different stuff, people and deals. The result can be
described as the metadata network, or in a narrower context, the semantic web.
1.5
Axiom 4: Transactions need automation
In an increasing range of cases, transactions need to be highly or completely automated. In
physical commerce, much metadata complexity has been dealt with (if at all) in administrative
systems within bounded organizations such as publishers or collecting societies, each
operating their own local data standards and systems. The scale and nature of e-commerce has
made it imperative that these local standards and systems can interoperate in automated ways
with others.
For example, in the non-digital environment, securing copyright "permissions" is a
complicated, time-consuming and often unsatisfactory process. Owners and publishers are
already often unable to cope with the volume of low-value permissions requests made in
conventional ways.
In the digital environment the volume and nature of such uses is increasing exponentially.
Because stuff is complex and technology is ingenious and the virtual world does not recognise
national boundaries, the number of creations, agreements and potential rights holders and
users multiplies rapidly and continually. Without automation, all but the most valuable
permissions will become impossible to administer.
WP1a-006-2.0
5
June 2000
Metadata framework: principles, model and basic dictionary
1.6
Interoperability
In the <indecs> framework, interoperability means enabling information that originates in one
context to be used in another in ways that are as highly automated as possible. Commerce
does not necessarily mean the exchange of money: any environment where creations are made
or used employing electronic means is encompassed by commerce in this sense.
The information that needs to interoperate here is metadata: data of all kinds relating to
creations, the parties who make and use them, and the transactions which support such use.
The problems to be overcome are often as simple as the fact that a term such as “publisher”
has a quite different meaning in two different environments which now need to exchange
metadata; they are also as complex as the fact that a single creation may contain a hundred
distinct pieces of intellectual property, the rights of which are owned or controlled by many
different people for different purposes, places and times. In the persistent environment of the
Web, changes in the status or control of these rights, recorded in different and unconnected
systems will need to be capable of being communicated automatically in many different ways.
1.7
Types of interoperability
Interoperability in e-commerce has many different dimensions. As traditional sectors and
business models break down, organisations increasingly face the need to combine or access
information that arrives in a variety of forms and that comes from a variety of sources. The
creator of metadata about a piece of intellectual property will want to be sure that the accuracy
and effectiveness of the information he creates (often at substantial cost) can survive intact as
it negotiates a range of barriers. A serious approach to the problem needs to support
interoperability of at least six different types:
•
Across media (such as books, serials, audio, audiovisual, software, abstract works,
visual material).
•
Across functions (such as cataloguing, discovery, workflow and rights management).
•
Across levels of metadata (from simple to complex).
•
Across linguistic and semantic barriers.
•
Across territorial barriers
•
Across technology platforms.
A good e-commerce metadata system therefore needs to be multimedia, multi-functional,
multi-level, multilingual, multinational and multi-platform. Such an approach may be said to
be well-formed.
The failure of interoperability in each of these dimensions can be seen as trade barriers to ecommerce interoperability. These barriers are not all yet generally critical, only because the
volume of e-commerce traffic in intellectual property is relatively modest: yet we are now
seeing an unprecedented explosion in the development of IP-based metadata schemas. Listed
alphabetically below are just some of the major initiatives where substantial metadata
vocabularies, models, databases and/or interchange formats are currently being developed or
deployed, showing the communities in which they currently operate or from which they were
originated:
abc2
CIDOC3
CIS4
DCMS5
Dublin Core6
EPICS/ONIX7
IFLA FRBR8
WP1a-006-2.0
(museums and archives)
(copyright societies)
(recording industry)
(library originated)
(book industry)
(libraries)
6
June 2000
Metadata framework: principles, model and basic dictionary
IMS9
International DOI Foundation10
IEEE LOM11
MPEG712
MPEG2113
P/META14
SMPTE15
(education)
(book/journal industry originated)
(education)
(audiovisual originated)
(audiovisual originated)
(audiovisual)
(audiovisual)
This is by no means a complete list, although it represents the most of main initiatives with
which <indecs> has communicated to date. These schemes, developing from different starting
points, are all converging on the “barriers” we have identified. To some degree, each is
finding that is has to become multi-media, multi-function, multi-level, multi-lingual and
technology neutral. As convergence renders the traditional sector divisions increasingly
meaningless, they will inevitably need to interoperate with one another substantially. In
future, essentially the same metadata about, for example, a web document, may need to be
handled within each of these schemes, and many more.
1.8
The limits of technology
Web-driven tools such as XML (the Extensible Mark-Up Language) and RDF (the Resource
Description Framework), and their derivatives and successors, will provide part of the
solution: but they only go so far. They do not deal with the underlying issue of semantic
identity. Ultimately it is only the deployment of unique identifiers across a wide range of
critical pieces of metadata – well beyond what is currently practised – which will allow trade
barriers to be surmounted without an uneconomic level of human intervention and
interpretation.
Such unique identification systems are more or less implicit in the schemes listed above: but
as things stand today these systems risk, unintentionally, finding themselves in competition to
no good purpose. The <indecs> framework is being developed to provide a reference model
for system implementers to avert a costly clash of standards and to provide an underlying
infrastructure for semantic interoperability between them. To be successful, the cost of
compliance with this infrastructure must be low, its implementation relatively straightforward
and it must facilitate, not obstruct, the development of local systems or schemas like those
listed above.
Such an infrastructure will depend on semantic mapping through metadata registries. The
development of such tools lies beyond the scope of the project and, at the time of writing, is in
its very early stages. However, the implication of the <indecs> analysis is that powerful tools
and systems for mapping and transforming metadata across the barriers described above will
provide the necessary technical key to interoperability.
The project also has also recognised that “make once, use many times” metadata is the only
viable economic model for the future As far as possible such metadata needs to be an
automatic by-product of other processes.
1.9
Intellectual property metadata
The focus of <indecs> is intellectual property: “rights management”. However, this is not a
domain separate from other metadata. While there are particular legal aspects involved in the
establishment and use of rights, these are intimately connected with the everyday activities of
the making and use of creations. A well-formed system must provide means for the
interoperation of for this metadata, if it is to enable automated rights management.
Intellectual property issues are wholly pervasive in e-commerce: every transaction that
involves the use of a digital creation at any point in the “supply chain” is, in some sense, a
rights transaction, even where no money changes hand. Rights management is as important
WP1a-006-2.0
7
June 2000
Metadata framework: principles, model and basic dictionary
for the protection of the freedom of legitimate “fair use” by libraries as it is for the protection
of rights owners.
The <indecs> framework is neutral on the merits of any given right or practice. It is concerned
only with the mechanism for describing the transactions that take place.
1.10
Characteristics of the <indecs> framework
The framework recognises:
•
metadata relating to any types of creation;
•
the integration of descriptive metadata with commercial transactions and rights;
•
that metadata should be created once, used many times for different purposes;
and proposes:
•
a generic attribute structure for all entities;
•
events as the key to complex metadata relationships;
•
a metadata dictionary for multimedia intellectual property commerce;
•
unique identifiers (iids) to be assigned to all metadata elements;
•
the need for transformation processes to express the same metadata at different levels
of complexity for different requirements.
At the heart of the model lies the assumption that it is indeed possible to produce generic
systems to handle complex metadata for all different creation types. So, for example, instead
of treating sound carriers, books, videos and photographs as fundamentally different things
with different, albeit similar, characteristics, all are recognised as creations requiring for their
description different values of identical higher-level attributes, whose metadata can therefore
be supported in a common environment.
The <indecs> framework is designed to help bridge the gap between the powerful but highly
abstract technical models such as that expressed in the Resource Description Framework
(RDF) and the more specific data models that are explicit or implicit in sector- or identifierbased metadata schemes.
1.11
The Directory of Parties: outline specification
This <indecs> proposal for the interoperability of party identifiers, developed in parallel with
the metadata schema, is not included here but is available from the <indecs> website16
2
Principles
The <indecs> framework recognises four guiding principles for the development of “wellformed” metadata to support effective e-commerce. In practice, it is rare that any of these is
fully realised; but the extent to which they are realised largely determines the ultimate
usefulness and resilience of any given metadata schema in terms of its effective
interoperability with other domains.
The principles relate to the origination of well-formed metadata, not to the means by which
different metadata may be integrated (what might be called the point of interoperability).
Metadata that does not conform to these four principles will be found to be in some way
deficient when it arrives at the point of interoperability (say, a central repository, or a third
party system).
Previous versions of this document have recognized a fifth principle, the principle of
application independence: “metadata structures should be independent of any specific
technical expression”. While still endorsing the general notion that metadata systems whose
WP1a-006-2.0
8
June 2000
Metadata framework: principles, model and basic dictionary
development is shaped by technical rather than semantic constraints will be less than optimal,
the framework now recognizes that technological differences must be resolved at the point of
interoperability, since they cannot be wholly anticipated at source.
2.1
The principle of Unique Identification
Every entity should be uniquely identified within an identified namespace.
It is difficult to overstate the importance of this simple and commonplace principle. At one
level it can be said that the basis of interoperable metadata is simply about the relationships of
recognisably unique identifiers. In pre-digital bibliographic and commerce systems,
effectiveness depends to a great extent on the robustness of their identification systems: the
UPC/EAN product numbers, the ISBN book identifier and the CAE
composer/author/publisher identifier are among the most successful identification systems in
use in the world of content management; they form the backbone of highly effective
distribution systems in their respective industries.
In contrast, where unique identifiers for major entities do not exist or are poorly implemented
within a domain, data management costs are higher – and simple, effective management
systems difficult to develop. The absence of unique “party” identifiers for creators and
publishers in the major content industries, the scarcely visible implementation of the ISRC for
sound recordings, and the lack of a standard agreement or licence identifier in any copyright
community, are each examples of gaps that are crippling for interoperability within a domain,
let alone between traditional domains.
Multi-media, multi-lingual, multi-national, multi-purpose metadata also requires that unique
identification applies at all levels, including the use of “controlled vocabularies” for values of
properties such as measures, form and type. In truly well-formed metadata, the only “free
text” properties of an entity are found in its names or titles; in some instances (for example, in
trademarks and in Actors Equity), even names may be protected to ensure their uniqueness in
a given domain.
Some issues that were once central to debates on identifiers have become much less important
in the electronic domain: in particular the question of intelligence, and of multiple identifiers
for the same entity.
Intelligent identifiers (that is, identifiers which carry some information in their structure
relating to the entity they identify, such as a format, date or producer code) are of some value
in particular circumstances, but problems of ambiguity or volatility often render much of this
apparent “intelligence” unreliable.
It is also less important that an entity may have more than one unique identifier, even in the
same domain. On the contrary, as entities like multimedia become more complex, or parties
such as publishers operate in multi-media, multi-national environments, it becomes inevitable
that they will acquire more and more domain identifiers, which may or may not require
reconciliation. The question of whether – or how – different identifiers for the same entity
should be reconciled is both practical and political; it is well beyond the scope of this
document.
The development of domains or namespaces within the Internet has helped in the relaxation of
pressure on the need for absolute uniqueness in the structure an identifier. URLs or URIs
provide mechanisms for universal disambiguation that allow even common terms to assume
unique, global status.
For wider interoperability, the most important properties of an identifier are (1) uniqueness
within a given domain; (2) stability (identifiers should never be changed or transferred); (3)
security, whether through protection by watermarking or encryption, and/or by internal
consistency through the use of check digit algorithms; and (4) the public availability of some
basic descriptive metadata for the entity identified, without which the identifier has only
limited use.
WP1a-006-2.0
9
June 2000
Metadata framework: principles, model and basic dictionary
2.2
The principle of Functional Granularity
It should be possible to identify an entity whenever it needs to be distinguished.
When should an identifier be issued? In this deceptively simple question lies the most basic
question of metadata: for which data is it meta-?
Resources – stuff - can be viewed in an infinite number of complex ways. Taking this
document as an example, it has an identifier in the <indecs> domain: WP1a-006-2.0. But to
what does this refer? Does it refer to the original Word document, or to a pdf version available
on the Website? Or does it refer to the underlying “abstract” content irrespective of delivery
format?
If it refers to the Web document, is this also adequate as a reference to local copies that have
been downloaded onto other computers or servers?
The document’s parts may require identification at any level (for example, this section 2.2, or
Diagram 14). If you wish to make a precise reference to this sentence from another document,
you will need a more precise locator, and its nature will depend on whether your reference is
intended to allow automated linking.
As this document has been through many stages of preparation, how many different versions
need to be separately recorded?
Each of these requires the exercise of functional granularity: the provision of a way (or ways)
of identifying parts and versions whenever the practical need arises.
The application of functional granularity depends on a huge range of factors, including the
type of resource, its location in time and place, its precise composition and condition, the uses
to which it is or may be put, its volatility, its process of creation, and the identity of the party
identifying it.
The implication of this is that a resource may have any number of identifiers
The same entity may be subjected to functional granularity across a range of views. The basic
“elements” of a resource may be entirely different according to your purpose. Stuff may be
analysed, for example, in terms of molecular entities (chemistry), particles such as electrons,
quarks or superstrings (physics), spatial co-ordinates (geography), biological functions
(biology, medicine), genres of expression (creations), price categories (commerce), and so on.
In the digital environment, stuff can be relatively easily managed at extreme levels of
granularity as minute as a single bit.
Each of these process will apply identifiers of different types at different levels of (functional)
granularity in different “dimensions”; these may need to be reconciled to one another at a
point of higher granularity.
Functional granularity does not propose that every possible part and version is identified: only
that the means exists to identify any possible part or version when the occasion arises.
2.3
The principle of Designated Authority
The author of an item of metadata should be securely identified.
“Who says?” is a big question in metadata interoperability. The quality or trustworthiness of
the metadata statements on which we increasingly rely (“this person is the translator”, “this
CD costs $20”, “this company is the owner of this right”, “this is a good product”) becomes a
profound question when metadata is modular and transactions need automation. Well-formed
metadata must provide mechanisms for declaring the authorship and for authenticating claims
of veracity in any item of metadata.
2.4
The principle of Appropriate Access
Everyone requires access to the metadata on which they depend, and privacy and
confidentiality for their own metadata from those who are not dependent on it.
WP1a-006-2.0
10
June 2000
Metadata framework: principles, model and basic dictionary
In a distributed environment, metadata has to be accessible where it is needed. At first sight
this is an unremarkable notion. However, the availability of metadata poses very similar
problems of security and standards to those posed by the availability of primary data. In order
to secure control of rights in a distributed environment, it is necessary to disclose, and to some
extent to distribute, information about the identity of rights owners and the nature and scope
of the rights that they control. This raises commercial, legal and political issues which are
likely to become increasingly complex and significant. The <indecs> framework is neutral on
the specifics of these issues: but the ability to express metadata in standardised forms is a
prerequisite for any level of appropriate access.
2.5
A definition of metadata
An item of metadata is a relationship that someone claims to exist between two entities.
In the process of developing the <indecs> metadata model, we have developed this general
definition of metadata that we believe is helpful in separating “metadata” from “data”.
This provides a concise paraphrase of much of the <indecs> framework. It stresses the
significance of relationships, which lie at the heart of the <indecs> analysis. It underlines the
importance of unique identification of all entities (since otherwise expressing relationships
between them is of little practical utility). Finally, it raises the question of authority: the
identification of the person making the claim is as significant as the identification of any other
entity.
3
Semantics
3.1
Basic terms
The <indecs> model elaborates a logical and semantic framework for describing entities, their
attributes and, where appropriate, values of each. Entities, attributes and values are referred to
as types of metadata elements.
Basic terminology is adapted in part from the vocabulary of information systems as defined in
ISO 11179, in part from terminology more familiar to users of XML (Extensible Markup
Language) and the RDF (Resource Description Framework)
Numbers in superscript (for example, entity1) refer to <indecs> element identifiers (iids) (see
3.3) whose definitions are found in the Framework Metadata Dictionary.
Defined terms are presented using the XML/RDF convention of lower case (eg creation) with
terms of two or more words presented as a single string with intermittent capitals (eg
sourceCreation).
The syntax used for the genealogy, the relationship of terms to one another, that is shown in
all the tables is explained in dictionary syntax (14.4).
Where the term “(derived)” appears in a definition this means that the definition has been
created by combining definitions from constituent terms in the element’s genealogy, and does
not add any new primary semantic material to the dictionary. For example, in table 4.2 the
definition of “percept” (“An entity which is perceived directly with at least one of the five
senses”) is made up from the terms and definitions of terms in its genealogy
(“perceived_entity”).
Table 3.1 Basic <indecs> metadata terminology
iid
element
element
entity
WP1a-006-2.0
1
491
definition
genealogy
An item of metadata (aka metadataElement) (see 3.2)
entity/
Something which is identified
concept/
11
June 2000
Metadata framework: principles, model and basic dictionary
attribute
value
9
10
227
iid
3.2
A characteristic of an entity (adapted from ISO 11179);
something which an entity has (aka property) (see 5)
relation/
An instance of an attribute (from ISO 11179-3)
concept/
A unique identifier allocated to an element of metadata
within the <indecs> framework (aka Indecs-id) (see 3.3)
identifier/
Metadata elements
Each element identified in the framework is listed in the Framework Metadata Dictionary (see
14) with an English language name, a description in the form of one or more compatible
definitions, and a numeric <indecs> element identifier (called an indecs-id or iid).
3.3
<indecs> element identifier (iid)
Within the framework all data elements are assigned a unique “dumb” numeric identifier An
iid may be considered as a logically equivalent and interchangeable synonym for an element
name: for example, event and iid=7 denote the same entity. Not all elements identified in the
<indecs> project work have been included in the published Framework Metadata Dictionary,
so iids referred to in this document do not form a continuous numeric sequence.
3.4
Element roles
A single element of metadata can play different metadata roles according to its context. Most
elements can function as attributes, types or values, or as entities which in turn have their own
attributes and types. For example, the element name may be an attribute of an entity person or
a type of the attribute label or it may be an entity in its own right with attributes such as type,
form or language.
4
Entities
Data models normally recognise entities which have various attributes, or properties, which
characterise them. In the <indecs> framework an entity is something which is identified. This
is more specific than the idea behind the word thing in the Oxford English Dictionary
definition of “a material or non-material entity, idea, action etc. that is or may be thought
about or perceived”, for it requires that a thing must be both thought about or perceived and
identified before it exists in a metadata framework. This is more like the term resource in the
sense adopted by the World Wide Web Consortium. The underlying idea – that nothing exists
in any useful sense until it is identified – combines the first two principles of unique
identification and functional granularity.
4.1
Different views, common structure
The fifth axiom (“everything is a view”) means that there are many different ways of
identifying and describing any entity. This of course creates serious complications for
interoperability. At the same time, it is possible to find common approaches that will allow
quite different things to be described in similar terms.
<indecs> takes into account three distinct but overlapping views of entities – a general view,
and within that a specific commerce view and an intellectual property view. These three views
enable us to describe the main metadata concerns in relation to e-commerce. A fourth, very
specific view, is then recognised in the generic attribute structure (see 5), which applies to
any entity seen in any view.
4.2
The general view
This view, which will make sense to most people most of the time, divides entities into three
basic types: those which are perceived with the senses (percepts), those which are conceived
in the mind (concepts), and those in which two or more of these are connected (relations).
WP1a-006-2.0
12
June 2000
Metadata framework: principles, model and basic dictionary
Taking one further step, we can recognise percepts as either animate (beings) or inanimate
(things), and relations as being dynamic (events) or static (situations) (Diagram 1 and Table
4.2):
general view
Metadata Schema Diagram 1
Diagram 1
entity
entity
something identified
percept
percept
relation
relation
something perceived through the senses
being
being
an animate percept
thing
thing
an inanimate percept
a link between two or more entities
event
event
situation
situation
concept
concept
a dynamic relation
a static relation
something conceived in the mind
Version 5.0 ©<indecs>June 2000
Table 4.2 General view, primitive entities
iid
definition
genealogy
Something which is identified
concept/
An entity which is perceived directly with at least one of
the five senses (derived);
perceived_entity
5
An entity which has the characteristics of animate life
(derived); anything which lives and dies
animate_percept
6
An entity without the characteristics of animate life
(derived)
inanimate_percept
The interaction of percepts and/or concepts; a connection
between two or more entities
entity/
A dynamic relation involving two or more entities
(derived); something that happens; a relation through which
an attribute of an entity is changed, added or removed
dynamic_relation
A static relation involving two or more entities (derived);
something that continues to be the case; a relation in which
the attributes of entities remain unchanged
static_relation
An entity which cannot be perceived directly through the
mode of one of the five senses (derived); an abstract entity,
a notion or idea; an abstract noun; an unobservable
proposition which exists independently of time and space
conceived_entity
element
entity
1
percept
being
thing
2
4
relation
event
7
8
situation
concept
3
In this view, one type of entity – the event – plays a special role. The event is the "glue" of the
model: all metadata relationships are either events in themselves, or rely on events to establish
them. This analysis underpins the <indecs> framework, which recognises that mechanisms to
WP1a-006-2.0
13
June 2000
Metadata framework: principles, model and basic dictionary
transform metadata into representations of events appears to provide the most powerful
approach to extensive interoperability (see 6, Relations).
4.3
The commerce view
The second view relates to what is often called descriptive metadata and is generally
concerned with how things are made. In this view people make stuff and people use stuff.
People also frequently make stuff out of other stuff: they are both users and creators at the
same time. Alongside this, people do deals about stuff which allow their stuff to be used by
others (Diagram 2):
commerce view
Metadata Schema Diagram 2
make
make
people
people
stuff
stuff
used
usedby
by
do
do
about
about
deals
deals
Version 5.0 ©<indecs> June 2000
The cycle of making and using can go round and round indefinitely, new stuff being
constantly made out of old, although ultimately there will be “end users” who simply perceive
or “enjoy” a creation with one or more of their senses.
In the framework this gives rise to three basic types of commerce entity (Diagram 3 and Table
4.3):
Table 4.3 Commerce entities
iid
element
party
68
94
creation
22
transaction
WP1a-006-2.0
definition
genealogy
An agent undertaking an activity or task in a creative or
commercial event
agent/
The output of creative activity (see 7)
created_entity
An event determining or recording the use or possible use of
an entity (see 8)
event/
14
June 2000
Metadata framework: principles, model and basic dictionary
commerce view
Metadata Schema Diagram 3
make
make
parties
parties
creations
creations
used
usedby
by
do
do
about
about
transactions
transactions
Version 5.0 ©<indecs> June 2000
Commerce in intellectual property is related to the exercise of rights, and this introduces the
third and last view:
4.4
The intellectual property (legal) view
In the final view, people (or legal persons) make and use intellectual property (IP) in which
rights are owned (Diagram 4 and Table 4.4). These entities and their subtypes are defined in
legal terms (see 9).
Table 4.4 IP legal concepts
iid
element
definition
genealogy
intellectual
204
Property
An entity defined by law or international convention to be
intellectual property
legal concept/
intellectual
Property
208
Right
The authority granted by law or international convention to do
or to authorise another person to do a defined act to
intellectual property
legal concept/
An entity possessing the capacity in law to exercise or
enjoy an intellectual property right
legal concept/
205
person
WP1a-006-2.0
15
June 2000
Metadata framework: principles, model and basic dictionary
legal view
Metadata Schema Diagram 4
persons
persons
make
make
used
usedby
by
own
own
intellectual
intellectual
property
property
in
in
rights
rights
Version 5.0 ©<indecs> June 2000
4.5
One model, three views
One of the keys to interoperability is to discover mechanisms for relating the different ways of
identifying what may (mistakenly) be viewed as the same entity. In the three views above, an
“entity” named as John Smith may be identified in the general view as a human being, in the
commerce view as a party and in the intellectual property view as a legal person. Each of
these has different attributes (and therefore metadata) and so must be treated as a distinct
entity. Yet it is commonplace for metadata from one of these “John Smith entities” to need to
interoperate with metadata from another.
5
Attributes
5.1
Generic attributes
The <indecs> framework asserts that the attributes of any entity may be usefully understood
as being of five types – labels, quantities, qualities, types and roles – each of which has its
own particular structure and behaviour, and this provides a generic structure for the
development and interoperation of metadata sets and systems for diverse kinds of entity
(Diagram 5 and Table 5.1).
WP1a-006-2.0
16
June 2000
Metadata framework: principles, model and basic dictionary
generic attributes
Model permission?
(event)
Metadata Schema Diagram 5
label
label
string
string
quantity
quantity
type
type
quality
quality
number
number
noun
noun
adjective
adjective
entity
entity
role
role
noun
noun
entity
entity22
Version 5.0 ©<indecs> June 2000
Table 5.1 Generic attributes
iid
element
11
label
quantity
quality
type
role
5.2
15
14
12
13
definition
structure
examples of subtypes
A string whose function is to
distinguish one entity from
another
A number measuring some
aspect of an entity
string + form
identifier name
number +
measure
dimension duration
59
61
62
force count rate
64
evaluation
A characteristic of the structure
or nature of an entity; an
intrinsic characteristic
adjectival
A categorisation of one or more
characteristics of an entity
through which it belongs to a
group of entities; a
characteristic role played by an
entity
A part played or function
fulfilled by an entity in relation
to another entity or entities; a
classification of an entity in
terms of its external relations;
an extrinsic classification
noun
language mode genre
36
31
colour gender
39
continuity etc
Any
noun
26
29
50
57
35
67
46
87
agent input output
116
context (see 6.2)
34
93
Characteristics of generic attributes
There are two characteristics of an <indecs> generic attribute.
The first, shown in the table above, is that the values of an attribute have a common form and
are supported by other common elements, even though they may be derived from more
WP1a-006-2.0
17
June 2000
Metadata framework: principles, model and basic dictionary
complex data. For example, quantity is a number value, and needs to be supported by a
measure (such as centimetres) to create a complete attribute.
Secondly, it should be possible for any value from any namespace at any level to be
substituted intelligibly as a value of one of its supertypes within the dictionary hierarchy (for
example, a height of 15 cms remains intelligible, though less informative, if shown as a value
of its supertypes distance, dimension or quantity. These characteristics provide part of the
framework of interoperability to allow values originated in one namespace to be recognised
and used in another, with greater or lesser degrees of precision.
6
Relations
Metadata, as it is data about data, is built on the relationships between entities. To say that x
has attribute y is to describe a basic relation. Relations, particularly events, are the most
important structures in the <indecs> framework.
6.1
Relation types
Metadata relationships may be described at three levels of complexity, events, situations and
attributes. Events and situations are defined in Table 4.2. Attributes are described in 5.
Events are relations in which something changes, and are defined by active verbs.
Situations are relations in which something remains the same. Two important subtypes are: a
possessingSituation in which an agent has something, and an association where two things are
passively related. possessingSituations are determined by possessive verbs (such as have or
owns), and associations by is.
Attributes have been described in 5. One of them (role) plays the central part in relations.
6.2
Relation structure
Like any entity, a relation may possess all the generic attributes (labels, quantities, qualities,
types and roles), and its structure is illustrated in Diagram 6:
relation
roles
Model Event
roles)
Metadata Schema Diagram 6
label
label
string
string
quantity
quantity
number
number
quality
quality
adjective
adjective
type
type
noun
noun
relation
relation
agent
agent
input
input
output
output
(event
(eventonly)
only)
context
context
Version 5.0 ©<indecs> June 2000
WP1a-006-2.0
18
June 2000
Metadata framework: principles, model and basic dictionary
6.3
Roles
Relations consist of two or more entities that play roles in relation to one another. Four
generic roles provide the framework for the <indecs> relation structure:
Table 6.3 Relation generic roles
iid
definition
element
agent
input
67
An entity acting in an event or sustaining a situation; a
characteristic active role undertaken by an entity
A pre-existing entity which participates in a relation in a
passive, qualifying or supportive role
An entity created or changed through an event
87
output
genealogy
93
An entity within which an event took place or a situation
exists (typically, time or place)
context
role/
role/
role/
role/
All these roles have many subtypes. Agent, input and context roles may apply to any type of
relation; outputs apply only to events.
6.3.1
Agent roles
Agent roles are normally fulfilled by people or other beings, or by organizations of beings,
although in principle anything capable of action may be an agent. Agents determine the nature
of the event or situation. If a relation is thought of as a sentence, the agent is the subject of the
verb. In the <indecs> commerce view, the agents are known as parties and the verbs of
making (contributors) and using (users) are important. Some agent roles are simultaneously
types of both contributor and user.
Contributor roles are intimately related to the establishment of rights, and user roles to the
exercise of rights, so the identification of agent roles is central to the schema. Those listed
below provide the basic framework, for agent roles are often complex entities that identify not
only the basic act (for example, director) but the aspect of the creation that is affected (for
example, art director) and any number of formal qualifiers (for example, third assistant
graphic art director). In many domains the precise description of contributor roles has a
significant impact on the grant and exercise of rights.
The same applies to user roles (some of which as we have seen overlap with creating roles);
permissions are commonly explicit about types of use and the roles of users (for example, a
creation might be licensed to be passed by a disseminator to a student or scholar but not to a
consumer).
Table 6.3.1 Generic party roles
iid
element
party
68
contributor
creator
70
modifier
71
excerpter
compiler
72
73
replicator
WP1a-006-2.0
74
69
definition
genealogy
A party undertaking a role in a creative or commercial
relation
A party contributing to the making of something, in whole
or in part
agent/
party/
A party contributing to the making of an original creation,
in whole or in part
(original_creati
on).contributor
A party contributing to the making of a modification, in
whole or in part
modification.con
tributor; user/
A party contributing to the making of an excerpt, in whole
or in part
excerpt.contribut
or; user/
A party contributing to the making of an compilation, in
whole or in part
compilation.cont
ributor; user/
A party contributing to the making of a replica, in whole or
i
replica.contribut
/
19
June 2000
Metadata framework: principles, model and basic dictionary
producer
75
76
director
77
performer
operator
recorder
78
79
80
facilitator
82
user
81
or; user/
A contributor directing the activity of others in the making
of a creation
A contributor performing or interpreting an abstraction in
an expression
A contributor operating equipment to create content in a
creation
A contributor recording an event in the making of a creation
contributor/
contributor/
contributor/
contributor/
contributor/
A contributor providing support services to other
contributors
A party making use of an entity for any purpose
contributor/
party/
A party making an entity available to potential users
user/
recipient
512
A party to whom an entity is disseminated
user/
audience
120
A being or group of beings experiencing or enjoying a
percept in one or more modes
user/
84
disseminator
A party retaining possession of an entity in a situation
party/
730
A party tranferring rights to another in an iprTransfer
party/
731
A party to whom rights are transferred to in an iprTransfer
party/
A party to a concluded agreement
party/
possessor
granter
grantee
consenter
6.3.2
in part
A contributor responsible for the realisation of a creation
732
Input roles
Input roles are passive roles that qualify, support, or are subject to, acts of agents. This
definition of an input role is broad enough to cover all entities playing a role in an event or
situation which is not that of an agent, context or output. Some principal input roles for the
commerce view are shown in Table 6.3.2:
Table 6.3.2 Generic input roles
iid
definition
genealogy
An entity which is the object of the act in an event, or is
possessed or associated in a situation
An entity made use of by a user
party/
patient/
An entity made available by a disseminator
patient/
An entity retained by a possessor
patient/
A party in an association
patient/
A bounded thing used directly by a contributor
input/
An unbounded thing used directly by a contributor
input/
An entity described or otherwise significantly covered by
the contents of a creation; what a creation is about
A creation which is part of another creation
input/
A creation from which another creation is wholly or partly
made; a creation which is the basis for another
input/
controlled
733
Creation
A creation in which intellectualPropertyRights exist
input/
transferred
734
Right
A right which is the subject of an iprTransfer
input/
element
patient
86
usedEntity
195
disseminatedE
196
ntity
197
possession
associate
660
90
tool
91
material
subject
92
component
89
sourceCreation
88
WP1a-006-2.0
20
input/
June 2000
Metadata framework: principles, model and basic dictionary
6.3.3
Output roles
Outputs are entities resulting from an event which were not pre-existent, or which are new
versions of pre-existing entities with different attributes. In the commerce view, output roles
are fulfilled by creations.
6.3.4
Context roles
Context roles are those played by time and place.
6.3.5
Role qualification
A role may carry a variety of qualifications, including the sequence in which it appears among
a group of roles (for example, chapter 1 of 20) and the quantity of an entity included in the
relationship (for example, 15 seconds of an audio recording included in a soundtrack).
6.3.6
Roles and types
All the same elements feature as both roles and types: when roles are attributed to an entity
outside of the setting of an event or situation they become characteristic types. For example,
Beethoven was the composer of Fidelio in an event; so from this and other events it is
established that Beethoven was a entity of the type composer. Similarly if a translation is be
the output of a translating event, then translation is a type of the output creation.
Any entity fulfilling a role in a relation may then be said to be of the type described by the
role, although in practice such attribution tends only to occur when an entity is identified
regularly with a particular role (if a person once played a brief part in an amateur stage
production, it would be technically correct but misleading to characterise them generally as an
“actor”).
6.4
Events
An event may be simple or complex. Any number of beings, things, concepts, times and
places may be involved in events, each playing different roles. Events may contain, or overlap
with, other events or relations to any degree: any number from one to all relations may be
common to two events, each qualified to a different level of granularity.
In contrast to the conventional resource-based (“stuff-centred”) approach to commerce
metadata, the event structure offers at least three major attractions for metadata
interoperability:
First, it is a way of creating the maximum number of metadata relationships with the
minimum amount of duplication. For example, where many parties play several contributor
roles at different times and places, using different tools (as, for example, in the making of a
film), this can be most simply described as a series of events.
Secondly, it provides a single, common and endlessly repeatable structure for integrating the
whole range of distinct creative, commercial and legal events which comprise the different
views relevant to IP e-commerce. The event structure is proposed as the long-term glue for ecommerce metadata interoperability.
Thirdly, the event structure provides the most efficient means to track changes that relate to
persistent entities. Beings, things and concepts have things happening to them constantly
(some of which need recording), while they retain a consistent identity. In rights management
in particular, tracking complex changes in ownership and in licensing terms and conditions is
critical.
6.4.1
Event types
Event types are determined by the agent role(s) they contain. Principle event types in the
commerce view include:
WP1a-006-2.0
21
June 2000
Metadata framework: principles, model and basic dictionary
Table 6.4.1 Commerce view principal event types
elementiid
105
expression
creatingEvent
19
transformingE
20
vent
usingEvent
21
disseminatingE
226
vent
22
transaction
agreement
offer
24
payment
25
23
definition
genealogy
A creation which is an event
event/
An event which results in the making of a creation
creating_event
An event which results in the making of a new creation
including elements of at least one existing creation; an event
in which both creating and using occur
event/
An event in which a result is the use of an entity
using_event
An event in which a result is the dissemination of an entity
disseminating_ev
ent
An event determining or recording the use or possible use of
an entity
event/
An event in which a written or unwritten accord is made
between two or more parties
transaction/
An event in which a party makes known the terms on which
an agreement may be made
transaction/
An event in which a party gives money to another party
transaction/
The structure of typical creatingEvents and usingEvents are shown in Diagrams 7 and 10
below, and agreements in section 10.
creatingEvent
Model Event
roles)
Metadata Schema Diagram 7
label
label
quantity
quantity
quality
quality
type
type
creatingEvent
creatingEvent
agent
agent
contributor
contributor
(=party)
(=party)
output
output
input
input
creation
creation
tool
tool
(=thing)
(=thing)
context
context
time
time
place
place
Version 5.0 ©<indecs> June 2000
WP1a-006-2.0
22
June 2000
Metadata framework: principles, model and basic dictionary
usingEvent
Model Event
roles)
Metadata Schema Diagram 10
label
label
quantity
quantity
quality
quality
type
type
usingEvent
usingEvent
agent
agent
user
user
(=party)
(=party)
input
input
context
context
usedCreation
usedCreation
(=creation)
(=creation)
tool
tool
(=thing)
(=thing)
time
time
place
place
Version 5.0 ©<indecs> June 2000
Events which involve the use of one creation in the making of another combine both these
types and become transformingEvents (Diagram 8):
transformingEvent
Model
Event roles)
Metadata Schema Diagram 8
label
label
quantity
quantity
quality
quality
type
type
transformingEvent
transformingEvent
agent
agent
contributor
contributor
user
user
(=parties)
(=parties)
input
input
output
output
sourceCreation
sourceCreation
(=creation)
(=creation)
tool
tool
(=thing)
(=thing)
creation
creation
context
context
time
time
place
place
Version 5.0 ©<indecs> June 2000
WP1a-006-2.0
23
June 2000
Metadata framework: principles, model and basic dictionary
6.4.2
Event granularity
Events may be as big or small as needed, as determined by functional granularity. An event
may contain any number of other events, but what defines a single event is strictly constrained
by syntactic rules. The syntax of <indecs> events reflects the structure of simple sentences. A
valid <indecs> event must conform to these syntactic rules:
1
Each entity in an event plays at least one role expressed as a relation between the
entity and the event.
2
Each event has at least one agent playing at least one agent role.
3
Entities may play more than one role in one event.
4
Two or more entities may play the same role in one event.
5
Within any one event, all non-agent roles (input, output or context roles) must apply
directly to all agent roles.
Rule 5 is the key to the structure, as this rule controls the level of granularity required in any
group of events. Here is an example to illustrate this:
Two people (A and B) collaborate in writing and illustrating a book (X), in England in 1999.
This can be shown as a single event which includes:
Author A (agent) + Illustrator B (agent) + Book X (output) + England (context) + 1999
(context).
However, if we wish to record that the text was written between March and August in
Manchester, and the illustrations completed in October in Nottingham, we require two
separate events, as the context roles no longer apply to both agent roles:
Author A (agent) + Book X (output) + Manchester (context) + March-August 1999 (context).
Illustrator B (agent) + Book X (output) + Nottingham (context) + October 1999 (context).
These two separate events can themselves be shown as being an input of the larger “parent”
event already described. The description can be made more granular by, for example,
identifying the day on which each illustration was completed, and by identifying chapters and
illustrations as individual outputs of specific events, and inputs into larger events. There is no
logical limit to the level of granularity. Such a structure can be applied to describing, for
example, the complex creative process involved in a film or multimedia creation, allowing
specific aspects to be recorded in great detail while others are treated more simply. Events
may have any degree of granularity: extreme granularity is required to record many technical
processes for many purposes, including rights management, multimedia production and
scholarship.
6.5
Situations
A situation is a relation that continues to happen for a period of time and/or in a given place
without changes in status. For example, a person being resident in a certain place, or a person
owning certain rights in a creation for a period of time, can be described using the relation
structure and syntax. The verbs used here include those of possession (has) and being (is).
Situations share many of the characteristics of events, but do not have outputs. There are two
types of situation:
Table 6.5 Situation types
elementiid
definition
genealogy
possessingSituat
403
ion
A situation in which an entity is owned or kept by another
entity; a relation based on the verb to have.
possessing_situat
ion
A situation in which two or more entities are passively
l t d
l ti b d
th
b b
situation/
124
association
WP1a-006-2.0
24
June 2000
Metadata framework: principles, model and basic dictionary
related; a relation based on the verb to be
In a possessingSituation, the owner or possessor plays an agent role. In an association, all
associated parties play an input role of associate.
7
Parties
In the commerce model, a party is defined by what it does: that is, the agent role it plays in a
creative or commercial event. So it is meaningful, for example, to say that John Williams,
Marilyn Monroe, the London Philharmonic Orchestra and Mickey Mouse are all performers,
even though one is a “real” human being, one is using a stage persona, one is a name that
represents a constantly changing group of individuals, and one is a fictional cartoon character.
However, although the commerce model is not primarily concerned with describing people
and organizations, parties commonly require their own metadata, independent of creative and
commerce events, to fulfil some basic functions of interoperability. How do we know or
record the fact that the John Williams performing here is the same as the one composing there,
or that Fred Astaire is an alias of Frederick Austerlitz, or keep track of the members of the
London Philharmonic Orchestra, or record the relationship between Mickey Mouse and the
performer speaking his voice? While much of this can be done through the events described
above, party metadata provides a different but essential view.
Party metadata conforms to the generic attribute structure: parties have labels (such as names),
quantities (such as age), qualities (such as gender), types (such as individual or organization)
and play roles in relations (such as birth, death, marriage and membership of groups).
The need for stable party identifiers and related metadata is covered in more detail in the
17
<indecs> Directory of Parties proposal . The principal party types are given below:
Table 7 Principal party types
elementiid
humanBeing
17
16
animal
plant
18
615
organization
ensemble
596
definition
genealogy
A man or woman of the species homo sapiens [OED]
being/
A living organism which feeds on organic matter, usually
possessing specialised sense-organs and a nervous system
[OED]
being/
A living organism of the species Plantae, usually containing
chlorophyll enabling it to live wholly on inorganic substances
and lacking specialised sense organs and the power of
voluntary movement [OED]
being/
A group of human beings (whether legally incorporated or
not)
group_party
A group of creators
organization/
8
Creations
8.1
A model of making
The top-line relationship of the commerce view (people make stuff) involves creating and
using events. Different types of creation come into existence through these, with different
attribute subtypes (and giving rise to different intellectual property rights). These different
WP1a-006-2.0
25
June 2000
Metadata framework: principles, model and basic dictionary
types and relationships can now be understood by combining the general and commerce views
through the events model into this model of making (Diagram 42):
a model of making
Metadata Schema Diagram 42
Diagram 42
Diagram 3
percept
percept
is used in
place
place
happens in
artefact
manifestation
produces
has instance
item
is fixed in
party
acts in
event
event
expression
is abstracted to
is abstracted to
is expressed in
happens in
is part of
abstraction
time
time
is used in
concept
concept
Version 5.0 ©<indecs> June 2000
8.2
Creation types
Table 8.2 Creation types
iid
definition
genealogy
406
A creation which is a thing (derived)
created_thing
A single instance of an artefact
artefact/
An artefact containing an infixion of an expression
artefact/
An artefact on which an expression may be infixed
to create a manifestation
artefact/
An event which is a creation
event/
A creation which is a concept; an abstract creation
whose existence and nature are inferred from one or
more expressions or manifestations
concept/
element
artefact
98
item
101
manifestation
format
32
105
expression
106
abstraction
The relationship of four of these creation types is further elaborated in Diagram 11 (which is a
“detail” of Diagram 42). The main function of these distinctions is that each of these different
types of creation may give rise to a different intellectual property right; for example, in an
audio CD there are separate rights in the physical product (manifestation), the recorded
performances (expressions) and the songs performed (abstractions), and these each require
distinct metadata at some point in the commerce chain. These rights have different values in
different jurisdictions, and will commonly be owned or controlled by different people and
organisations. While music is used as an example, parallel situations exist for all other genres
of creation. Without the clear structural distinctions of this kind, effective rights management
is impossible.
WP1a-006-2.0
26
June 2000
Metadata framework: principles, model and basic dictionary
creation types
Metadata Schema Diagram 11
atoms, bits “I made it”
artefact
perceived
manifestation
has instance
identifiers
include
isrc
doi
actions “I did it”
is fixed in
expression
spatiotemporal
Diagram
Diagram
5
8
identifiers
include...
isbn
upc/ean
umid
doi
item
is abstracted to
is abstracted to
is expressed in
abstract
abstraction
Concepts “I conceived it”
identifiers
include
iswc
isan
issn
pii
doi
Version 5.0 ©<indecs> June 2000
8.2.1
Artefact, Manifestation, Item and Format
An artefact is a created, inanimate percept: anything from a nail to a book to a computer file
to a skyscraper.
A manifestation is a particular type of artefact in which expressions and/or abstractions are
recognised which may have underlying intellectual property. Manifestations include the
books, CDs, videocassettes, films, newspapers, software programs, digital objects and all the
other forms of created stuff which manifest “content”. Manifestation metadata is in the frontline of e-commerce requirements.
However, a manifestation is typically not an individual creation but a class of creations. For
example, in describing a book with its ISBN, format, title, author and subject classes, we are
describing all instances of that book. However, if 50,000 copies are distributed, each of these
may require its own metadata for identification, location, ownership and so on, and these
become items, which inherit metadata from the manifestation which may be supplemented by
local metadata specific to the item.
A format is an artefact which requires content to become a manifestation: a blank DVD, an
empty computer file or a book without words. A manifestation might be thought of as the
combination of format and expression.
8.2.2
Expression
An expression is a performance – an event which is in itself regarded as a creation and may or
may not be recorded or fixed in a manifestation, and may be reproduced by some form of
recording playback.
The expression is the event which is recorded, not the physical or digital recording itself,
which is a manifestation. One expression may be recorded and copied onto many media while
maintaining its integrity.
An expression may give rise to an abstract work; at the same time it may be an expression of
an existing abstract work.
WP1a-006-2.0
27
June 2000
Metadata framework: principles, model and basic dictionary
Separate rights frequently exist in expressions. Recorded audio and audiovisual performance
are the most commonly identified expressions. Live performances are also creations that may
require identification and description for rights purposes, even if the performance itself is not
recorded in audio or audiovisual form. Static manifestations such as texts, paintings or
photographs are the results of creatingEvents, but these events themselves (the act of writing
or photographing, for example) are not generally treated as expressions (or intellectual
property) in themselves.
8.2.3
Abstraction
An abstraction is the entity often popularly called a work. However, in the <indecs>
framework a work is a piece of intellectual property (ip) defined directly in terms of the legal
provisions of the Berne Convention, so while all works are abstractions, all abstractions are
not necessarily works in the legal sense. Abstractions are the hardest types of creations to pin
down. They are recognised as the common denominator between various different
performances or manifestations. For example, the same work may be recognised underlying a
dozen different performances of Hamlet, or different recordings of My Way, or editions and
translations of Moby Dick. In the bibliographic community, abstractions are sometimes
referred to by uniform titles.
Common formal elements, such as a storyline, or a melody, or the arrangements of words and
images, are typical evidence of a common underlying abstraction, and it is these elements of
expression which are subject to copyright; but the precise characteristics by which such
recognition is secured are elusive and are settled by editorial, commercial or, ultimately, by a
legal judgement. The point at which new abstract works or versions of works are identified is
therefore imprecise, and subject to the principle of functional granularity. This will vary
considerably from genre to genre and form to form. Rights are one of the major drivers of
functional granularity. For example, if a translation has different rights from the original work
(which will almost certainly be the case), it must be identified as a distinct creation.
8.3
Creation identifiers
Creation identifiers are among the most important elements of intellectual property metadata.
An initial set of these is included in the Framework Metadata Dictionary:
Table 8.3 Some significant creation identifiers
elementiid
172
bici
catalogNo
174
doi
175
genealogy
Book Item and Component Identifier
creation.identifier/
An identifier given to an entity in a disseminator's
catalog
identifier/
Digital Object Identifier
creation.identifier/
European Article Number
artefact.identifier/
176
International Standard Audiovisual Number; draft ISO
standard identifier for audiovisual abstractions
abstraction.identifier/
177
International Standard Book Number; ISO standard
identifier for books
manifestation.identifi
er/
International Standard Music Number; ISO standard
identifier for printed music
manifestation.identifi
er/
179
International Standard Serial Number; ISO standard
identifier for serial publications
serial.identifier/
180
International Standard Recording Code; ISO standard
identifier for audio and video recordings
expression.identifier/
International Standard Musical Work Code; draft ISO
standard 15707 identifier for compositions
composition.identifie
r/
ean13
isan
isbn
178
ismn
issn
isrc
iswc
WP1a-006-2.0
620
definition
181
28
June 2000
Metadata framework: principles, model and basic dictionary
183
pii
185
sici
186
umid
upc
8.4
187
Publisher Item Identifier; an identifier for textual
abstractions
abstraction.identifier/
Serial Item and Contribution Identifier; a NISO standard
identifier for components of serials
creation.identifier/
Universal Media Identifier; an SMPTE standard
identifier for digital content
creation.identifier/
Universal Product Code
artefact.identifier/
Creation qualities
The number of possible formal characteristics of creations is limitless. Some of the most
significant are given in the table below:
Table 8.4 Some significant creation qualities
elementiid
mode
46
209
origination
genre
34
language
colour
35
36
substance
37
33
infixion
continuity
39
485
completion
8.5
definition
genealogy
subtypes
A sensory mode or modes
through which an entity may be
perceived
form/
audio gustatory
162
163
visual olfactory
164
tangible
A process by which a creation is
made
form/
original excerpted
212
213
compiled modified
215
216
replicated natural
A style or manner of the
expression of an abstraction
expression.form/
lexical musical
283
pictorial
295
audiovisual
504
narrative etc
A particular form of verbal or
symbolic expression of an
abstraction
lexical_expression
.form/
all languages
A visual attribute of an entity
resulting from the separation and
combination of particular
wavelengths of light
visual_expression.
form/
all colours
The form of the material of
which an entity is made
form/
physical
The means of representation or
fixing in which an expression of
an abstraction is established in
or on a manifestation (aka
encoding)
manifestation.for
m/
analogue
135
bitEncoded
The nature of dynamism of an
entity over time
form/
dynamic
The status of a creation in the
course of the creative process
form/
draft
160
161
214
211
288
282
132
133
digital
134
486
138
static
139
487
finished
etc
Creation-to-creation relation roles
The most important roles played by creations have been described in creation types (8.2) (as
has been noted in 6.3.6, terms used as types or roles are interchangeable). Other principal
roles which creations play in events and situations are:
Table 8.5 Some creation-creation relation roles
elementiid
WP1a-006-2.0
definition
role type
29
June 2000
Metadata framework: principles, model and basic dictionary
96
originalCreation
99
compilation
excerpt
95
97
modification
replica
448
sourceCreation
9
88
A creation without a source input
output
A creation made from two or more pre-existing creations of
other types
output
A creation which is made by extraction from a pre-existing
creation
output
A creation made by changing a pre-existing creation of the
same type (aka version)
output
An item made by copying another item
output
A creation from which another creation is wholly or partly
made; a creation which is the basis for another
input
Intellectual property
Intellectual property (ip) is a legal concept. Its terms are generally understood (amongst
lawyers at least) and defined in a series of international conventions and treaties and under
national law.
ip includes items protected by copyright, neighbouring (or related) rights and patent and
trademark law, among others.
This legal view finds expression in three main classes of entity: ipTypes, ipRights (ipr) and
person, each of which is defined in table 4.4. <indecs> recognises that legal concepts relevant
to e-commerce must be defined within an IP legal namespace and does not try to re-define
these. Here are examples of the kind of terms and definitions required from a legal
namespace:
Table 9 Examples of ip types
element
definition
work
As defined by the Berne Convention for the Protection of Literary and Artistic
Works, the WIPO Copyright Treaty and the TRIPS Agreement
performance
As defined by the International Convention for the Protection of Performers,
Producers of Phonograms and Broadcasting Organisations (Rome Convention),
the WIPO Performances and Phonograms Treaty and the TRIPS Agreement
phonogram
As defined by the International Convention for the Protection of Performers,
Producers of Phonograms and Broadcasting Organisations (Rome Convention),
the WIPO Performances and Phonograms Treaty and the TRIPS Agreement
broadcast
As defined by the International Convention for the Protection of Performers,
Producers of Phonograms and Broadcasting Organisations (Rome Convention),
the WIPO Performances and Phonograms Treaty and the TRIPS Agreement
criticalOr
Scientific
Publication
As defined by Article 5 of the European Directive harmonising the term of
protection of copyright and certain related rights
Definitions of this kind, mediated as required by territorial and temporal constraints, are
needed to support the vocabulary of IP types, rights and legal persons which is routinely used
in IP-based metadata systems.
10
IPR Transactions
10.1
Overview
Transactions (specifically in this context, iprTransactions) cover the <indecs> approach to
describing rights ownership and what are commonly called “business rules” for ipr.
Ultimately they rely on the combination of ipr vocabulary with commerce vocabulary
WP1a-006-2.0
30
June 2000
Metadata framework: principles, model and basic dictionary
An intellectual property right (ipr) is defined by <indecs> as the authority granted by law or
international convention to do or to authorise another person to do a defined act to
intellectual property. Rights transactions depend on a “chain” of grants of rights and of
permissions: this chain is established initially by law or statute, in what may be viewed as the
original binding agreement that confers rights to a person. Whether the laws are concerned
with copyright, patent law or other forms of ip is unimportant for the operation of the
framework
Rights normally flow from the original creator(s) of a piece of intellectual property through a
series of ipr agreements, passing through an indefinite number of intermediaries to an
indefinite number of end users. An agreement is defined as an event in which a written or
unwritten accord is made between two or more parties. In iprAgreements, parties may agree
to pass on ip Rights in an iprTransfer, or they may agree to some act being permitted,
prohibited or required in relation to the exploitation of specific ipr. The details of these agreed
acts form the “business rules”.
In the <indecs> framework, the term agreement has a very broad meaning and is designed to
encompasses all forms of agreement which relate to the protection and use of ipr, from
international law at one extreme to licences for Internet downloads of individual files at the
other.
Agreements may or may not require documentation, and this documentation may or may not
need to be integrated at any point in the chain. However, in the e-commerce environment
there is a growing need for an electronic system of documenting rights which
1.
2.
3.
4.
5.
accommodates any type of right or creation;
allows for the integration of incomplete information at any point in the chain;
supports a high level of automated metadata generation;
is integrated with descriptive metadata systems; and
allows data to be transformed into and out of alternative structures, including
accounting systems.
An events-based transaction structure appears able to support these requirements optimally.
10.2
Integrating rights and commerce metadata
Rights in a particular item of ip can be encapsulated in an iprStatement (see 10.3): a situation
which identifies the legal person owning or controlling a particular ipr (for example, the
copyright) in a particular item or group of ip (known in this context as controlledCreations).
Rights are then passed on through agreements (see 10.4), whereby parties may also agree on
the uses to which creations may be put. This can be done using <indecs> commerce
vocabulary within the relation model. Agreements also cover the transfer from one person to
another of the right to grant further uses to other parties (an iprTransfer, see 10.4.2.3).
The outstanding requirement is to establish the appropriate mappings between user roles in
the commerce view and rights as defined in a legal namespace, to allow iprStatements and
agreements or usage reports to be correlated. Contributor roles (for example, author,
composer, performer and translator) need to be mapped to rights for given creation types and
jurisdictions so that provisional iprStatements may be generated by inference from
descriptions of the creatingEvents themselves. For example, a creatingEvent in which party A
is the composer of composition B may give rise to the iprStatement person A is the copyright
owner of work B in a given jurisdiction.
Such inferences can only ever be provisional, and their reliability will depend on the authority
with which the descriptive statements have been made, and the assertions which back them up
(see 11). However, it is likely that the ability to produce iprStatements simultaneously with
descriptive ones as part of an integrated process will become an e-commerce necessity, as will
mechanisms for automatically exchanging and integrating details of diverse iprStatements and
WP1a-006-2.0
31
June 2000
Metadata framework: principles, model and basic dictionary
agreements to support licensing and payment systems. This may be viewed as the ultimate
challenge for e-commerce metadata interoperability.
10.3
iprStatement
An iprStatement is a situation (see Diagram 12 below) which describes the ownership of an
ipr, or of some entitlement to agree to further exploitation of an IPR. iprStatements are based
on “possessor” roles, such as owner or rights administrator:
iprStatement
Model Event
roles)
Metadata Schema Diagram 12
label
label
quantity
quantity
quality
quality
type
type
iprStatement
iprStatement
agent
agent
owner
owner
(=party)
(=party)
input
input
context
context
possession
possession
(=ipr)
(=ipr)
controlled
controlled
Creation
Creation
(=ip)
(=ip)
time
time
place
place
Version 5.0 ©<indecs> June 2000
An iprStatement, when used as the patient of an assertion (see 11), can form part of an input
to an agreement. It is by this device that the authority to enter into an agreement is established.
10.4
Agreement
iprAgreements record where, when and by whom a deal was concluded. A generic agreement
following the event structure is given in Diagram 13:
WP1a-006-2.0
32
June 2000
Metadata framework: principles, model and basic dictionary
agreement
Model Event
roles)
Metadata Schema Diagram 13
label
label
quantity
quantity
quality
quality
type
type
agreement
agreement
agent
agent
output
output
consenters
consenters
(=parties)
(=parties)
permission
permission
requirement
requirement
prohibition
prohibition
iprTransfer
iprTransfer
(=relation)
(=relation)
context
context
time
time
place
place
Version 5.0 ©<indecs> June 2000
In popular usage the term agreement is often taken more narrowly to mean a document or
contract signed by the parties, but it explicitly does not have this meaning in the <indecs>
framework. Such a contract document may in reality encompass the terms of many
agreements, in whole or in part: an appropriate data element for this, and the description of its
relations with such agreements, remains to be identified.
10.4.1
Direct attributes of agreements
Agreements may have labels in the form of identifiers and names. Contract and licence
numbers are common forms of agreement identifier. The development of more widely
recognisable agreement identifiers is an essential prerequisite for widespread automated
interoperability in e-commerce rights management, for use in both public and confidential
party-to-party environments.
Quantities are not prominent features of an agreement itself, although they may record, for
example, a count of its parties or other components.
Quality attributes may record, for example, whether an agreement is verbal or written, or
exclusive or non-exclusive.
There are many types of ipr agreement, including (for example) those commonly called
publishing agreement, sub-publishing agreement and licence. The original grant of a right by
law is itself an agreement between a person or persons and a collective person in the form of a
nation, government or other legal entity. The identification of standard agreement types,
generically and by sector, is necessary for interoperability. An agreement type will often
automatically determine which roles feature in its outputs: for example, a public performance
licence may determine that the agent role in the permitted action is one of performer and that
others may fulfil an audience agent role.
10.4.2
Agreement relations
An agreement has at least two parties. Normally these will be legal persons, but the <indecs>
agreement structure is neutral as to whether an agreement is enforceable by law: it simply
describes who has agreed what. According to the nature of the outputs, the roles of the parties
WP1a-006-2.0
33
June 2000
Metadata framework: principles, model and basic dictionary
to an agreement may be more specific than simply “parties” (for example, granter and grantee
of rights).
The context role of the agreement identifies where and when the agreement was made. Note
that this refers only to the making of the agreement itself, not to the time or place of events or
situations which are the subject of its terms: those are dealt with in the outputs.
The direct attributes of the agreement itself are normally quite simple: the complexity comes
in the terms of the deal which are set out in the relations permitted, required or prohibited or
in the rights transferred by the rights agreement, which are its outputs. The four generic
outputs so far identified are defined in Table 9.3.2.
Table 9.3.2 Rights agreement outputs
elementiid
110
permission
requirement
113
496
prohibition
iprTransfer
500
definition
genealogy
A relation which is allowed by an agreement
permitted_relation/
A relation which is necessitated by an agreement
required_relation/
A relation which is forbidden by an agreement
prohibited_relation/
A situation in which an ipr is transferred by an
agreement
situation/
A properly constituted agreement will always contain at least one permission, prohibition or
iprTransfer. It does not need to contain a requirement.
While the <indecs> schema is designed to allow for the complete documentation of the terms
of agreements, including their financial and other terms, it assumes no obligation of disclosure
of any specific terms in any particular circumstances. It is common in current practice for
certain aspects of agreements – such as the details of the owners or agents representing rights
owners in specific territories – to be made generally available, while the date of the expiry of
the agreement, or the financial terms by which it was secured, remain confidential. Such
partial recording or disclosure of agreements is the commercial norm and is not prejudiced by
the <indecs> schema, but is rather enabled by it.
Agreements imply, but do not always assert, that the granter of ipr has the authority to do so.
This can be made explicit within an agreement by the inclusion of an assertion (see 12) of
which an ipr statement is the output, or by a chain of two or more agreements, at the head of
which will be an assertion.
10.4.2.1 Permissions and prohibitions
These outputs come in the form of events or situations. Transforming, disseminating and other
using events have been described above (6.4.1), and these are the normal kinds of permitted or
prohibited outputs. This is the focal point for the integration of rights and descriptive
metadata, because the reporting of an event which has taken place (descriptive metadata), or
an event which may or may not take place (rights metadata) may take precisely the same
form.
Where a difference occurs, it is typically that the scope of a permitted event is broader than
that of an event which actually takes place. For example, a party may be permitted to make
“up to ten copies” of any of a hundred different creations in a catalogue at any time during a
three year period, but may in practise only make a few copies of ten of these creations at
specific times. This leads to the frequent identification of classes of party, creation or context
as having roles within permitted events. At times, these classes will themselves be defined by
other agreements: for example, a party may allow another party to use all the creations for
which he has acquired rights from a third party under another agreement or set of agreements.
All these arrangements can be described as groups or chains of relations.
WP1a-006-2.0
34
June 2000
Metadata framework: principles, model and basic dictionary
10.4.2.2 RequirementsRequirements are stipulated in many forms, including that of a payment or of
approval for specific use being sought and given. In theory any event may be required as a condition an
agreement, including a reciprocal agreement. The basic structure of a payment event may normally be
straightforward enough, but the quantification of money (or any other entity) may be open to any degree
of complex calculation. The event structure does not model numeric calculation, but may refer to any
external method or source from which conditional or unconditional values or formulae may be derived.
10.4.2.3 iprTransfers
An iprTransfer is a situation which is the output of an agreement in which ipr in one or more
ips is assigned or transferred from one party to another. This model applies irrespective of
whether such assignment is limited by time, place or non-exclusivity. The iprTransfer
structure is shown in Diagram 14:
iprTransfer
Model Event
roles)
Metadata Schema Diagram 14
label
label
quantity
quantity
quality
quality
type
type
iprTransfer
iprTransfer
agent
agent
granter
granter
grantee
grantee
(=parties)
(=parties)
input
input
context
context
transferred
transferred
Right
Right
(=ipr)
(=ipr)
controlled
controlled
Creation
Creation
(=ip)
(=ip)
time
time
place
place
Version 5.0 ©<indecs> June 2000
In many agreements (such as agency agreements), one party gives to another the right to grant
further permissions to third parties, without actually assigning the ownership or control in the
right itself. This doesnot need to be shown by an iprTransfer, but simply as another permitted
event in the form of an agreement in which the party granted the right themselves appears as a
granter of further permissions.
10.5
Offers
An offer is an event in which one or more parties sets out the terms of a possible agreement.
11
Assertions
An assertion is an event in which a party makes a claim of veracity about something.
Assertions are the mechanisms in the <indecs> framework by which authority is established
(see 2.3: The principle of designated authority).
WP1a-006-2.0
35
June 2000
Metadata framework: principles, model and basic dictionary
It involves an agent role of asserter (or a more specific subtype such as a warrantor) and a
patient role of the thing asserted, which may be anything from the statement of a simple
attribution (“this book has 200 pages”) to a complex set of ipr agreements or a tax return. The
basic structure of an assertion is shown in Diagram 15:
assertion
Model Event
roles)
Metadata Schema Diagram 15
label
label
quantity
quantity
quality
quality
type
type
assertion
assertion
agent
agent
asserter
asserter
(=party)
(=party)
input
input
context
context
asserted
asserted
Relation
Relation
(=relation)
(=relation)
time
time
place
place
Version 5.0 ©<indecs> June 2000
The qualities of an assertion may include degrees of veracity, the nature of the truthfulness of
an assertion according to the asserter, of which typical values may be true, probable,
possible and false.
Any number of assertions may be made about a relation by any number of asserters.
12
Non-textual metadata
All the examples in this document have been taken from textual metadata. However, metadata
may equally be comprised of non-textual creation types, such as diagrams, thumbnail images,
audiovisual and audio clips, watermarks and so on. The principles and mechanisms of the
framework apply equally to these.
13
Transformations
The document provides a reference model and does not specify mechanisms for the delivery,
mapping or transformation of metadata, whether through parsers, metadata registries or other
mechanisms. A technical paper on the further development of the event model to support
metadata interoperability can be found at the abc project.18
14
Framework Metadata Dictionary
The framework metadata dictionary holds information on <indecs> metadata elements, their
names, iids, definitions, relationships and mappings to elements in other schemas.
WP1a-006-2.0
36
June 2000
Metadata framework: principles, model and basic dictionary
Here is an example of a basic dictionary entry for the element modification, followed by an
explanation of particular components.
14.1
element name
description
genealogy
iid
modification
A creation made by changing a pre-existing
creation of the same type (aka version)
modified_creation
97
Element names
English language element names are selected for convenience, clarity and precision. Where
popular usage has rendered a term widely ambiguous (for example, publisher) or where it has
a specific technical or legal meaning which is likely to confuse (for example, object, work)
these are generally avoided in the <indecs> framework unless they are being used according
to an established external definition. In some cases uncommon or unusual element names are
selected precisely because they lack semantic baggage (for example, the terms percept and
infixion). Within the metadata dictionary, an element name has some semantic value, but
without its definition and generic identity (see below) this is limited. Elements may and will
use different names in different <indecs>-based schemas, and of course in languages other
than English.
14.1.1
Element name synonyms
A synonym within the dictionary is viewed as semantically indistinguishable from the main
element name and iid. These are shown here in bold type as an aka in brackets after the
definition.
14.2
Element definition
The purpose of an <indecs> definition is to support semantic identity between different views
and therefore to allow for the mapping of elements in different schemas which need to
recognise one another’s data. This purpose is functional rather than philosophical. What
matters for interoperability is that two parties or schemas use a term in the same way, not that
the definition is any absolute or abstract sense “right” or “wrong”. In the nature of language
and reality, such identity is ultimately elusive: words are ambiguous and success in
interoperability will always be approximate to some degree. The underlying purpose of the
<indecs> framework is to reduce ambiguity and approximation so far as is possible, and
where it is irreducible (for example, where an element in a schema is found to be inherently
ambiguous in its definition or operation) to provide a user with choices for its resolution,
whether by human or automated means. Like any dictionary, the <indecs> Framework
Metadata Dictionary uses a number of devices to attain precision. <indecs> definitions
include primary and derived components:
Where a definition includes a terms which is itself defined in the <indecs> dictionary, this is
highlighted in bold type.
14.2.1
Primary definitions
Primary definitions are those that do not rely wholly on predefined terms, and are the points at
which new semantic material is introduced into the schema19. With every primary definition
comes the possibility of further ambiguity; the higher the elements are placed within the
hierarchical levels of the Metadata Dictionary, the more problems any such ambiguity will
cause.
For example, the element quality13 is defined as a characteristic of the structure of an entity.
In this definition only one term (entity) is pre-defined elsewhere in the dictionary (as
something which is identified). The effectiveness of the definition therefore relies on a
common understanding of what the terms “quality”, “characteristic” and “structure” mean.
This understanding is refined by the various subtypes of quality which the dictionary
identifies (mode, language, continuity, genre etc); by the provision of further glosses and
WP1a-006-2.0
37
June 2000
Metadata framework: principles, model and basic dictionary
descriptions (in this example, an intrinsic classification); by synonyms (form); by related
terms (to be added in future editions of the metadata dictionary), which are the same notion
rendered in different parts of speech (for example, percept and perceiver); and by
identification of terms to which it is opposed (that is, a term which cannot be simultaneously
attributed to an entity along with the term to which it contrasts). All of these devices are
designed to provide the least room for ambiguity and support the accurate analysis and
mapping of elements in other schemas.
14.2.2
Derived definitions
Derived definitions are those which are entirely determined by reliance on previously defined
terms without introducing new primary material. These are indicated in the Metadata
Dictionary by the term (derived).
For example, the element being5 has a derived definition, which means it can be compiled
from the components of its generic name animate_percept (generic names are described in
14.3.1). A percept2 is defined as “an entity which is perceived directly by one of the five
senses” and animate136 is defined as “of an entity with the characteristic attributes of life”, so
a being can be generically defined as “an entity with the characteristic attributes of life,
perceived directly by one of the five senses”.
While simpler glosses may be provided (for example, in this case a being is also described as
something that lives and dies), the more elaborate generic construction provides an analytical
basis for the underlying mapping of elements between different schemas, becoming
increasingly useful as more and more formal distinctions are added to create elements lower
down in the hierarchies.
14.3
Genealogy and syntax
The genealogy of an element is a structured account of its relationships with other elements.
Genealogies can be constructed in different ways according to the context of an element.
Genealogies can be specified for any element both as a subtype and as an event role. In the
published dictionary, the majority of genealogies are expressed as subtypes.
Genealogies are described with a specific syntax that has been developed for use within the
abstract expression of the metadata dictionary for the purposes of logical precision, and may
be translated into other syntactic forms as required for specific applications. Syntactic
conventions used to relate elements are given in the table below:
Table 14.3 Dictionary syntax
relationship
convention
is attribute of
. (full stop)
is constrained
by
_
(underscore)
is subtype of
/ (forward
slash)
is value of
> (greater
than)
is not applicable
to
~ (tilda)
WP1a-006-2.0
example and description
creation.identifier
The last term is an attribute of the first (“an identifier of a
creation”)
dynamic_relation
The first term places a particular formal constraint the last (“a
relation which is dynamic”).
creation/manifestation
The last term is a specialised type of the first (“a manifestation is a
type of creation”) and inherits its characteristics
continuity>dynamic
The first term functions as an attribute, of which the last is a value
(“dynamic is a value of continuity”)
(creation_input)~original
The last term does not apply when the previous term does
(“original is not a valid output role when the relation contains an
input which is a creation”).
38
June 2000
Metadata framework: principles, model and basic dictionary
is synonym of
= (equals)
may be
synonym of
%
(percentage)
is attribute of
related entity
{} (special
brackets)
combines with
+ (plus)
()
(brackets)
format=manifestation.form
The first term denotes the same entity as the last (“format and
manifestation.form are the same thing”)
dc:publisher%[75]indecs:disseminator%[25]indecs:contributor
The first term may be a synonym of either the second or third
(“dc:publisher may be the same as indecs:disseminator or
indecs:contributor”). Bracketed figures may be used to indicate
estimated probability.
{is-component-of}journal.title, journal{has-component}.title
The entity following or preceding the special brackets has the
specified relationship with the entity to which the attribute is
assigned (“title of journal of which this entity is a component”).
audio+visual=audiovisual
The terms combine together to make a new element which is an
arbitrary supertype of the combined terms (“audiovisual is a
supertype combining audio and visual”)
The expression within the brackets is a complex element. This
device is used as elsewhere to eliminate ambiguity where more
than one logical interpretation of the syntax is possible without it.
The last term in a generic description always denotes the element being referred to. For
example description.identifier refers to an identifier of a description, whereas
identifier.description refers to a description of an identifier. The generic syntax is used in
conjunction with element names to create generic names.
14.3.1
Generic names
The generic name shows the element’s genealogy in relation to another element(s), normally a
supertype, whether formally qualified by further elements or not. The generic name iid (not
shown here) expresses the same thing using iids.
For example, percept (iid=2) is a subtype of entity (iid=1) with the constraint perceived
(iid=191), so its full generic name is perceived_entity. This might also be expressed as a
generic identifier of iid=191_1.
Generic names can give a complete account or genealogy of an element’s relations, tracing it
back by one or more routes to entity, or they can be summarised as short generic names or
iids.
For
example,
The
full
genealogy
of
event
(iid=7)
is
(entity/concept/attribute/quality/continuity>dynamic)_(entity/relation). This has the short
form dynamic_relation. As relation has iid=4 and dynamic has iid=138, so the generic
identity of indecs:event can be summarised as iid=(138_4). Its complete generic name iid
would read 7=(1/3/9/13/39>138)_(1/4).
14.3.2
Generic role
This shows the structure of an event through which the element is created or otherwise
defined. For example,
(modifier_agent)_((source_creation)_input)_(creation_output)_output
shows that the element (modification) is an output of an event which has (at least) an agent in
the form of a modifier, a source creation and a new output creation.
14.3.3
Hierarchies
Qualification and constraint mean that an element begins to belong to more than one
hierarchy, as each qualifier adds one or more hierarchical routes into which it may be plotted.
For example, a physical_format (or carrier) is a subtype of format. If it is further qualified as
an analogue_physical_carrier, it becomes a subtype of both physical_carrier and
WP1a-006-2.0
39
June 2000
Metadata framework: principles, model and basic dictionary
analogue_carrier. If it is further qualified by the genre musical it becomes a
musical_analogue_physical_carrier with six possible parents; and so on.
14.3.4
Structure of generic labels
Short generic labels include only as much of the genealogy as is required to define the new
term fully in terms of one or more already defined terms. A short generic label contains
elements and syntax which indicate either the immediate supertype of an element or its
immediate attributes or constraints. The latter approach, which is preferable, can only be used
for a term which has a fully generic definition (see above). A short generic name such as
dynamic_relation is sufficient for placing an element into the genealogy as the remaining
elements in the chain can be derived from the genealogies of those two terms.
The order of elements in the generic short id of a qualified element is significant and must be
preserved. For example, a creation.description.identifier has a generic short id of 94.30.26,
whereas a creation.identifier.description is a quite different entity with a generic short id of
94.26.30.
The order of elements in a constrained element must also be preserved, although for a
different reason. Re-ordering a string of adjectives which constrain the same noun does not
affect the identity of the element (for example, a large green ball is the same as a green large
ball), but as strings need to be matched it is helpful for them to follow a predictable order. The
rule adopted is that the iids of constraints are listed in ascending numeric order. For example,
the constrained element, a musical_analogue_physical_carrier has iid=132_134_282_102.
Of course, if the adjectives qualify one another rather than the noun, the precise order does
matter: a light green ball has two quite different meanings. These will be constructed
differently according to the schema syntax as (light_green)_ball and light_green_ball.
14.3.5
Principle genealogy
Every element has at least one generic name and at least one generic role. However, in most
cases there are more or less common ways of managing them within metadata schemes. For
example, an identifier is normally treated simply as a type of label, and not the output of an
identifying event, whereas a requirement is most commonly treated as the output of an
agreement.
14.3.6
Other relationships
Other genealogical relationships, such as generic situations and linguistic “families” which
connect the various related parts of speech such as Creator, Creation, Creating and Created
will require identification to support developing needs of interoperability. These are not
specified in this document.
14.4
Complex element iids
Complex elements can be given simple identities for the purpose of interoperability: for
example creation.identifier may be given an iid as a composite, as well being described as
iid=94.26 as the composite of creation94 and identifier26.
14.5
Dictionary
This table includes all terms already defined or shown in bold type in the <indecs> metadata
framework: principles, model and basic dictionary document. iids have been provisionally
allocated to elements other than those listed here (accounting for the breaks in the numbering
sequence). More extensive versions of the dictionary may be published in future.
Table 14.5 Framework basic metadata dictionary
element
description
abstract
WP1a-006-2.0
Of an entity conceived in the mind only (aka
40
genealogy
mode>
iid
159
June 2000
Metadata framework: principles, model and basic dictionary
conceived)
abstraction
A creation which is a concept; an abstract
creation whose existence and nature are inferred
from one or more expressions or manifestations
concept/
agent
An entity acting in an event or sustaining a
situation; a characteristic active role undertaken
by an entity
role/
67
agreement
An event in which a written or unwritten accord is
made between two or more parties
transaction/
23
alternative
Of a secondary or subsidiary entity in a class
priority>
152
analogue
Of a manifestation whose content is infixed by
physical means
infixion>
134
animal
A living organism which feeds on organic matter,
usually possessing specialised sense-organs and a
nervous system [OED]
being/
animate
Of an entity with the characteristic attributes of
life
vivacity>
136
artefact
A creation which is a thing [derived]
created_thing
406
assertedRelation
A relation about which an assertion is made
input/
735
asserter
An agent making an assertion about the veracity
of something
agent/
444
assertion
An event in which a party makes a claim of
veracity about something
event/
728
associate
A party in an association
patient/
660
association
A situation in which two or more entities are
passively related; a relation based on the verb to
be
situation/
124
attribute
A characteristic of an entity (adapted from ISO
11179); something which an entity has (aka
property)
relation/
audience
A being or group of beings experiencing or
enjoying a percept in one or more modes
user/
120
audio
Of an entity perceived through the sense of
hearing
perceived/
160
audioAndV
Of an entity perceived simultaneously through the
senses of sight and hearing
audio+visual
618
audiovisual
Of a creation whose principal form of
expression is in synchronised sound and pictures
multimedia/
295
being
A percept which has the characteristics of
animate life [derived]; anything which lives and
dies
animate_percept
bici
Book Item and Component Identifier
creation.identifier/
172
bitEncoded
Of a manifestation whose content is infixed by
digital means
infixion>
135
carrier
A physical format.
physical_format
102
catalogNo
An identifier given to an entity in a
disseminator's catalog
identifier/
620
colour
A visual attribute of an entity resulting from the
separation and combination of particular
visual_expression.
form/
isual
WP1a-006-2.0
41
106
16
9
5
36
June 2000
Metadata framework: principles, model and basic dictionary
wavelengths of light
compilation
A creation made from two or more pre-existing
creations of other types
compiled_creation
compiled
Of an entity made by a compiler
created/
compiler
A party contributing to the making of an
compilation, in whole or in part
compilation.contri
butor; user/
complete
see finished
completion
The status of a creation in the course of the
creative process
form/
485
component
A creation which is part of another creation
input/
89
composition
An abstraction normally expressed in musical
sounds, with or without words [derived]
musical_abstracti
on
309
conceived
see abstract
conceived_entity
3
concept
An entity which cannot be perceived directly
through the mode of one of the five senses
[derived]; an abstract entity, a notion or idea; an
abstract noun; an unobservable proposition which
exists independently of time and space
conceived_entity
3
consenter
A party to a concluded agreement
party/
732
context
An entity within which an event took place or a
situation exists (typically, time or place)
role/
116
continuity
The nature of dynamism of an entity over time
form/
39
contributor
A party contributing to the making of something,
in whole or in part
party/
69
controlledCreation
A creation in which intellectualPropertyRights
exist
input/
733
count
A number measuring the occurrence of an entity
quantity/
created
Of an entity made by a contributor
originated>
creatingEvent
An event which results in the making of a
creation
event/
19
creation
The output of creative activity
created_entity
94
creator
A party contributing to the making of an original
creation, in whole or in part
(original_creation
).contributor
70
description
A string giving a verbal representation or account
of an entity or some aspect of an entity
text/
30
digital
Of a percept made of digital bits
substance>
dimension
A number measuring some spatial aspect of an
entity
spatial_quantity
50
director
A contributor directing the activity of others in
the making of a creation
contributor/
76
disseminatedEntity
An entity made available by a disseminator
patient/
196
disseminatingEven
t
An event in which a result is the dissemination of
an entity
event/
226
disseminator
A party making an entity available to potential
users
user/
81
doi
Digital Object Identifier
creation.identifier/
174
draft
Of a creation disseminated in a not yet finalised
form
completion>
486
WP1a-006-2.0
42
99
212
73
61
210
133
June 2000
Metadata framework: principles, model and basic dictionary
duration
A number measuring the time quantity for which
something extends.
temporal_quantity
dynamic
Of an entity whose form and/or content is
perceived or conceived as changing in some way
over time
continuity>
138
ean13
European Article Number
artefact.identifier/
175
element
An item of metadata (aka metadataElement)
entity/
491
encoding
see infixion
ensemble
A group of creators
organization/
596
entity
Something which is identified
concept/
1
evaluation
A number measuring the worth of an entity
quantity/
64
event
A dynamic relation involving two or more
entities [derived]; something that happens; a
relation through which an attribute of an entity is
changed, added or removed
dynamic_relation
7
excerpt
A creation which is made by taking a part from a
pre-existing creation
excerpted_creatio
n
95
excerpted
Of an entity made by an excerpter
created/
excerpter
A party contributing to the making of an excerpt,
in whole or in part
excerpt.contributo
r; user/
expression
An event which is a creation
event/
facilitator
A contributor providing support services to other
contributors
contributor/
false
Not true
veracity>
727
finished
Of a creation disseminated in a finalised form
(aka complete)
completion>
487
forbidden
see prohibited
force
A number measuring the power exerted on an
entity
form
see quality
format
57
211
72
105
80
quantity/
59
An artefact on which an expression may be
infixed to create a manifestation
artefact/
32
genre
A style or manner of the expression of an
abstraction, normally combining elements of both
quality and subject
expression.form/
34
grantee
A party to whom rights are transferred to in an
iprTransfer
party/
731
granter
A party tranferring rights to another in an
iprTransfer
party/
730
gustatory
Of an entity perceived through the sense of taste
perceived/
161
humanBeing
A man or woman of the species homo sapiens
[OED]
being/
17
identifier
A unique label allocated to an entity within a
given namespace
unique_label
26
iid
A unique identifier allocated to an element of
metadata within the <indecs> framework (aka
indecs-id)
identifier/
227
inanimate
Of an entity without the characteristic attributes
vivacity>
137
WP1a-006-2.0
43
June 2000
Metadata framework: principles, model and basic dictionary
of life
indecs-id
see iid
infixion
The means of representation or fixing in which an
expression of an abstraction is established in or
on a manifestation (aka encoding)
manifestation.for
m/
33
input
A pre-existing entity which participates in a
relation in a passive, qualifying or supportive role
role/
87
intellectual
Property
An entity defined by law or international
convention to be intellectual property
legalConcept/
204
intellectual
PropertyRight
The authority granted by law or international
convention to do or to authorise another person to
do a defined act to intellectual property
legalConcept/
208
iprStatement
A situation in which one or more parties
possesses ipr
possessingSituatio
n/
218
iprTransfer
A event in which an ipr is transferred by an
agreement
transaction/
500
isan
International Standard Audiovisual Number; draft
ISO standard identifier for audiovisual
abstractions
abstraction.identif
ier/
176
isbn
International Standard Book Number; ISO
standard identifier for books
manifestation.iden
tifier/
177
ismn
International Standard Music Number; ISO
standard identifier for printed music
manifestation.iden
tifier/
178
isrc
International Standard Recording Code; ISO
standard identifier for audio and video
recordings
expression.identifi
er/
180
issn
International Standard Serial Number; ISO
standard identifier for serial publications
serial.identifier/
179
iswc
International Standard Musical Work Code; draft
ISO standard identifier for compositions
composition.ident
ifier/
181
item
A single instance of an artefact
artefact/
98
label
A string whose function is to distinguish one
entity from another
attribute/
11
language
A particular form of verbal or symbolic
expression of an abstraction
verbal_expression
.form/
35
legalConcept
A concept defined by law, statute or international
convention
concept/
127
lexical
Of a creation whose principal form of
expression is in words
genre>
288
mandatory
see required
manifestation
An artefact containing an infixion of an
expression
artefact/
101
material
An unbounded thing used directly by a
contributor
input/
metadataElement
see element
mode
A sensory mode or modes through which an entity
may be perceived
WP1a-006-2.0
91
491
44
form/
46
June 2000
Metadata framework: principles, model and basic dictionary
modification
A creation made by changing a pre-existing
creation of the same type
modified_creation
modified
Of an entity made by a modifier
created/
modifier
A party contributing to the making of a
modification, in whole or in part
modification.contr
ibutor; user/
multimedia
Of a creation whose principal form of
expression combines two or more other genres
genre>
294
multimodal
Of an entity perceived through two or more
senses
perceived/
389
musical
Of a creation whose principal form of
expression is in musical sounds or notation
genre>
282
name
A string by which an entity is known; what an
entity is called; a label which is not necessarily
unique within a given namespace
nonUnique_label
narrative
Of a creation containing elements of narrative plot
and theme
genre>
504
natural
Of an entity occurring in the natural world without
direct or indirect human intervention
originated>
216
nonUnique
Of an entity of which there can be more than one
singularity>
298
obligation
The extent to which an entity is required
form/
201
offer
An event in which a party makes known the terms
on which an agreement may be made
transaction/
24
olfactory
Of an entity perceived through the sense of smell
perceived/
163
operator
A contributor operating equipment to create
content in a creation
contributor/
78
optional
see permitted
organization
A group of human beings (whether legally
incorporated or not)
group_party
615
original
Of an entity made by an originalCreator
created/
214
originalCreation
A creation without a source input
original_creation
origination
The process by which a creation is made
form/
other
see alternative
output
An entity created or changed through an event
patient/
93
party
An agent undertaking an activity or task in a
creative or commercial relation
agent/
68
patient
An entity which is the object of the act in an
event, or is possessed or associated in a situation;
input/
86
payment
An event in which a party gives money to another
party
transaction/
25
perceived
Of an entity perceived through one or more of the
five senses
mode>
percept
An entity which is perceived directly with at least
one of the five senses [derived];
perceived_entity
performer
A contributor performing or interpreting an
abstraction in an expression
contributor/
permission
A relation which is allowed by an agreement
permitted_relation
/
WP1a-006-2.0
45
97
213
71
29
96
209
191
2
77
110
June 2000
Metadata framework: principles, model and basic dictionary
permitted
Of an entity (typically an event) which is allowed;
something that may happen (aka optional)
obligation>
202
person
An entity possessing the capacity in law to
exercise or enjoy an intellectual property right
legalConcept/
205
physical
Of a percept made of a tangible substance
substance>
132
pictorial
Of a creation whose principal form of
expression is in pictures or symbols
genre>
283
pii
Publisher Item Identifier; an identifier for texts
abstraction.identif
ier/
183
place
A location in space in which a relation applies
context/
117
plane
The dimension or dimensions in which an entity
is perceived
form/
47
plant
A living organism of the species Plantae, usually
containing chlorophyll enabling it to live wholly
on inorganic substances and lacking specialised
sense organs and the power of voluntary
movement [OED]
being/
18
plural
Of an entity of which there is more than one
singularity>
299
possessingSituation
A situation in which an entity is owned or kept by
another entity; a relation based on the verb to have.
possessing_situati
on
403
possession
An entity retained by a possessor
patient/
197
possessor
A party retaining possession of an entity in a
situation
party/
possible
Possibly true
veracity>
724
primary
see principal
principal
Of a dominant or prevailing entity in a class
priority>
151
priority
The position of an entity within a class or group
form/
probable
Likely to be true
veracity>
producer
A contributor responsible for the realisation of a
creation
contributor/
75
prohibited
Of an entity (typically an event) which is
forbidden; something that must not happen (aka
forbidden)
obligation>
497
prohibition
A relation which is forbidden by an agreement
prohibited_relatio
n/
496
property
see attribute
quality
A characteristic of the structure or nature of an
entity; an intrinsic characteristic (aka form)
attribute/
13
quantity
A number measuring some aspect of an entity
attribute/
12
rate
A number measuring the quantity of one entity in
relation to a quantity of another (aka ratio)
quantity/
62
ratio
see rate
recipient
A party to whom an entity is disseminated
user/
recorder
A contributor recording an event in the making
of a creation
contributor/
relation
The interaction of percepts and/or concepts; a
connection between two or more entities
entity/
replica
An item made by copying another item
manifestation/
WP1a-006-2.0
46
84
44
725
512
79
4
448
June 2000
Metadata framework: principles, model and basic dictionary
replicated
Of an entity made by a replicator
created/
replicator
A party contributing to the making of a replica, in
whole or in part
replica.contributor
; user/
required
Of an entity (typically an event) which is
demanded; something that must happen (aka
mandatory)
obligation>
203
requirement
A relation which is necessitated by an agreement
required_relation/
113
role
A part played or function fulfilled by an entity in
relation to another entity or entities; a
classification of an entity in terms of its external
relations; an extrinsic classification
attribute/
14
secondary
see alternative
sequence
A position of an entity in relation to other similar
entities within the same relation
context/
119
sici
Serial Item and Contribution Identifier; a NISO
standard identifier for components of serials
creation.identifier/
185
singularity
The status of an entity in terms of its uniqueness
or otherwise
form/
296
situation
A static relation involving two or more entities
[derived]; something that continues to be the case;
a relation in which the attributes of entities
remain unchanged
static_relation
sourceCreation
A creation from which another creation is wholly
or partly made; a creation which is the basis for
another
input/
88
spatial
Of an entity that is perceived in space
plane>
192
static
Of an entity whose form and/or content is
perceived or conceived as constant
continuity>
139
subject
An entity described or otherwise significantly
covered by the contents of a creation; what a
creation is about
input/
92
substance
The form of the material of which an entity is
made
form/
37
tangible
Of an entity perceived through the sense of touch
perceived/
164
temporal
Of an entity that is perceived in time
plane>
200
text
An abstraction normally expressed in words
[derived]
lexical_abstractio
n
308
textual
Of a creation whose principal form of
expression is in written words [derived]
visual_lexical
289
thing
A percept without the characteristics of animate
life [derived]
inanimate_percept
time
A point or period in time during which a relation
applies
context/
118
title
A name by which a creation is known [derived]
creation.name
303
tool
A bounded thing used directly by a contributor
input/
90
transaction
An event determining or recording the use or
possible use of an entity
event/
22
transferredRight
A right which is the subject of an iprTransfer
input/
734
transforming
An event which results in the making of a new
event/
20
WP1a-006-2.0
47
215
74
8
6
June 2000
Metadata framework: principles, model and basic dictionary
Event
creation including elements of at least one
existing creation; an event in which creations are
both used and made
true
In accordance with fact or reality [OED]
veracity>
726
type
A categorisation of one or more characteristics of
an entity through which it belongs to a group of
entities
attribute/
15
umid
Universal Media Identifier; an SMPTE standard
identifier for digital content
creation.identifier/
186
unique
Of an entity of which there is and can be only one
singularity>
297
upc
Universal Product Code
artefact.identifier/
187
uri
Uniform Resource Identifier
identifier/
190
url
Uniform Resource Locater
place.identifier/
188
usedEntity
An entity made use of by a user
patient/
195
user
A party making use of an entity for any purpose
party/
82
usingEvent
An event in which a result is the use of an entity
event/
21
value
An instance of an attribute [from ISO 11179-3]
concept/
10
veracity
The level of confidence placed in an assertion by
the asserter
form/
723
verbal
Of a creation whose principal form of
expression is in spoken words [derived]
audio_lexical
281
visual
Of an entity perceived through the sense of sight
perceived/
162
vivacity
The nature of an entity in terms of its being, or
having been, alive
form/
1
<indecs> project website: www.indecs.org
2
http://www.cs.cornell.edu/cdlrg/harmony/ABC/abc-results.htm
3
http://www.cidoc.icom.org/home
4
http://purl.org.dc
38
5
Information about DCMS has not yet been made public. For information about IFPI metadata initiative(s), contact
Philippa Morrell, Metadata Executive, IFPI (International Federation of the Phonographic Industry).
http://www.ifpi.org
6
http://purl.org/dc
7
http://www.editeur.org
8
http://www.ifla.org/VII/s13/frbr/frbr.pdf
9
http://www.imsproject.org/index.html
10
http://www.doi.org
11
http://ltsc.ieee.org/wg12
12
http://www.cselt.it/mpeg/standards/mpeg-7/mpeg-7.htm
13
http://www.cselt.it/mpeg/standards/mpeg-21/mpeg-21.htm
14
For information about the P/META initiative, contact Carol Owens, [email protected].
15
http://www.smpte.org/
16
http://www.indecs.org/results/persons.htm
17
http://www.indecs.org/results/persons.htm
WP1a-006-2.0
48
June 2000
Metadata framework: principles, model and basic dictionary
18
“An Event-Aware Model for Metadata Interoperability”
http:/www.cs.cornell.edu/lagoze/papers/harmonyecdl2000.ps
19
There is of course no completely independent primary definition in the schema, as all definition is ultimately circular.
This circularity is encapsulated at a single point in the <indecs> dictionary hierarchies by the appearance of the basic
term entity both as a subtype of concept and as its supertype.
WP1a-006-2.0
49
June 2000