CA2359688A1 - Broadcast media metadata structure - Google Patents

Abstract

A broadcast media metadata structure is comprised of a number of metadata storage entities related to the media materials, concepts and services defined by the structure. The entities contain a number of storage elements which store metadata relating to a given storage level, and relate to attributes or characteristics of the entity, the storage levels are arrranged in a number of mutually consistent hierarchical or non-hierarchical relationships with the storage level at each level above the lowest level relating to the metadata of the immediately lower level. A number of levels of business entities each have business elements related to business metadata. The business elements are linked to the media metadata stores at a storage level appropriate to the business metadata.

Description

BROADCAST MEDIA METADATA STRUCTURE
FIELD OF THE INVENTION
This invention relates to methods and systems for storing and exchanging metadata, or data about data, between systems. It is particularly, but not exclusively, concerned with the storage and exchange of metadata associated with media materials, concepts.and services within the context of media production and distribution, and its future evolution.
BACKGROUND TO THE INVENTION
1o The changes brought about in the broadcasting industry by the move to digital technology in all aspects of media production and distribution has exposed significant short-comings in traditional and existing methods and systems.
The proliferation of distribution channels, using both push and pull technologies, has led to an increased demand for media content which cannot be serviced economically through original production alone but relies heavily on re-use.
Information is the key to un-locking the re-use value of material, yet the industry has no agreed approach to generating and structuring this crucial data, or metadata, to enable efficient exchange of material between process stages or business parties.
The move away from analogue or physical media capture and storage formats towards digital video, audio, text, stills, graphics and software has created new problems in terms of identifying and managing materials and tracking copyright intellectual properties across multiple incompatible and non-interoperating formats and systems. A video tape, in a box with a label, is a physical object which is managed through well-understood logistical methods. When the video information is transferred as digits into an Information Technology repository such as a server, it cannot be distinguished from any other data, whether media or business data.
Such data is not self-identifying; it requires additional metadata to give it meaning, context and value, and that information must be available at any stage during the media production and distribution lifecycle. The lack of common description and management protocols in computer-based systems and among users in the Media domain has already led to loss of material, errors in retrieval and distribution, 1o and accidental copyright infringement.
The emerging capability of digital media formats to support embedded metadata offers an opportunity to attach business information to the audio or video for example, but if there are no standards for generation and exchange of metadata, serious inefficiencies will proliferate and solutions will be hard to find. In addition, early industry thinking about metadata development reflected a view that all metadata might have to be encoded on every section of media however small, such as a video frame or equivalent increment. Thus 2o the business and technical metadata volumes could easily dwarf the media item, making huge demands on storage and slowing down access time, making metadata systems unviable.
At a time when information accuracy and accessibility, and business agility are increasingly vital for the media industry, the new converging technologies are causing fragmentation, data loss, and over-loading on labour-intensive human "fixes". This chaos is exacerbated by the proprietary approaches taken by individual equipment vendors, all with different systems supporting only partial 3o solutions.
Although there are some industrial initiatives underway to stimulate a more open approach, what has been lacking to date has been an overall understanding of the requirements.

The starting point must be an architectural framework which defines the way in which all the information needed to support media production and distribution in the digital domain (while not excluding analogue technology) can be effectively structured and exchanges between process stages and business parties, and linked the with media to which it relates . Inter-operable systems can then be built to support that architecture, and.metadata can be managed efficiently in terms of storage and transfer.
SUMMARY OF THE INVENTION
The invention, therefore, aims to provide such an architecture. According to the invention there is provided a method for defining a metadata structure relating to media materials, concepts and services, the method comprising the steps of: defining a plurality of storage entities at a plurality of levels for metadata relating to media materials, concepts and services, the storage entities having a plurality of storage elements and being related with a media metadata subject grouping, and arranged in 2o hierarchical and non-hierarchical relationships allowing an appropriate combination of elements as required; storing metadata relating to a given storage entity in one of a plurality of storage elements of the entity at that level, each storage element representing an attribute or characteristic of the entity subject or media material;
arranging media metadata entities and attributes relating directly to the media material, concepts and services in hierarchical and non-hierarchical entity level relationships allowing an appropriate combination of elements are 3o required; and wherein for hierarchical entities, the storage elements of storage entities at a level apart from the lowest level, comprise the storage elements of the immediately lower storage level.
The invention further provides a data structure for defining broadcast media metadata comprising: a plurality of storage entities for metadata relating to media materials, concepts and services, the entities being arranged in storage levels and each entity comprising a plurality of storage elements each for storing metadata relating to a given entity, each storage element representing an attribute or characteristic of the entity subject or the media material; wherein the storage levels are hierarchical and non-hierarchical allowing the appropriate combination of elements as required, where the levels are hierarchical, the storage 1o elements of storage entities, apart from the lowest level, comprise the stores of the immediately lower storage level.
The invention still further provides a data structure for defining media metadata comprising: a plurality of storage entities for metadata relating to media production and distribution, the entities being arranged at storage levels and each entity comprising a plurality of storage elements each holding metadata relating to a given entity level, each storage element representing an attribute or characteristic of the entity subject or the media material; a plurality of levels of business entities each comprising storage elements storing business metadata, the business entities being linked to the metadata stores at a storage level dependent on the business element metadata, one of the plurality of levels of business stores comprising a rights level and having one or more storage entities containing business metadata identifying legal rights attached to the media material, the business metadata including the legal jurisdiction of the right, the geographical territory of the right, the duration of the right and the owner of the right;
3o wherein the metadata storage levels are hierarchical and non-hierarchical and, for hierarchical storage levels, the metadata stored in the storage elements of storage entities at a level, apart from the lowest level comprise the stores of the immediately lower storage level.

The invention also provides a data structure for defining media metadata comprising: a plurality of storage entities for metadata relating to media production and distribution, the entities being arranged at storage levels and each entity comprising a plurality of storage elements each holding metadata relating to a given entity level, each storage element representing an attribute or characteristic of the entity subject or the media material; a rights store linked to at least one of the metadata stores and comprising one or more storage entities containing business metadata identifying legal rights attached to the media material, the business metadata including the legal jurisdiction of the right, the geographical territory of the right, the duration of the right and the owner of the right; wherein the metadata storage levels are hierarchical and non-hierarchical and, for hierarchical storage levels, the metadata stored in the storage elements of storage entities at a level, apart from the lowest level, comprise the stores of the immediately lower storage level.
A method embodying the invention may define a metadata structure relating to media material, concepts and services, which in turn provides a method for defining storage and exchange requirements.
The method comprises of the steps of defining a plurality of storage entities for metadata related to media production and distribution, the entities being associated with a media metadata subject grouping, and arranged in hierarchical and non-hierarchical relationships. Metadata relating to a given 3o storage entity is organised in one of a plurality of storage elements at that level, each element representing an attribute or characteristic of the entity subject or media material.
Media metadata entities and attributes relating directly to media material, concepts and services are arranged hierarchically and non-hierarchically allowing the appropriate combinations of metadata to be supported. Where storage levels are hierarchical, the storage elements in stores at the lower levels are linked in defined relationships with stores at the higher levels. The result is a structure for defining metadata, wherein all individual metadata values may be organised according to the entities and relationships defined.
A data structure embodying the invention may define the 1o business data not directly related to media material but vital for its management and exploitation, by defining a plurality of business entities each comprising business elements storing business data, the business stores being related to the media metadata stores at a level dependent on the business element metadata. One or more of a plurality of entities comprises a rights storage entity or entities containing business metadata identifying legal rights attached to the media material, wherein the relationships with the appropriate media metadata are recorded. Where 2o storage levels are hierarchical, the storage elements in stores at the lower levels are linked in defined relationships with stores at the higher levels.
The invention also provides a method of defining a standard media exchange framework comprising the steps of: storing media metadata by the method defined above; defining industry-specific processes involved in media production and distribution, and defining the flow of data between them.
The metadata defined by the metadata structure may be mapped on to this process flow, in order to define metadata 3o exchange requirements between different process stages and business areas.
A method embodying the invention may define media metadata and related business metadata exchange requirements by using the process flow definitions on to which the storage entities may be mapped, so that the systems requirements at each interface may be identified against a standard structure, providing a framework for systems development and integration. In providing the hierarchical and non-hierarchical structure of storage entities and attributes, the method and data structure serves as a basis for defining standard media metadata exchange requirements between process and business interfaces at an appropriate level of granularity.
1o Embodiments of the invention have the advantage that metadata related to a media item can be stored in a manner which minimises storage space and minimises retrieval time.
A metadata item for a media item need only be stored once and is retrievable at any point in the broadcast media chain. Furthermore, embodiments of the invention allow media exchange formats to be defined which embed certain metadata in the media object, for example into a video frame from where they can be accessed at any point in the broadcast chain.
2o The term media concept referred to herein refers to an idea for a media item such as a television programme or series of programmes independent of its realisation. It is common in the media industry to buy, sell and licence media concepts and as such they may be regarded as intellectual property.
BRIEF DESCRIPTION OF DRAWINGS
Embodiments of the invention will now be described by way of example, and with reference to the accompanying drawings, in which:
Figure la), lb) and lc) show three views of an Entity 3o Relationship Diagram embodying the invention;
Figure 2 is an overall process flow diagram illustrating broadcast media production and distribution;

_ g _ Figure 3 shows in more detail the CREATE TV/RADIO PROGRAMME
process box of figure 2;
Figure 4 shows in more detail the GATHER NEWS process box of figure 2;
Figure 5 shows the RESEARCH EVENT process of figure 4 in more detail;
Figure 6 shows ALLOCATE RESOURCES process of figure 4 in more detail;
Figure 7 shows the CREATE NEWS PROGRAMMES process of figure 1o 2 in more detail;
Figure 8 shows the SELECT PROGRAMME CONTENT process of figure 7 in more detail;
Figure 9 shows the RESEARCH AND CAPTURE process of figure 7 in more detail;
Figure 10 shows the COMMISSION OUTPUT process in more detail;
Figure 11 shows the EVALUATE and SELECT OFFERS process in figure 10 in more detail;
Figure 12 shows the DEVISE OUTLINE SCHEDULE process of 2o figure l0 in more detail;
Figure 13 shows the ACQUIRE PROGRAMME/EVENT RIGHT process of figure 2 in more detail;
Figure 14 shows the SCHEDULE & PROMOTE process of figure 2 in more detail;

_ g -Figure 15 shows the CREATE TRANSMISSION SCHEDULE process of figure 14 in more detail;
Figure 16 shows the PLAN & INITIATE ON-AIR PUBLICITY process of figure 14 in more detail;
Figure 17 shows the PLAY-OUT AND TRANSMIT process of figure 2 in more detail;
Figure 18 shows the PERFORM PLAY-OUT process of figure 17 in more detail;
Figure 19 shows the MANAGE MATERIAL STORE and ARCHIVE
1o process of figure 2 in more detail;
Figure 20 shows the MANAGE INCOMING MATERIAL process of figure 19 in more detail;
Figure 21 shows the RETRIEVE MATERIAL process of figure 19 in more detail;
Figure 22 shows the MANAGE RIGHTS AGENCY process of figure 2 in more detail;
Figure 23 shows the PLAN OUTPUT process of figure 2 in more detail;
Figure 24 shows the UNDERSTAND AUDIENCE & COMPETITORS
2o process of figure 2 in more detail;
Figure 25 shows the MANAGE RESEARCH STATISTICS process of figure 24 in more detail;
Figure 26 shows the HANDLE AUDIENCE FEEDBACK process of figure 24 in more detail;

Figure 27 shows the DEAL WITH AUDIENCE FEEDBACK process of figure 24 in more detail; and Figure 28 shows the PROVIDE RESOURCES TO PROGRAMMES process of figure 2 in more detail.
DESCRIPTION OF BEST MODE
In the entity relationship diagram of figures la) to lc), it is shown how a media material item such as a television programme may be described as an interrelated series of entities . The term media material includes any logical whole to piece of media for distribution. It may, for example, be a news item, a section of video, a series of data or software or audio. In figure la), the central entity is the EDITORIAL
OBJECT VERSION 10 together with its sub-types PROGRAMME
VERSION 11 and ITEM VERSION 12 (it is assumed that these are included whenever the main entity 10 is referred to) . An entity is a logical grouping of data to be stored, retrieved and used. This data is all programme and item metadata as it describes a characteristic or attribute of the PROGRAMME or EDITORIAL OBJECT VERSION. The entity contains a number of 2o data items. Thus, the EDITORIAL OBJECT VERSION entity 10 holds both key and non-key data. The key data for the EDITORIAL OBJECT VERSION entity is the EOV count PK1 and EOC
number PK2 which together make up a unique identifier. The tags PK1 and PK2 show the two parts of the primary key. For data to be allocated a primary key it should be unique in its own right or unique when taken with another data item.
The primary key is the "way-in" to the information contained within the entity. It can be seen from figure la) that all the entities contain key data. Key data is essential to 3o those entities. An entity might only hold key data.
The EDITORIAL OBJECT CONCEPT entity 20 is an example of an entity which holds key metadata which is unique in its own right. Thus, the primary key is simply EOC number PKl.

In EDITORIAL OBJECT VERSION entity 10, the non-key data relates to editorial information about the programme or item, such as the title, working title, synopsis, etc.
Technical information about an EDITORIAL OBJECT VERSION is found through other entities such as EDITORIAL OBJECT
VERSION INST 30 and MEDIA OBJECT INSTANCE 32. The term instance refers to a unique material embodiment of an editorial or media object, whether electronic or physical (eg film), signal stream or file. Different instances can 1o exist of the same object, with different technical attributes.
THE EDITORIAL OBJECT VERSION entity 10 is linked to a number of other entities. As the programme or item is the end product of the creation process, it follows that the vast majority of the other entities will, either directly or indirectly, be linked to the EDITORIAL OBJECT VERSION 10.
The link between entities is a relationship, with the link line showing how the data is related. At the end of the relationship line are two symbols indicating whether the 2o connection is mandatory and whether only one or many connecting entities are to be supported. A particular relationship with only a single symbol indicates an entity being a subtype of another entity.
In the example of figure la), the EDITORIAL OBJECT VERSION
entity 10 is linked to a number of other entities such as the entity EDITORIAL OBJECT CONCEPT 20, the relationship being that the EDITORIAL OBJECT CONCEPT may give rise to a number of EDITORIAL OBJECT VERSIONS. The EDITORIAL OBJECT
VERSION PROGRAMME is linked to the entity SOUND, FORMAT, 3o TYPE, 27, the relationship being "may describe". The EDITORIAL OBJECT VERSION entity 10 is linked to the EDITORIAL OBJECT VERSION INST entity 30 by the relationship "may be instantiated as" . A wide variety of terms may be used to describe relationships between entities and the terms vary from the very specific, such as "is made up of"
to the more vague, such as "has associated".
Many of the entities having relationships with the EDITORIAL
OBJECT VERSION 10 in turn have relationships with other entities some of which have relationships with the EDITORIAL
OBJECT VERSION entity 10. Thus, the EDITORIAL OBJECT CONCEPT
entity 20 has the relationship "may be specified in" with the OFFER LINK EOC entity which in turn has the relationship "may specify" with the OFFER entity 28 which has the 1o relationship "may specify as examples" with the OFFER-LINK EOV EXAMPLE entity 67. That latter entity has the relationship "may be specified as examples in" with the EDITORIAL OBJECT VERSION entity 10.
The entity relationship diagrams of figures 1a)-lc) provide a hierarchical and non-hierarchical breakdown of programme content and metadata through media object instances which point to individual media objects. The structure also allows optimal storage of information by linking information to objects at the logical level. Thus, rights, incorporating 2o contributor rights and/or exploitation rights are linked to programmes and at lower levels, through a contract for a particular role, such as rights owner. Thus it can be seen that not all programme metadata need be stored at a very low level, such as on a video frame, as has previously been proposed. The model sets out the entities required to hold metadata for say, a programme at the optimal level, not, for example, duplicating it across low level details such as video frames.
3o Figures 1a) to 1c) set out the range of metadata hierarchical relationships necessary to support appropriate media metadata structures.
The EDITORIAL_OBJECT VERSION entity 10 may be instantiated in terms of a number of media object instances which represent the physical make up of the item. These are represented by the MEDIA_OBJECT-INSTANCE entity 32. The media object instance is connected to only one of a number of different elements such as shots, audio clip, text, graphics and stills which are determined through the relationship to the entity MEDIA_OBJECT-CONTENT entity 31 to MEDIA OBJECT entity 14 and its associated sub-types. Thus a given media object instance only comprises shots, or stills, etc. Each of these are represented by their own entity.
1o Stored at each level is metadata relating to the media item at that level. These storage elements can then be combined upwards in a hierarchical and non-hierarchical structure with the data stored at each level being appropriate to that level. Thus, a given piece of metadata only needs to be stored once throughout the whole broadcast chain from commissioning of a programme to transmission and exploitation.
In the digital environment, business and technical data become indistinguishable. It is an advantage of the embodiment that business information can be linked to the appropriate level entity. This again reduces the amount of storage required and avoids the need for business information to be embedded in the individual video or audio frames. One example of this is the STORY entity 25 which is linked to the MEDIA OBJECT and EDITORIAL OBJECT entities 14, 10 via link entities. If the previously assumed constraints were followed, this data would have been embedded at the frame level.
The manner in which the model handles rights is itself 3o novel. As can be seen from figure lc, the RIGHT entity 61 has RIG number and COM number as key data, and jurisdiction, start date, end date, and condition as non-key data. The condition data item is included to provide a field for storage of additional information required to define the right over and above the jurisdiction, and other provided for. The RIGHT entity 61 is linked to the TERRITORY
entity 63 through the RIGHT LINK TERRITORY entity 72 along the relationship "is valid in". This allows a series of pre-defined territories for rights management to be specified.
Within an organisation's development local equivalent names would be defined as synonyms for the terms used here, different parts of the broadcasting industry may use different terminology. The data dictionary is therefore a 1o compendium of data items with their definitions (complemented with local synonyms) and provides a basis to all the items a broadcaster needs to know about a media item throughout its life cycle with flexibility to cope with specialised terminology and future developments.
The structure of the data model described has hierarchical and non-hierarchical areas representing different levels of granularity through brand, programme group, programme, item and media objects. The entities are linked by relationships that support the expected connections across sets of 2o metadata necessary to support business functionality. Each of the metadata items in figures 1a) to c) would appear in the data dictionary. Relationships linking data elements to the programme entity provide its CV or Resume.
In figure la), the MEDIA OBJECT entity 14 is shown as having five different sub-types: SHOT entity 15, AUDIO CLIP entity 16, TEXT entity 17, GRAPHIC entity 17 and STILL entity 19.
Each of these sub-type entities contain metadata relating to the subtype. Thus, the AUDIO CLIP entity contains audio metadata, the GRAPHIC entity, graphic metadata etc.
3o Each of the entities may be realised as a storage entity having a series of storage elements.
Each of the entities may be realised as a storage entity having a series of storage elements.

An example of the metadata contained in the entity MEDIA
OBJECT 14 is as follows:
KEY DATA NON-KEY DATA
MOB Identifier (PK1) MOB Title MOB Creation Date MOB Creation Time MOB Description Format Original Format Examples of entries from the data dictionary for some of the entities shown in figures la), b) and c) are as follows:
AUDIO CLIP (16) The entity represents an editorial description of a section of continuous/discrete sound from a defined viewpoint. The 1o sound may be being planned to be captured, edited, or transmitted.
BRAND (22) The name applied to a collection of assets which could include a series of programmes. The assets could cover programmes, books, videos, characters, magazines, toys etc.
A brand can be defined at a high level as BBC Sport or as a sub-Brand as Grandstand.
BRIEF (41) The document used by a Commissioning Editor to describe the 2o programme or programmes required for publication.
Also known as Commissioning Brief.
GENRE ( 3 9 ) A domain-specific conceptual grouping of programmes, e.g.
comedy, drama etc. It is because genres are domain specific that a single programme concept may be described in terms of multiple genres.
PROGRAMME CLASSIFICATION (29) Used to describe the functional type of programme, for example ordinary scheduled programme, trail, time signal, outlet ident.
PROGRAr~IE GROUP ( 21 ) 1o A grouping of programmes with shared identification and branding linked by common character, subject matter, style or story. Could be a series, serial or themed grouping. A
fiction series (drama or comedy) will have common characters, themes and/or style between episodes, but individual stories. A fictional series will have a common story running across all episodes, with part being told in each. A factual series may have either individual or shared stories/arguments, such as a history series. A series may be occasional or regular in its transmission pattern - a serial 2o will always have a prescribed transmission pattern and order. A themed group may draw together programme versions based around a campaign or anniversary.
PROGRAMME TYPE (24) Programme Type is the category of programme type taken from a standardised list for transmission to the consumer.
Commonly used in RDS delivery, DAB delivery and MPEG-2 delivery. Programme types include News, Sport, Traffic Information, Pop, Classical, with further sub-categorisation. Also used for EPGs.
PUBLICATION EVENT (42) This is the window of availability for a consumer to view or listen to a version of a Programme.

RIGHT (61) An interest, or permission, which is recognised and protected by law. This entity records the detail of each right which has been acquired for exploitation purposes.
SHOT (15) The entity provides the editorial description for a continuous section of moving images from a defined viewpoint, such as video or film. The section may be planned, captured, created from other recorded images or to transmitted.
STILL (19) An editorial description of an image with no duration , but persistence e.g. a photo, or single frame extracted from a shot. The description may apply to a still image that is planned to be taken, captured, edited or transmitted.
SUBJECT REFERENCE (43) This reference applies to the subject of the material (compared with, for example, the contributors or the action location) and is a "tag" by which a user may retrieve the material.
TEXT (17) The entity provides an editorial description for a media object that contains alphanumeric content to be included in a presentation e.g. captions, website text, teletext.
To assist in understanding how the data model operates it is helpful to consider a media object such as footage of wildlife. At the MEDIA OBJECT entity level information about this footage is stored such as the identifier, its 3o name, creation date etc as shown in figure 1(a). A simple object represents a continuous stream of action. Media objects may only exist conceptually, that is they may not have been captured. When an object is captured the data held at the level of the MEDIA OBJECT entity is complemented by technical information about the digital representation of the action stored in the MEDIA OBJECT CONTENT and MEDIA
OBJECT INSTANCE entities 31 and 32. The combination of simple objects to become footage, or to become a compound media object is represented in the MOI SEGMENT USAGE entity Zo 33, the complementary information about any processing applied being stored in the TRANSFORM and TRANSITION entity 38.
The audio clip used, for example in the signature tune for one of the programmes may have rights attached to it and may have been used for other programmes.
Prior to the present invention it was an assumed constraint that all the data represented by the footage would either be to store all of it for each frame of each shot or for it to be largely lost or stored in many places simultaneously.
2o The first of these results in vast storage requirements and the second also has large storage overheads as well as being undesirable. The data model represented by figures la) to c) requires each metadata item to be stored only once and the hierarchical and non-hierarchical relationships between the storage objects means that all the information can be retrieved as required. Thus at the programme level one can access all the shot information and at the shot level one can access all the programme information for which that shot has been used. Given the shot data, one can move up the hierarchy through the MEDIA OBJECT, CONTENT, MEDIA OBJECT
INSTANCE, EDITORIAL OBJECT VERSION INST and PUBLICATION
EVENT entities 31-32 to find out when and in what form the shot has been broadcast.

The data model gives a representation of the data required by media business processes. The actual processes can be represented by process flow diagrams. Process flow diagrams consist of process, data flows, data stores, and external entities and illustrate the process involved in the broadcast media production chain. In a process box, the action is linked with nouns to describe the process. The diagram does not show how many times the process is executed or any conditions that may prevent the process from being 1o executed. However, the process must be triggered by a data flow. A data flow carries data in a packet into and out of processes and must change the data in some way. The data on the data flow is broken down into data structures and data items/elements. Data may flow to and from an external entity which is a source or recipient of data.
An external entity is a person, role organisation or body that is outside the area represented by the process flow diagram and not necessarily to the organisation as a whole.
A data store is a repository (possible temporary) of data.
2o Everything in it should be retrieved and used by a process somewhere and data stored must be placed there by a process.
Figure 2 shows the content creation and distribution process flow diagram for a broadcasting organisation. Figures 3 - 28 show process flow diagrams for each of the processes illustrated in figure 2.
Thus the content creation and distribution process is broken down into twelve processes. Each of these processes are in turn broken down into a number of sub-processes. Central to this is CREATE TV/RADIO PROGRAMME 72 which has data flows 3o from sources 74, 76 which represent an external archive and a contributor. The data flow from the archive 74 represents information and footage. Data flows both from and to the contributor, the flow into the contributor being contractual and the flow from the contributor being availability. There is further flow of data to an external entity 77 representing billing to broadcasting data services.
The process 72 has a data flow between the process PROVIDE
RESOURCES to PROGRAMMES 78, the flow from the CREATE
TV/RADIO PROGRAMME process 72 representing bookings and demand forecast and the flow to the process representing resources, equipment, studios and quotes.
The process CREATE TV/RADIO PROGRAMME 72 has data flow to the process COMMISSION OUTPUT 82 with data representing offers flowing from the CREATE TV/RADIO PROGRAMME 72 process to the commission output process and data representing commissioning brief, and offer response flowing to the CREATE TV/RADIO PROGRAMME process. Data included in production contract will flow both ways. The CREATE TV/RADIO
PROGRAMME process 72 will exchange data with the PLAY-OUT
and TRANSMIT process 84 with the flow of data to PLAY-OUT
and TRANSMIT process 84 representing programme feed and the data flow to the CREATE TV/RADIO PROGRAMME 72 representing a confirmed transmission. The data will flow from the CREATE
2o TV/RADIO PROGRAMME process 72 to the process SCHEDULE and PROMOTE 86. That flow represents promotional material and presentation details.
Data is exchanged between the CREATE TV/RADIO PROGRAMME 72 process and the MANAGE MATERIAL STORE & ARCHIVE process 90.
The data flow from the CREATE TV/RADIO PROGRAMME process represents pre-recorded programme tape, enquiries, rushes and documents together with transmitted programmes. The flow from the archive process 90 represents information and footage. Finally, there is a flow of data from the process ACQUIRE PROGRAMME EVENT RIGHT 92 to the CREATE TV/RADIO
PROGRAMME process which represents an insert of programme or broadcast right.

The CREATE TV/RADIO PROGRAMME process 72 is illustrated in more detail in figure 3.
The CREATE TV/RADIO PROGRAMME process 72 may be broken down into 6 sub-processes as follows: RESEARCH AND SUBMIT OFFER
196; PLAN PROGRAMME 198; PREPARE AND RESEARCH 200; CAPTURE
MATERIAL 202; MANIPULATE MATERIAL 204; and DELIVER
PROGRAMME.
As can be seen from figure 3, these processes involve the flow of data to and from 3 stores : PROGRAMME CONTENT
l0 207; PROGRAMME INFORMATION 210; and PRODUCTION SCHEDULE 212.
Figure 2 shows a STORE 100 which represents the programming schedule. Data flows from the SCHEDULE STORE 100 to the SCHEDULE & PROMOTE PROCESS 86 representing MASTER SCHEDULE
data. MASTER SCHEDULE data also flows from the commission output process to the SCHEDULE STORE 100. Data also flows to the SCHEDULE STORE 100 from the SCHEDULE & PROMOTE process 86 representing trail details and confirmed timings and from the play-out and transmit process 84 representing actual start and finish times.
The PROVIDE RESOURCES TO PROGRAMMES process is shown in more detail in figure 28. The process is broken down into six sub-processes: PROVIDE QUOTES & TAKE BOOKINGS 212; SET UP, MONITOR AND MANAGE JOB 214; PROVIDE RESOURCES 216; MANAGE
PROJECT FINANCES 218; ESTABLISH COST OF PRODUCTS AND
SERVICES 220; and FORECAST DEMANDS OF PRODUCTS AND SERVICES
222.
These sub-processes draw information from and send data to three stores; SCHEDULE & COSTING INFORMATION 224, PROJECT
PLAN AND DOCUMENTATION 226 and EXPERIENCE LIBRARY 226.
3o News within the organisation is represented by 2 processes;
CREATE NEWS PROGRAMMES 88 and GATHER NEWS 94. The GATHER

NEWS process receives data flow from 6 external data sources: NEWS EDITORS 96, REGIONAL NEWS 98, NEWSROOM 102, EXTERNAL NEWS PROVIDERS 104, THE PUBLIC/AGENCIES AND WIRES
106 AND EXTERNAL ARCHIVES 108. The data flow from NEWS
EDITORS 96 represents guidance, from REGIONAL NEWS 98 and the NEWSROOM represents prospects and also from the NEWSROOM
availability, from the EXTERNAL NEWS PROVIDERS 104 represents knowledge of competition, from PUBLIC/AGENCIES
AND WIRE 106 represents prospects and diary events and from 1o EXTERNAL ARCHIVE represents information and footage. Data flow is also received from the MANAGE MATERIAL STORE &
ARCHIVE process 90 representing information and footage.
Data flows from the GATHER NEWS process 94 is to the NEWSROOM 102 representing an assignment, to the EXTERNAL
ARCHIVE 108 representing an enquiry, to the MANAGE MATERIAL
STORE & ARCHIVE 90 also representing an enquiry and to the CREATE NEWS PROGRAMMES process 88 representing a potential news item and an event, outline or story.
The GATHER NEWS process 94 is illustrated in more detail in 2o figures 4-6 and comprises three sub-processes MAINTAIN DAILY
PROSPECTS 110, ALLOCATE RESOURCES 112 and RESEARCH EVENT
114. The RESEARCH EVENT and ALLOCATE RESOURCES processes are illustrated in detail in figures 5 & 6.
The CREATE NEWS PROGRAMMES process 88, in addition to the data flows already described, exchanges data with the EXTERNAL ARCHIVE source 108 by way of enquiries to the archive and information and footage from the archive. Data flow to the MANAGE MATERIAL STORE & ARCHIVE process 90 represents enquiries, rushes and documents, together with 3o pre-recorded programme tape whereas data flow from the MANAGE MATERIAL STORE & ARCHIVE process 90 represents information and footage. Data flow to the SCHEDULE AND
PROMOTE process 86 represents promotional material and presentation details and data flow to the PLAY-OUT and TRANSMIT process 84 represents programme feed.

The CREATE NEWS PROGRAMME process is illustrated in more detail in figures 7-9 and comprises 4 sub-processes: SELECT
PROGRAMME CONTENT 116, RESEARCH & CAPTURE 118, COMPILE
PROGRAMME 120 and EDIT 122. The SELECT PROGRAMME content process is shown in more detail in figure 8 and the RESEARCH
AND CAPTURE process is shown in more detail in figure 10.
The SELECT PROGRAMME CONTENT process is broken down into four sub-processes: FINALISE NEWS ITEMS 228, ALLOCATE ROUGH
TIMINGS 230, ALLOCATE PRODUCTION TEAM 232 and CREATE DRAFT
1o TREATMENT 234. These processes draw a data from a PROSPECTS
store 234. The ALLOCATE PRODUCTION TEAM process also draws on available production staff data from a PRODUCTION ROTA
store 236.
The COMMISSION OUTPUT process 82, as well as the data flows described with the CREATE TV/RADIO PROGRAMME process 72 receives data from a STORE 124 which represents the controllers stock of untransmitted material. Data is also received from an external entity, representing offers from EXTERNAL PRODUCTION BODIES 126. Data flows from the COMMISSION OUTPUT process to the EXTERNAL PRODUCTION BODY
126 in the form of commissioning briefs, offer responses and production contracts. A second external recipient of data is the CORPORATE CENTRE 128 which receives data relevant to actual versus planned quotas. The COMMISSION OUTPUT process 82 also receives data flow from the SCHEDULE STORE 100 and from a process PLAN OUTPUT SERVICE 130. The data from the STORE represents available slots and the data from the plan output service represents strategic output plan. Data in the form of requirements is sent to the SCHEDULE STORE 100. Data 3o flows from the COMMISSION OUTPUT process to an UNDERSTAND
AUDIENCE & COMPETITORS process 132 in the form of information requirements and flows from the UNDERSTAND
AUDIENCE & COMPETITORS to the COMMISSION OUTPUT process in the form of filtered statistics.

The COMMISSION OUTPUT process is shown in more detail in figures 10-12 and comprises four processes: DEVISE OUTLINE
SCHEDULE 134, EVALUATE AND SELECT OFFICERS 136, NEGOTIATE
AND AWARD COMMISSION 138 and CHECK WITH QUOTA TARGETS 140.
The ACQUIRE/PROGRAMME EVENT RIGHT 92 process involves data flow between an external source representing the EVENT RIGHT
HOLDER 142 with the data representing negotiation and contract and also flow of data in from EXTERNAL EVENT
ORGANISERS 144 representing possible events to cover. Data flows to an EXTERNAL SOURCE 146 representing other distributors. Data representing negotiation and contract flows both ways to and from that source and data to that source represents "ancillary rights which could be sold" and from the source represents "potential acquisitions and programme and paperwork information".
The ACQUIRE PROGRAMME/EVENT RIGHT process 92 is illustrated in more detail in figure 13. The process 92 is broken down into five sub-processes: IDENTIFY ACQUISITIONS & EVENTS 238, NEGOTIATE & AGREE CONTRACT 240, SELL ANCILLARY RIGHTS 242, 246. The sub-processes make use of data in the CONTROLLERS
STOCK STORE 124, the SCHEDULE STORE 100 and a RIGHTS STORE
248.
The SCHEDULE AND PROMOTE process 86, in addition to the data flows already described, receives a flow of data from the UNDERSTAND AUDIENCE & COMPETITORS process representing upheld complaints regarding the content of a broadcast and sends data to the BROADCASTING DATA SERVICES SOURCE 77 representing weekly schedules and data to a recipient 3o representing press and public relations 148 regarding off-air publicity and promotions. Data flows from the SCHEDULE
AND PROMOTE process also to the UNDERSTAND AUDIENCE &
COMPETITORS process representing information requirements.
Data also flows to the PLAY-OUT & TRANSMIT process representing on-air publicity and promotions and schedule and continuity script. Data representing a tape list flows to the MANAGE MATERIAL STORE & ARCHIVE process 90.
The SCHEDULE AND PROMOTE process is illustrated in more detail in figures 14-16. The SCHEDULE & PROMOTE process is broken down into three sub-processes: CREATE, TRANSMISSION
SCHEDULE 250, PLAN & INITIATE ON-AIR PUBLICITY 252 AND PLAN
& INITIATE OFF-AIR PUBLICITY 254. Each of these processes relies on data flow to and from the SCHEDULE STORE 100. The 1o CREATE TRANSMISSION SCHEDULE process is shown in more detail in figure 16 and the PLAN & INITIATE ON-AIR PUBLICITY
process is shown in more detail in figure 16.
The PLAY-OUT AND TRANSMIT process 84, in addition to the data flows described already sends information requirements to the UNDERSTAND AUDIENCE & COMPETITORS process 132, transmitted programme data, transmission log and original documents to the MANAGE MATERIAL STORE & ARCHIVE process 90.
Pre-recorded tape information is received from the MANAGE
MATERIAL STORE & ARCHIVE process and completed contract 2o information flows to a MANAGE RIGHTS AGENCY process 150.
Distribution data flows to, and transmission service data flows from an External source/recipient labelled DISTRIBUTION SERVICE PROVIDER 152.
The PLAY-OUT AND TRANSMIT process is illustrated in more detail in figures 17 & 18. The PLAY-OUT & TRANSMIT process comprises 4 sub-processes: PERFORM PLAY-OUT 256, CAPTURE
ACTUAL TRANSMISSION DETAILS 258, INITIATE POST-TRANSMISSION
RIGHTS PAYMENT 260 and PERFORM PROMOS ANALYSIS 262. These processes draw on data from the SCHEDULE 100 and from a 3o store of research statistics 264. The PERFORM PLAY-OUT sub-process is shown in more detail in figure 18.
The MANAGE MATERIAL STORE & ARCHIVE process 90, in addition to the data flows described already receives a data flow from the UNDERSTAND AUDIENCE & COMPETITORS process 132 in the form of request for tapes and sends data to that process in the form of pre-recorded programme tapes. Data flow from two external sources, EXTERNAL ARCHIVE 154 and ARCHIVE
STEERING GROUP 156 represent material and rights flowing from outside the Organisation and strategic direction respectively.
The MANAGE MATERIAL STORE & ARCHIVE process is illustrated in more detail in figures 19-21. The MANAGE MATERIAL STORE
& ARCHIVE process may be broken down into three sub-processes as shown in figure 19. These processes are CREATE
ARCHIVING POLICY 266, MANAGE INCOMING MATERIAL 268 and RETRIEVE MATERIAL 270. The latter two sub-processes draw on data in a MATERIAL STORE & ARCHIVE 272. The MANAGE INCOMING
MATERIAL sub-process is shown in more detail in figure 20 and the RETRIEVE MATERIAL sub-process is shown in more detail in figure 21.
The MANAGE RIGHTS AGENCY process 150 will receive data flow representing Union & Framework Agreements from a source 2o representing Union & Industry Bodies 156 and data will flow to a recipient representing Worldwide product Licences 158.
The MANAGE RIGHTS AGENCY process is illustrated in more detail in figure 22.
The PLAN OUTPUT service process 130 receives data flows from external sources representing the chief executive broadcast 160, the Government 162 and any relevant legislation represented here by the Broadcasting Act 1990, 164. Data also flows from the UNDERSTAND AUDIENCE & COMPETITORS
process in the form of filtered statistics. Data is output 3o to the SCHEDULE 100 in the form of news slots, to the COMMISSION OUTPUT process 82 in the form of strategic output plans and to the CREATE NEWS PROGRAMMES process 88 in the form of guaranteed news output. The plan output service is illustrated in more detail in figure 23.

The UNDERSTAND AUDIENCE & COMPETITORS process gathers information from a variety of external sources such as the Government 162 in the form of broadcasting requirements, for example under a broadcasting charter, from broadcasting industry monitoring services in the form of viewer/listener statistics, quote requests and contracts and other research results, from viewers and listeners in the form of complaints and feedback. Information flows to external sources in the form of published statistics to an annual 1o report, reports and statistics to a given channel controller, responses to viewers and listeners and requests to statistical gathering agencies. The UNDERSTAND AUDIENCE
& COMPETITORS process is illustrated in more detail in figures 24-27. The UNDERSTAND AUDIENCE & COMPETITORS process can be broken down into two sub-processes: MANAGE RESEARCH
STATISTICS 274 and HANDLE AUDIENCE FEEDBACK 276. These sub-processes are shown in more detail in figures 25 & 26 respectively. Figure 26 shows that the HANDLE AUDIENCE
FEEDBACK sub-process can be further sub-divided into two more sub-processes: DEAL WITH AUDIENCE FEEDBACK 278 and INVESTIGATE COMPLAINTS 280. The DEAL WITH AUDIENCE FEEDBACK
sub-process is further illustrated in figure 27.
A combination of the data model of figures 1a) to c) and the PROCESS flow diagram of figure 2 can be used to develop a standard media exchange framework. This sets out the metadata items which must be associated with media material, concepts or services at each level of the entity model and can be used to define the exchange at each process interface.
An example of a possible exchange framework interface is the data which is required to be created by or loaded into a capture device such as a camera. This requires standardisation amongst camera manufacturers. Some of that information might then be imported into the device from a data store before capture, to be embedded with a media material as it is created, then it and new data subsequently exported into an information system for media management purposes, or for access by an editing system for onward processing. Rather than capture the data at the end of a process, data is captured as it happens and is perpetuated.
The media exchange architecture described enables the linking of media materials together with their metadata in a way which enables extremely efficient development, re-use and re-purposing of media in an integrated but distributed 1o device and database.
Application of the data structure described enables systems to be built which will integrate converging requirements of broadcast and media business systems. Systems which are compliant with this structure will be easier to integrate as 1s the data exchange standard will be consistent regardless of the internal storage schemes used. Systems which are compliant in their internal storage schemes will also be optimumly efficient in their use of storage. Specific examples of systems which can be made compliant include 2o media commissioning and scheduling systems, systems to support content production process, broadcast play-out systems, Internet websites, customer feedback capture systems, content asset management systems, intellectual property right systems and archive systems.
25 The data structure is typically implemented in software, for example the data dictionary may be held in a software repository.

Claims (36)

-29-

1. A method for defining a metadata structure relating to media materials, concepts and services, the method comprising the steps of:
defining a plurality of storage entities at a plurality of levels for metadata relating to media materials, concepts and services, the storage entities having a plurality of storage elements and being related with a media metadata subject grouping, and arranged in hierarchical and non-hierarchical relationships allowing an appropriate combination of elements as required;
storing metadata relating to a given storage entity in one of a plurality of storage elements of the entity at that level, each storage element representing an attribute or characteristic of the entity subject or media material;
arranging media metadata entities and attributes relating directly to the media material, concepts and services in hierarchical and non-hierarchical entity level relationships allowing an appropriate combination of elements are required; and wherein for hierarchical entities, the storage elements of storage entities at a level apart from the lowest level, comprise the storage elements of the immediately lower storage level.

2. A method according to claim 1, wherein the storage entities include an editorial object concept entity which may give rise to one or more editorial object version entities, wherein the metadata stored within the editorial object concept entity is related to the editorial object version entity, the version entity comprising the immediately lower storage level.

3. A method according to claim 2, wherein the storage entities include a programme version level and an item version level, the programme version level and the item version level being subtypes of the editorial object version.

4. A method according to claim 3, wherein the storage entities include a media object level, and the programme version and item version entities are related to media object metadata, the media objects comprising the immediate lower level.

5. A method according to claim 4, wherein the media object level includes occurrences of individual media types as sub types.

6. A method according to claim 5, wherein the media object includes an audio level subtype and the storage elements relate to audio metadata.

7. A method according to claim 5, wherein the media object level includes a text level sub-type and the metadata storage elements relate to text metadata.

8. A method according to claim 5, wherein the media object level includes a graphics level subtype and the media object level storage elements relate to graphics metadata.

9. A method according to claim 5, wherein the media object level includes a stills level subtype and the media object level storage elements relate to stills metadata.

10. A method according to claim 1, further comprising storing the entity and attribute definitions as a metadata dictionary, wherein metadata occurrences are defined to be consistent with the metadata dictionary.

11. A method according to Claim 10, wherein the dictionary further includes acceptable synonyms for at least some of the metadata.

12. A method according to claim 1 further comprising defining a plurality of levels of business stores each comprising business elements each relating to business metadata, the business stores being linked to the metadata stores at a storage level dependent on the business element metadata.

13. A method according to claim 12, wherein one of the plurality of levels of business stores comprises a rights level comprising one or more related entities containing business metadata identifying legal rights attached to the media material, the business metadata including the legal jurisdiction of the right, the geographical territory of the right, the duration of the right and the owner of the right.

14. A method according to claim 1 wherein the media material is a radio, television or Internet material or associated or derived product.

15. A method according to claim 1, wherein the storage levels cover the distributed media supply chain extending from service proposition to audience consumption.

16. A method according to claim 1, comprising defining a plurality of mutually consistent hierarchies of storage levels.

17. A method of defining a standard media exchange framework comprising the steps of:
defining a media metadata structure according to the method of claim 1, defining a process flow model reflecting the media production and distribution chain; and defining metadata items for exchange between one process in the media production and distribution chain and another.

18. A data structure for defining broadcast media metadata comprising:
a plurality of storage entities for metadata relating to media materials, concepts and services, the entities being arranged in storage levels and each entity comprising a plurality of storage elements each for storing metadata relating to a given entity, each storage element representing an attribute or characteristic of the entity subject or the media material;
wherein the storage levels are hierarchical and non-hierarchical allowing the appropriate combination of elements as required, where the levels are hierarchical, the storage elements of storage entities, apart from the lowest level, comprise the stores of the immediately lower storage level.

19. A structure according to claim 18, wherein the storage entities include an editorial object concept entity which may give rise to one or more editorial object version entities, wherein the metadata stored within the editorial object concept entity is related to the editorial object version entity, the editorial object version entity comprising the immediately lower storage level.

20. A structure according to claim 19, wherein the storage entities include an item version level and a programme version level, each of the item version level and the programme version level being subtypes of the editorial objection version entity.

21. A structure according to claim 20, wherein the programme version and item version entities relate to media object metadata, the media objects comprising the immediately lower level.

22. A structure according to claim 21, wherein the media object level includes occurrences of individual media types as subtypes.

23. A structure according to claim 22, wherein the media object level includes an audio level subtype and the storage elements relate to audio metadata.

24. A structure according to claim 22, wherein the media object level includes a text level subtype and the storage elements relate to text metadata.

25. A structure according to claim 22, wherein the media object level includes a graphics level and the storage elements relate to graphics metadata.

26. A structure according to claim 22, wherein the media object level includes a stills level and the media object level storage elements relate to stills metadata.

27. A structure according to claim 18, further comprising a metadata dictionary having stored therein entity and attribute definitions, wherein the metadata occurrences are defined to be consistent with the metadata dictionary.

28. A structure according to claim 27, wherein the dictionary further includes acceptable synonyms for at least some of the metadata.

29. A structure according to any of claims 18 to 28 comprising entities relating to editorial requirements and entities relating to instantiation requirements.

30. A structure according to claim 18 further comprising a plurality of levels of business entities each comprising storage elements related to business metadata, the business elements being linked to the media metadata entities at a storage level dependent on the business element metadata.

31. A structure according to claim 30, wherein one of the plurality of levels of business storage elements comprises a rights level and includes one or more entities containing business metadata identifying legal rights attached to the media material, the business metadata including the legal jurisdiction of the right, the geographical territory of the right, the duration of the right and the owner of the right.

32. A structure according to claim 18 wherein the media material is a radio, television or Internet material or associated or derived product.

33. A structure according to claim 18, wherein the storage levels cover the broadcast media supply chain extending from service proposition to audience consumption.

34. A structure according to claim 18, including a plurality of mutually consistent hierarchies of storage levels.

35. A data structure for defining media metadata comprising:
a plurality of storage entities for metadata relating to media production and distribution, the entities being arranged at storage levels and each entity comprising a plurality of storage elements each holding metadata relating to a given entity level, each storage element representing an attribute or characteristic of the entity subject or the media material;
a plurality of levels of business entities each comprising storage elements storing business metadata, the business entities being linked to the metadata stores at a storage level dependent on the business element metadata, one of the plurality of levels of business stores comprising a rights level and having one or more storage entities containing business metadata identifying legal rights attached to the media material, the business metadata including the legal jurisdiction of the right, the geographical territory of the right, the duration of the right and the owner of the right;
wherein the metadata storage levels are hierarchical and non-hierarchical and, for hierarchical storage levels, the metadata stored in the storage elements of storage entities at a level, apart from the lowest level comprise the stores of the immediately lower storage level.

36. A data structure for defining media metadata comprising:
a plurality of storage entities for metadata relating to media production and distribution, the entities being arranged at storage levels and each entity comprising a plurality of storage elements each holding metadata relating to a given entity level, each storage element representing an attribute or characteristic of the entity subject or the media material;
a rights store linked to at least one of the metadata stores and comprising one or more storage entities containing business metadata identifying legal rights attached to the media material, the business metadata including the legal jurisdiction of the right, the geographical territory of the right, the duration of the right and the owner of the right;
wherein the metadata storage levels are hierarchical and non-hierarchical and, for hierarchical storage levels, the metadata stored in the storage elements of storage entities at a level, apart from the lowest level, comprise the stores of the immediately lower storage level.