INTERNET-DRAFT A. Van Kerckhoven Document: draft-avk-bib-music-rec-00.txt Fibonacci sprl May 14, 1999 Expires November 15, 1999 A Bibliographic Format for Music Media Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt Abstract Many music libraries, music centers, music publishers, music shops and public need to share bibliographic musical records. No standard format exists and exchanging musical records involves an important pre- and/or post-processing of these data. Searching, sorting and cataloging music bibliographical records does not currently follow any standard. The researcher needs, in each library and each music information center, to use different procedure. In some cases, it is just impossible to obtain the targeted result. This document defines the requirements for a standard musical bibliographic format. 1. Introduction Many music libraries, music centers, music publishers, music shops and public need to share bibliographic musical records. No standard format exists and exchanging musical records involves an important pre- and/or post-processing of these data. Searching, sorting and cataloging music bibliographical records does not currently follow any standard. The researcher needs, in each library and each music information center, to use different procedure. In some cases, it is just impossible to obtain the targeted result. The following format may be the base of a standard for musical bibliographic records. Organizations may automate to any degree (or not at all) both the creation of these records (about their own publications) and the handling of the records received from other organizations. This format is designed to be simple, for people and for machines, to be easy to read ("human readable") and create without any special programs. The focus of this format has been into many aspects of digital libraries including searching and accessing techniques that do not necessarily use bibliographic records (for example, natural language processing, automatic and full-text indexing). However, the continued use of bibliographic records is expected to remain an important part of the library system environment of the future and its use is an important link between the servers of records and the clients on site, on line or using a distributed media. The use of this format is free and encouraged. There are no limitation on its use. 2. Format This format is a "tagged" format with self-explaining alphabetic tags. It should be possible to prepare and to read bibliographic records using any text editor, without any special programs. It is very easy to adapt any database for reading and writing this format. Converters may be developed to transform such data from this format to plain text or HTML and vice-versa. Since linear records are unable to efficiently manage the relation between the different kinds of information involved in music records management, the relational aspect of cataloguing must be maintained. Each packet of data considered in this format contains all significant information regarding a specific aspect of a record. This involves that several linked tables with several fields are necessary. Some fields are mandatory to insure integrity of the records and consistency of the links. 3. The tables The various tables should follow the format described below. This diagram constitutes the minimum requirement of the format. It can be extended with other tables for particular uses. RIGHTS-HOLDER Records relative to the rights-holders of the works (composers, librettist, arranger, publisher, sub-publisher...). WORK Records relative to the original works. VERSION Records relative to the instrumental versions of the works. RAPPORT Records relative to the rapport between a particular version and a rights-holder. MEDIA Records relative to the supports of the versions. OCCURRENCE Records relative to the occurrence of a particular version in a particular format. 4. The fields The various fields should follow the format described below. These diagrams constitute the minimum requirement of the format. They can be extended with other fields for particular uses. These complementary fields names (or tags) can't use ":", "<" nor ">". means Mandatory; a record without it is invalid. means Optional. designs the table targeted by a link. Just the fields are parts of this format. Links will be optionally used in the database systems to optimize the data management and the consultation of the records. MEDIA ----- ID TITLE TYPE PRODUCER LOCALISATION KEYWORDS NOTES OCCURRENCE --------- ID ID_VERSION ID_MEDIA KEYWORDS NOTES VERSION ------- ID ID_WORK SPECIFICITY OPUS START_COMPOSITION_DATE START_COMPOSITION_PLACE END_COMPOSITION_DATE END_COMPOSITION_PLACE KEYWORDS NOTES WORK ---- ID TITLE START_COMPOSITION_DATE START_COMPOSITION_PLACE END_COMPOSITION_DATE END_COMPOSITION_PLACE DURATION CITATIONS KEYWORDS NOTES RAPPORT ------- ID ID_RIGHTS-HOLDER ID_VERSION STATUS KEYWORDS NOTES RIGHTS-HOLDER ------------- ID NAME TYPE CONTACT KEYWORDS NOTES 5. Meta Format * A record contains several fields. * A packet contains several linked records. * A missing mandatory field invalidates the record. * A missing linked record invalidates the packet. * Some tables as one-to-many relationship with others. It involves that some tables may be repeated as needed, for example for works with several rights-holders (composer, author, arranger, publisher, sub-publisher...) or for media with including several versions. * Each packet starts with an indentifier (eventually random). This identifier is to check the relative identity of each field and to detect an eventual error (transmission, media corruption...) We shall design it by <>. It can be cleared after verification of the records. * Each packet ends with the tag <> preceding the packet identifier. * Each field starts with its tag preceded by the table-tag followed by two colons ":". This so-formed meta-tag is enclosed between "<<" and "::". Each field is ended by ">>". For example : <> * Carriage Return, Line breaks, tabulations and multiple spaces does not have significance. They may be used or not to optimize the clearness of the data according to the used media (email, paper...). If used, they may be replaced by single spaces. Other unprintable ASCII characters (backspace, null, DEL...) are prohibited. * Without derogation to the preceding point, 8-bit ASCII may be used. * It is recommended to follow the specification of text **** to format the fields and to implement other fields. EXAMPLE ------------------------------------------------------------- <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> ---------------------------- End of Example ------------------- This example illustrates a music sheet (MEDIA BS542187935) titled 'Two works for four hands. It includes one version (PF2H0001 and PF2H0002) of two different works : 'La bella Postina' (00000001) and 'Jazz' (00000002). The first one is published and has two rights-holders : the publisher Alain Van Kerckhoven (BE_ED001) and the composer Piotr Lachert (BE_CP001). The second one is unpublished and has been reproduced with a simple agreement of the composed, who has the all rights : Michel Lysight (BE_CP002). For reference, the above example has about 2,2281 characters. 6. Mandatory fields description PACKET_ID - alphanumeric field Any value (random, sequential or inductive) marking the beginning and the end of each packet, in order to avoid merging of packets in case of a media default. MEDIA:ID - alphanumeric field Identifies the media record and is used in management of these records. MEDIA:TITLE - alphanumeric field Main title of the media. If necessary, sub-titles or translations of the title have to fill other fields. MEDIA:TYPE - alphanumeric field Type of support : music sheet, CD, CD-ROM, DVD... Formats of the information can be described in other fields (encoding, file type, standard, compression...). OCCURENCE:ID - alphanumeric field Identifies the occurrence of a version in a media. OCCURENCE:ID_VERSION - alphanumeric field Points to a specific version. OCCURENCE:ID_MEDIA - alphanumeric field Points to a specific media. VERSION:ID - alphanumeric field Identifies the version record and is used in management of these records. VERSION:ID_WORK - numeric field Points to a specific work. VERSION:SPECIFICITY - alphanumeric field Main information making this version different from the other versions of the same work. It will often contain formation data : clarinet and piano, flute and piano etc. WORK:ID - numeric field Identifies the work record and is used in management of these records. WORK:TITLE::La bella Postina Main title of the media. If necessary, sub-titles or translations of the title have to fill other fields. RAPPORT:ID - numeric field Identifies the rapport between a rights-holder and a version. RAPPORT:ID_RIGHTS-HOLDER - alphanumeric field Points to a specific rights-holder RAPPORT:ID_VERSION - alphanumeric field Points to a specific rights-holder. RAPPORT:STATUS - alphanumeric field Describes the status of the rights-holder regarding the pointed version. A composer may be an arranger, and a publisher may be a librettist. RIGHTS-HOLDER:ID - alphanumeric field Identifies a rights-holder record and is used in management of these records. RIGHTS-HOLDER:NAME - alphanumeric field Name of the rights-holder (person of company). 7. Security Considerations Security issues are not addressed in this memo. Author's Address Alain Van Kerckhoven avenue Broustin 110 B-1083 Brussels Belgium Phone: +32 2 420.21.21 Fax : +32 2 420.05.05 EMail: alain@avk.org