123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657

585960616263

ARTICLE IN PRESS

http://france.elsevier.com/direct/CULHER/

Journal of Cultural Heritage ■■ (2006) ■■■

Modele+

Original article

646566

* CorrE-ma1 A tri

1296-20doi:10.1

The digital opera house: an architecture for multimedia databases

6768697071

G. Haus, L.A. Ludovico *

Laboratorio di Informatica Musicale (LIM), Dipartimento di Informatica e Comunicazione, Università degli Studi di Milano, 39, via Comelico, 20135 Milan, Italy

Received 5 October 2005; accepted 20 February 2006

72737475767778798081828384858687

D

PROO

FAbstract

This paper deals with the problem of preserving, organizing and retrieving information for a typical opera house environment. On the onehand, the live fruition of a music work in a theatre is an experience very difficult to be recreated in a different context or handed down toposterity; but, on the other hand, opera houses are important centers for cultural preservation and diffusion, and their work cannot get lostimmediately after performances. The processes in such an environment are very heterogeneous and complex, including not only the economicmanagement and the logistic activities which take place in the offices, but also on-stage artistic production and craft-made activities in work-shops. Probably, these latter activities are the most interesting from the point of view of cultural heritage. This paper provides a classification ofthe heterogeneous data to put in relationship in order to obtain a thorough and effective database. The ultimate purpose is highlighting whichinformation should be captured, structured, and retrieved in order to transform musical performances in cultural heritage for posterity.© 2006 Elsevier SAS. All rights reserved.

Keywords: Music databases; Cultural heritage; Digital knowledge; Information retrieval; Multimedia

888990919293949596979899

100101102103104105106

NCOR

REC

1. Introduction

The ever-growing possibilities and needs to organize infor-mation in large databases have recently involved theatrical en-vironments [2,3]. In the case of theatres and opera houses, da-tabases could be employed not only to store administrative andoperational data, but also to preserve and transmit the artisticactivity itself.

As technology evolves and catches on in the most disparatefields, an increasing number of cultural institutions take intoconsideration the need to control and manage their vast amountof data and digital media assets. Technically speaking, a digitalasset is any form of media that has been converted into a bin-ary source. The term “asset” is used to indicate that such fileshave some sort of intrinsic value that makes it worthwhile tomanage them. Thus, the locution “digital asset management”(or simply DAM) refers to the practice and domain of organiz-ing digital files. DAM is a field related to content management,and often is considered as a superset of this subject.

107108

U

esponding author.il addresses: haus@dico.unimi.it (G. Haus), ludovico@dico.unimi.it (L.Avial example is constituted by the editorial activity to compose evening’s p

74/$ - see front matter © 2006 Elsevier SAS. All rights reserved.016/j.culher.2006.02.007

TE

Our paper deals with the design and implementation of anefficient and effective Digital Asset Management for theatricalenvironments. A well-designed and structured DAM, by pre-serving and organizing information, allows its users to savetime and money. For instance, long times due to researchesinto traditional archives, retrieving the collocation of physicalobjects, composing elaborated document layouts1 are virtuallycancelled.

Before analyzing the subject thoroughly, some wordsshould be spent about the enormous importance of operahouses’ activity from the point of view of cultural heritage.Music, in its various forms and representations, constitutes apatrimony of mankind. Such heterogeneous world is madenot only of chords and rests (scores), but also of sounds andvoices (recordings), of images (photo and video captures), ofcraft-made objects (costumes, accessories, backdrops and stagetools), of men’s work (hairstyle and make-up).

A well-structured database for an opera house is intrinsi-cally different from databases appointed to other purposes. Ma-terials of interest for opera houses include both data and meta-

109110111112113114

. Ludovico).rograms, which include articles, reviews, photographs, paintings and so on.

CULHER-2154

115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171

172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228

ARTICLE IN PRESS

Fig. 1. Hierarchy among base version, staging and evening concepts. In italic,an example about different revivals of the same opera.

G. Haus, L.A. Ludovico / Journal of Cultural Heritage ■■ (2006) ■■■2

UNCO

RREC

data, and data themselves can be extremely heterogeneous. Infact, such databases have to store a number of document types,e.g. text, audio, still images and video; and multimedia con-tents, of course, require a multimedia database. As an immedi-ate consequence, the database itself will need a large amount ofdisk space and a very smart way of managing related informa-tion. In other words, both hardware and software requirementswill be demanding.

In this context, a particular importance is acquired by twoactivities: i) database planning, and ii) related applications de-sign. In fact, even a very powerful calculation system could notbe sufficient to handle the computational burden, in particularwhen data and metadata are not organized in a proper way.Thus, database structuring requires an accurate analysis, andrelated applications to retrieve information should be imple-mented very carefully.

2. Contents of an opera house database

Which kind of information should find place inside the da-tabase of an opera house? As told before, we can roughly con-sider two different categories of information: i) data about thea-tre management (e.g. personal data, salaries, addresses), and ii)data and metadata about its artistic production (e.g. playbills,recordings, photos).

Often, the two different ambits are tightly related: for in-stance, precise information about the presence of an artist in acertain number of performances could be used not only to re-construct the cast of the plays, but also to calculate his/her sal-ary. Many other examples could be cited: the relationshipamong the costs of a particular staging and the run of the play,the availability of recordings to be marketed, and so on.

Only the second category of data and metadata is peculiar ina theatrical environment, so this paper will focus this subject,omitting comments about the organization of a traditional ar-chive of personal data. However, even ignoring one of the twofacets, the matter is still complex and challenging. For exam-ple, the contents to be stored in the database can be very het-erogeneous, ranging from textual information to symbolic re-presentation of music, from still images to video, from audio tophysical objects. A more structured vision of the matter will bepresented in the following sections.

We can individuate three different phases that are consecu-tive and logically interdependent: information capturing, infor-mation structuring, and information retrieval. In this context,we prefer the term “information” to “data” as it can embracealso the concept of metadata. Literally meaning “data aboutdata”, metadata is information that describes another set ofdata. In the paper, we will underline that database entries areconstituted not only by digital objects, but also by some addi-tional information. Metadata are fundamental in order to clas-sify and retrieve such digital objects. Besides, metadata allowone to relate objects to other objects inside the database. As aconsequence, our proposal for an effective database will sup-port both data and metadata.

TEDPR

OOF

3. A night at the opera

The purpose of this section is introducing some importantconcepts typical of theatre’s jargon.

A standard opera house usually runs different kinds ofshow: mainly operas, ballets, symphonic concerts, chamberconcerts, and recitals, but also other initiatives such as lessons,conferences, and presentations.

By adopting the top-down approach shown in Fig. 1, thefirst key concept is the idea of base version, which representsthe music work as conceived by its author(s). This definition ismeaningful for operas, ballets, and concerts, and not for otherkinds of manifestation such as conferences.

Among the data related to base version, we can cite theoriginal title of the composition, the name and the role of itsauthor(s), the date and place of its first representation, and fi-nally the instrumental and vocal ensemble. In this context, theensemble is a mere list of instrumental and vocal parts, oftenwith a quantitative indication. For instance, by examining theoriginal score we learn that S. Prokofiev’s Peter and the Wolf iswritten for flute, oboe, clarinet in A, bassoon, three horns,trumpet, trombone, timpani, triangle, tambourine, cymbals,castanets, snare drum, bass drum, and strings. On the contrary,the cast—intended as the names of the performers—cannot bespecified in the base version. Similarly, for an opera or a balletthe ensemble information includes also the name of the maincharacters, but once again not the personal data about the inter-preters.

The second key concept is the one of staging. By such term,we indicate a set of performances characterized by the samemusic program, belonging to the same season and having com-mon features about production, staging, and cast. Under ourhypotheses, Le nozze di Figaro by W.A. Mozart and L. daPonte represents a “base version”, whereas its production forTeatro alla Scala’s 2005/06 opera season will constitute a “sta-ging”.

It is worthy of noting that stagings—if compared with baseversion—are characterized by a superset of common features.In fact, all the common aspects of a base version are inheritedby stagings, which allows one to put in correspondence differ-ent stagings of the same music work. But choosing a particularstaging makes some other peculiar elements emerge, such asthe same conductor, orchestra, director, stage designer, cos-

229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285

286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334

ARTICLE IN PRESS

G. Haus, L.A. Ludovico / Journal of Cultural Heritage ■■ (2006) ■■■ 3

NCOR

REC

tume designer for all the performances. Among the commonfeatures of a staging, we cannot count the name of the inter-preters (singers, dancers…), as the general rule in opera housesis having two or more casts that alternate on the stage in dif-ferent evenings.

This last consideration brings us to introduce the final keyconcept: the evening, where not only the music program butalso the performers are fixed. An evening represents the imple-mentation of a base version (or many base versions, or even aselection from different base versions), according to a particu-lar staging, in a particular date and place and with a definitecast of performers. According to this interpretation, eveningsare in biunique relationship with fliers or playbills, which arethe single-page leaflets advertising the event.

Thanks to our top-down approach, it is evident that movingfrom base version to evening concepts we are providing moreand more punctual and detailed information, whereas the levelsof abstraction and aggregation lowers: the base version of G.Verdi’s Otello was performed thousands of times at Teatro allaScala, while the 7th December 2001 performance is a singleevening; on the other hand, each Otello evening is character-ized by very detailed information, but all the evenings belong-ing to the same base version share few common features.

A particular situation happens when a performance can besubdivided in a number of blocks, each presenting complete-ness and independence from others; in this case, we can as-sume that each block belongs to a different base version. Atypical example is represented by those vocal recitals wherearias from different operas are sung, as each aria belongs tothe base version of the corresponding opera. This situation,namely many base versions involved in a single evening, canoccurs in composite2 concerts, ballets, and operas.

4. Data capturing

The first step to build the database is capturing the informa-tion of some interest for our purposes. Identifying all the pos-sible types of heterogeneous material is not a trivial process.As Teatro alla Scala experience taught us [5,6], an opera houseis a very rich and complex informative environment, whosematerials and documents include:

● scores and symbolic representations of music;● audio recordings;● video recordings;● fliers, playbills and posters;● photos;● sketches;

U

2 In this context, “composite” means “made of pieces by different authors”or “made of distinct pieces by the same author”. For example, we can definecomposite an evening when G. Puccini’s triptych is performed: the single baseversions are respectively Il tabarro, Suor Angelica, and Gianni Schicchi. Onthe contrary, according to our definition the performance of C. Orff’s CarminaBurana is not composite: even if the work could be subdivided into moreatomic parts (“O Fortuna”, “Fortuna Plango Vulnera”, “Veris Leta Facies”…),the author conceived it as a single scenic cantata.

TEDPR

OOF

● fashion plates;

● costumes and related accessories;

● stage tools and equipment;

● stage maps;

● other textual documents, such as bibliography, discography,libretto, short descriptions and reviews of music works.

This list does not claim completeness, but it is sufficient toillustrate the heterogeneity of data and metadata the databasewill store.

First, the original form of the material often has to be con-verted. Obviously, in a multimedia database only digital ob-jects and data can be entered. Some contents from the afore-mentioned list are already digital encodings: for instance,digital photos, digital recordings, and computer-edited texts.Besides, some contents undergo an analog-to-digital conver-sion which prevents (or should prevent, under particular con-ditions) informative loss; it is the case of image scanning, ana-log audio and analog video digitalization, typing of digitaldocuments (texts and scores) from a hard copy. Finally, thereare physical objects that can be captured only from certainpoints of view and a limited number of times. In this case,we know that the digital copy does not allow one to catchand appreciate all the facets of the digitalized object. Let uscite the examples of a stage tool or a costume (Fig. 2): manydigital photos can be taken and stored to show their features,but the whole photographic sequence is not sufficient to pro-vide a three-dimensional view of the original object. For phy-sical objects, a virtually exhaustive set of digital descriptions(both textual and visual) should be chosen; but such choicewould represent—in any case—an arbitrary operation whichintroduces informative loss. For instance, three photos of a cos-tume can show its characteristics better than a single shot, aswell as 100 photos give us a far better three-dimensional viewof the subject, but neither 1000 photos can make up for thesensation of touching the costume’s fabric.

5. A proposal for database structuring

335336337338

When designing the database, a problem soon arises: whatare the most appropriate relationships among the aforemen-tioned digital contents listed in Section 4 and the concepts ofbase version, staging and evening listed in Section 3? A possi-ble answer is provided by the entity-relationship diagramshown in Fig. 3. This layout represents just an example amongmany combinations of different constraints and requirements.Some aspects of our proposal—for instance the type of materi-als involved and their relationships—are a direct consequenceof LaScalaDAM project, which took place at Teatro alla Scalaof Milan and was coordinated by our laboratory3.

339340341342

3 LIM (Laboratorio di Informatica Musicale)—DICo (Dipartimento di Infor-matica e Comunicazione), Università degli Studi di Milano—Web site: http://www.lim.dico.unimi.it.

343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399

400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456

ARTICLE IN PRESS

UNCO

RREC

TEDPR

OOFFig. 2. Three photos to capture the same subject: a sword and its sheath.

Fig. 3. The entity-relationship diagram for the proposed multimedia database.

G. Haus, L.A. Ludovico / Journal of Cultural Heritage ■■ (2006) ■■■4

457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513

514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570

ARTICLE IN PRESS

TEDPR

OOF

Fig. 4. An example of “composite” flier: the same playbill describes three evenings.

4 To tell the truth, sometimes the authors annotate precise indications ontheir scores as regards scenery, stage layouts, movements of the artisticmasses.

G. Haus, L.A. Ludovico / Journal of Cultural Heritage ■■ (2006) ■■■ 5

UNCO

RRECLet us briefly comment on some peculiar aspects of our

proposal, that is the result of our most recent efforts and anevolution of [1].

In Fig. 3, the skeleton of database structure is evident: theframework is composed by the three key concepts listed before(namely BaseVersion, Staging, and Evening) together withtheir relationships.

Music score as well as a number of textual documents (e.g.librettos) and data (e.g. authors, title, publication date) can beassociated to the base version. Each sub-entity presents its ownmetadata, and these peculiarities will be considered when im-plementing the database, but from a theoretical point of viewthey all can be grouped under the concept of BaseObject. Someminor problems can arise: for example, various autographicscore versions or different titles for the same work. Fortu-nately, those problems can be easily solved thanks to a 1:Ninstead of a 1:1 relationship.

According to our proposal, sketches, fashion plates, cos-tumes, stage maps and equipment are naturally related not toa base version, but to a staging. In fact, the choice of the stagematerial to use depends on the dictates of the director, of the

costume designer, of the scene painter and so on4. Once again,even if the aforementioned objects are usually related to a par-ticular staging, we cannot ignore common events as stagingrevivals or “contaminations” among different works whoseproduction employs the same equipment. This is the reasonwhy in Fig. 3 the theoretical 1:N cardinality between Stagingand StagingObject entities becomes a M:N relationship. Inother words, our database structure supports the following si-tuations: for a given staging many objects can be used, as wellas the same object can be employed in different productions.

Considering the sub-entities grouped by the concept of Sta-gingObject, two of them present a particular relationship: Cos-tume and Accessory. The latter category includes, for example,jewelry, wigs, and shoes. The relationship cardinality is justi-fied by the following considerations: some costumes don’thave any accessory, or perhaps accessories are stored and clas-

571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627

628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664

ARTICLE IN PRESS

G. Haus, L.A. Ludovico / Journal of Cultural Heritage ■■ (2006) ■■■6

EC

sified together with their costumes; on the contrary, in our opi-nion each accessory must be related to some costume.

By examining Fig. 3, an asymmetry becomes soon evident.BaseVersion is related to BaseObject, as well as Staging isrelated to StagingObject, but Evening is not related to a uniqueEveningObject entity. The reason resides in the different car-dinalities we have to manage for the relationships involvingEvening. In fact, audio and video recordings are necessarilyrelated to one and only one evening; on the contrary, a flieris usually related to a single show, but it can describe alsomany evenings that share the same music program and thesame performers (Fig. 4); finally, photos can be even unrelatedto any evening: this is the case of pictures taken during non-musical events or depicting private moments of artists’ life.

6. Conclusions

An effective and efficient multimedia database presentsmany advantages for opera houses. From the point of view ofthe theatre establishment, it makes management operations andeditorial initiatives much simpler.

However, such database can assume a very important rolealso from the cultural heritage perspective. In fact, thanks tocomputer-based technologies, database contents can be easilytransmitted, both in space and in time dimension.

A digital version of the original material can be handed onfrom generation to generation. In a certain sense, not only dataand metadata, but also physical objects can be transmitted,after ad hoc digitalization campaigns.

Besides, thanks to network technologies, a worldwide ac-cess to database contents can be granted to any authorized user.On-line publication of multimedia contents requires a well-structured interface, containing effective navigation tools andappropriate forms of data aggregation. However, as a resultof this effort, researchers, performers, music students, operafans and simple keens could access such cultural treasure, any-time and anywhere.

TEDPR

OOF

7. Uncited reference

[4].

Acknowledgments

The authors wish to acknowledge the partial support of thisproject by Italian MIUR (FIRB “Web-Minds” project N.RBNE01WEJT_005) and the Italian National Research Coun-cil, in the framework of the research program “Methodologies,techniques, and computer tools for the preservation, the struc-tural organization, and the intelligent query of musical audioarchives stored on heterogeneous magnetic media”, FinalizedProject “Cultural Heritage”, Subproject 3, Topic 3.2, Subtopic3.2.2, Target 3.2.1.

References

[1] E. Ferrari, G. Haus, The Multimedia ORDBMS Architecture of the Musi-cal Archive at Teatro alla Scala, Proc. of the IEEE 1999 Multimedia Con-ference, Firenze.

[2] G. Haus, M.L. Pelegrin, Music processing technologies for rescuing musicarchives at teatro alla Scala and Bolshoi theatre, Journal of New MusicResearch, Swets and Zeilinger, Amsterdam, 2001.

[3] L. Diana, E. Ferrari, E. Haus E., Saving the Multimedia Musical Heritageof Teatro alla Scala for Querying in a Web-Oriented Environment, Proc.of the IEEE 2001 Wedelmusic Conference, Florence, 2001.

[4] G. Haus, in: Rescuing La Scala’s Audio Archives, IEEE Computer, 31(3),IEEE CS Press, Washington, 1998, pp. 88–89.

[5] G. Haus, A. Paccagnini, M.L. Pelegrin, Characterization of Music Ar-chives’ Contents. A Case Study: the Archive at Teatro alla Scala, Attidel XII° Colloquio di Informatica Musicale, AIMI/Università di Udine,Gorizia, 1998.

[6] G. Haus, A. Paccagnini, M.L. Pelegrin, “Characterization of Music Ar-chives’ Contents. A Case Study: the Archive at Teatro alla Scala”, Proc.of the 3rd International Congress on Science and Technology for the Safe-guard of Cultural Heritage in the Mediterranean Basin, Alcalà de Henares,Spain, 2001.

665666667668669670671672673674675676677678679680681682683684

UNCO

RR