idnits 2.17.1 draft-avk-bib-music-rec-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 683 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 30, 2000) is 8602 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'M' on line 323 -- Looks like a reference, but probably isn't: 'O' on line 327 -- Looks like a reference, but probably isn't: 'RFC-2376' on line 558 == Unused Reference: '1' is defined on line 577, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 581, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 585, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 589, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 592, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 596, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 599, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 603, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 606, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1766 (ref. '1') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 1866 (ref. '2') (Obsoleted by RFC 2854) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2413 (ref. '5') (Obsoleted by RFC 5013) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 1815 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 9 errors (**), 0 flaws (~~), 12 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT A. Van Kerckhoven 2 Document: draft-avk-bib-music-rec-02.txt Fibonacci 3 March 30, 2000 4 Expires September 30, 2000 6 Music Records Markup Language (MuReML) 8 1. Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 To view the list Internet-Draft Shadow Directories, see 24 http://www.ietf.org/shadow.html. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 Copyright Notice 31 Copyright (C) The Internet Society (1999). All Rights Reserved. 33 2. Abstract 35 Many music libraries, music centers, authors societies, music 36 publishers, music shops, broadcasting companies and public need to 37 share bibliographic musical records. No standard format exists and 38 exchanging musical records involves an important pre- and/or 39 post-processing of these data. 41 Searching, sorting and cataloging music bibliographical records does 42 not currently follow any standard. The researcher needs, in each 43 library and each music information center, to use different 44 procedure. In some cases, it is just impossible to obtain the 45 targeted result. 47 This document defines the requirements for a standard musical 48 bibliographic format. 50 3. Introduction 52 Many music libraries, music centers, authors societies, music 53 publishers, music shops broadcasting companies and public need to 54 share bibliographic musical records. No standard format exists and 55 exchanging musical records involves an important pre- and/or 56 post-processing of these data. 58 Searching, sorting and cataloging music bibliographical records does 59 not currently follow any standard. The researcher needs, in each 60 library and each music information center, to use different 61 procedure. In some cases, it is just impossible to obtain the 62 targeted result. 64 The following format may be the base of a standard for musical 65 bibliographic records. 67 It designed as an XML application, as defined by W3C in 68 REC-xml-19980210 accessible at http://www.w3.org/TR/REC-xml.html. 70 It features all properties of XML metalanguage : a structural 71 extensibility, validity controls, independence of data and 72 formatting, and it allows heterogeneity of data sources and targets. 73 XML will likely be supported by the main web browsers in a short 74 future. 76 This format fits the goals and recommendations of RFC-2413 (Dublin 77 Core Metadata for Resource Discovery) : 79 - Simplicity of creation and maintenance 80 - Commonly understood semantics 81 - Conformance to existing and emerging standards 82 - International scope and applicability 83 - Extensibility 84 - Interoperability among collections and indexing systems 86 Organizations may automate to any degree (or not at all) both the 87 creation of these records (about their own publications) and the 88 handling of the records received from other organizations. 90 This format is designed to be simple, for people and for machines, 91 to be easy to read ("human readable") and create without any special 92 programs. 94 The focus of this format has been into many aspects of digital 95 libraries including searching and accessing techniques that do not 96 necessarily use bibliographic records (for example, natural language 97 processing, automatic and full-text indexing). However, the 98 continued use of bibliographic records is expected to remain an 99 important part of the library system environment of the future and 100 its use is an important link between the servers of records and the 101 clients on site, on line or using a distributed media. 103 The use of this format is free and encouraged. There are no 104 limitation on its use. 106 4. Formal Syntax 108 The following syntax specification uses the Extensible Markup 109 Language (XML) 1.0. 111 4.1. Character set 113 The characters set used is defined by ISO-10646 (coding characters 114 on 32 bits) and permits the use of symbols and non latin alphabets. 115 It is preferable, but not mandatory to explicitly declare it. 117 119 All entities defined by ISO-10646 are permitted but "&" and "<". 120 They can be used, as any other entity, on pointing the referring 121 ISO-10646 code or the pre-defined XML entities with the standard XML 122 syntax : 124 & or & for "&" 125 $#60; or < for "<" 127 4.2. Languages 129 XML's support for multiple human languages, using the "xml:lang" 130 attribute, handles cases where the same character set is employed by 131 multiple human languages. In consequence, MuReML is a multi-language 132 format. It gives the possibility to labellize the chosen language 133 for each field, and the default language of the record. XML syntax 134 applied to ISO-639 (for language) and optionally to ISO-3166 (for 135 regional linguistic particularities) may be used. 137 My Foot! 138 Mon Œil! 140 4.3. Specific formattings 142 Data of each field may refer to any adequate ISO norm for its 143 representation. According to XML specification, this norm will be 144 declared in the opening tag. 146 F 147 1999-10-02T20:30:00Z 148 150 4.4. Cases 152 Data are case-sensitive. 154 4.5. White space and End-of-line handling 156 The Music Records Markup Language, as a subset of XML, has the same 157 white space handling and end-of-line handling as specified in 158 Extensible Markup Language (XML) 1.0 (W3C Recommendation 159 10-February-1998). 161 4.6. Grammar 163 XML has been chosen because it is a flexible, self-describing, 164 structured data format that supports rich schema definitions, and 165 because of its support for multiple character sets. XML's self- 166 describing nature allows any property's value to be extended by 167 adding new elements. 169 This format is a "tagged" format with self-explaining alphabetic 170 tags. It should be possible to prepare and to read bibliographic 171 records using any text editor, without any special programs. 173 It is very easy to adapt any database for reading and writing this 174 format. Converters may be developed to transform such data from this 175 format to plain text or HTML for example. 177 As an XML application, the lay-out and the design of the formatted 178 data may be freely cosen by normalized style sheet mechanism like 179 Cascading Style Sheet (CSS1, CSS2) or Extensible Stylesheet Language 180 (XSL). 182 Since linear records are unable to efficiently manage the relation 183 between the different kinds of information involved in music records 184 management, the relational aspect of cataloguing must be maintained. 186 Each element has a descriptive name intended to convey a common 187 semantic understanding. 189 Each packet of data considered in this format contains all 190 significant information regarding a specific aspect of a record. 191 This involves that several linked tables with several fields are 192 necessary. Some fields are mandatory to insure integrity of the 193 records and consistency of the links. 195 Each packet starts with an indentifier (eventually random). This 196 identifier is to check the relative identity of each packet and to 197 make it traceable. A community of users may use it to identify its 198 own packets. 200 4.7. The tables 202 The various tables must follow the format described below. This 203 diagram constitutes the minimum requirement of the format. It can be 204 extended with other tables for particular uses. To fit the needs of 205 musical records management (for example : highest hierarchy of 206 tables, unnecessary differentiation of the various contributors...), 207 this structure lightly diverges from the recommendations of the 208 Dublin Core Metadata Element Set. 210 Some tables as one-to-many relationship with others. It involves 211 that some tables may be repeated as needed, for example for works 212 with several rights-holders (composer, author, arranger, publisher, 213 sub-publisher...) or for media with including several versions. 214 Tables are also optional. They may appear in any order inside a 215 particular packet. 217 MEDIA 218 Records relative to the supports of the versions. 220 OCCURRENCE 221 Records relative to the occurrence of a particular version in a 222 particular format. 224 RAPPORT 225 Records relative to the rapport between a particular version 226 and a rights-holder. 228 RIGHTS-HOLDER 229 Records relative to the rights-holders of the works 230 (composers, librettist, arranger, publisher, sub-publisher...). 232 VERSION 233 Records relative to the instrumental versions of the works. 235 WORK 236 Records relative to the original works. 238 4.8. The fields 240 The various fields should follow the format described below. These 241 diagrams constitute the minimum requirement of the format. They can 242 be extended with other fields for particular uses. These 243 complementary fields names (or tags) have to be built in accordance 244 of XML requirements. 246 These fields are repeatable. A missing mandatory field invalidates 247 the packet. 249 Each field tag name begins with the parent table name, followed 250 by an underscore. For example : Monochrone 252 [M] means Mandatory; a record without it is invalid. 254 [O] means Optional (here to illustrate the extensibility of MuReML) 256 [L:FIELD] designs the table targeted by a link. Just the fields are 257 parts of this format. Links will be optionally used in the database 258 systems to optimize the data management and the consultation of the 259 records. 261 PACKET 262 ----- 263 [M] id 265 MEDIA 266 ----- 267 [M] id 268 [M] title 269 [M] type 270 [O] producer 271 [O] localization 272 [O] keywords 273 [O] notes 275 OCCURRENCE 276 --------- 277 [M] id 278 [M] id_version [l:version] 279 [M] id_media [l:media] 280 [O] keywords 281 [O] notes 283 VERSION 284 ------- 285 [M] id 286 [M] id_work [l:work] 287 [M] specificity 288 [O] opus 289 [O] start_composition_date 290 [O] start_composition_place 291 [O] end_composition_date 292 [O] end_composition_place 293 [O] keywords 294 [O] notes 296 WORK 297 ---- 298 [M] id 299 [M] title 300 [O] original language title 301 [O] US-english title 302 [O] start_composition_date 303 [O] start_composition_place 304 [O] end_composition_date 305 [O] end_composition_place 306 [O] duration 307 [O] citations 308 [O] keywords 309 [O] notes 311 RAPPORT 312 ------- 313 [M] id 314 [M] id_rights-holder [l:rights-holder] 315 [M] id_version [l:version] 316 [M] status 317 [O] keywords 318 [O] notes 320 RIGHTS-HOLDER 321 ------------- 322 [M] id 323 [M] name 324 [O] type 325 [O] contact 326 [O] keywords 327 [O] notes 329 4.9. Meta Format and DTD 331 MuReML is an open format. Communities of users may enlarge it to 332 their own needs. The minimal elements needed in a DTD to fit the 333 MuReML specifications are : 335 337 338 339 340 341 342 344 345 346 347 349 350 351 352 353 354 355 357 358 359 360 361 362 364 5. Example 366 ---------------------- Begin of Example ------------------- 368 370 371 AVK990127223015 373 374 BS542187935 375 Two works for four hands 376 music sheet 377 Big Deal Publishing 378 Produced by the publisher 379 381 382 a12354879654-12 383 PF2H0001 384 BS542187935 386 a12354879655-13 387 PF2H0002 388 BS542187935 389 391 392 PF2H0001 393 00000001 394 piano four-hand 395 102 396 ordered by the publisher and dedicated 397 to AmF 399 PF2H0002 400 00000002 401 piano four-hand 402 102 403 ordered by the publisher 404 406 407 00000001 408 La bella Postina 409 1999-02-05 410 411 00:12:30 412 modules, rehearsals, repetitive, composer's 413 introduction 415 00000002 416 Jazz 417 1999-01-15 418 419 1999-01-30 420 421 00:09:00 422 424 425 5478985251454117 426 BE_ED001 427 PF2H0001 428 original publisher 430 5478985251454117 431 BE_CP001 432 PF2H0001 433 composer 435 5478985251454117 436 BE_CP002 437 PF2H0002 438 composer 439 441 442 BE_ED001 443 Big Deal Publishing 444 publisher 445 Alain Van Kerckhoven 446 447 post-modernism, classical, Devreese, 448 Lachert, Lysight, Mendes, Pelecis 449 Founded in 1989 451 BE_CP001 452 Lachert, Piotr 453 composer 454 Lachert, Piotr 455 post-modernism, computer music, 456 letters music 458 BE_CP002 459 Lysight, Michel 460 composer 461 Lysight, Michel 462 post-modernism, repetitive music, 463 minimalism 464 466 468 ------------------------- End of Example ------------------- 470 Indentations and line-breaks are for convenient visualization. 472 This example illustrates a music sheet (MEDIA BS542187935) titled 473 "Two works for four hands". It includes one version (PF2H0001 and 474 PF2H0002) of two different works : "La bella Postina" (00000001) and 475 "Jazz" (00000002). The first one is published and has two 476 rights-holders : the publisher Alain Van Kerckhoven (BE_ED001) and 477 the composer Piotr Lachert (BE_CP001). The second one is unpublished 478 and has been reproduced with a simple agreement of the composer, who 479 has the all rights : Michel Lysight (BE_CP002). 481 For reference, the above example contains 3,405 characters. 483 6. Mandatory fields description 485 PACKET_ID 486 Any value (random, sequential or inductive) marking the beginning 487 and the end of each packet, in order to avoid merging of packets 488 in case of a media default. 490 MEDIA_ID 491 Identifies the media record and is used in management of these 492 records. 494 MEDIA_TITLE 495 Main title of the media. If necessary, sub-titles or translations of 496 the title have to fill other fields. 498 MEDIA_TYPE 499 Type of support : music sheet, CD, CD-ROM, DVD... Formats of the 500 information can be described in other fields (encoding, file type, 501 standard, compression...). 503 occurrence_ID 504 Identifies the occurrence of a version in a media. 506 occurrence_VERSION_ID 507 Points to a specific version. 509 occurrence_MEDIA_ID 510 Points to a specific media. 512 VERSION_ID 513 Identifies the version record and is used in management of these 514 records. 516 VERSION_WORK_ID 517 Points to a specific work. 519 VERSION_SPECIFICITY 520 Main information making this version different from the other 521 versions of the same work. It will often contain formation data : 522 clarinet and piano, flute and piano etc. 524 WORK_ID 525 Identifies the work record and is used in management of these 526 records. 528 WORK_TITLE 529 Main title of the media. If necessary, sub-titles or translations 530 of the title have to fill other fields. 532 RAPPORT_ID 533 Identifies the rapport between a rights-holder and a version. 535 RAPPORT_ID_RIGHTS-HOLDER 536 Points to a specific rights-holder 538 RAPPORT_ID_VERSION 539 Points to a specific rights-holder. 541 RAPPORT_STATUS 542 Describes the status of the rights-holder regarding the pointed 543 version. A composer may be an arranger, and a publisher may be 544 a librettist. 546 RIGHTS-HOLDER_ID 547 Identifies a rights-holder record and is used in management of these 548 records. 550 RIGHTS-HOLDER_NAME 551 Name of the rights-holder (person of company). This includes 552 composers, publishers, sub-publishers, librettists, transcribers, 553 illustrators, arrangers, orchestrators etc. 555 7. Security Considerations 557 The Music Records Markup Language, as a subset of XML, has the same 558 security considerations as specified in [RFC-2376]. 560 8. Acknowledgments 562 This document has benefited greatly from the luminous suggestion by 563 Mark Needlaman to move my first format proposition 564 (draft-avk-bib-music-rec-01.txt) into a XML application. 566 Thanks to John Stracke for introducing the Dublin Core to me. 568 Thanks to Steve Coya and to IESG for critics of the first release of 569 this memo. 571 Thanks to the "lazy bits" of Brussels. You know who you are. 573 Thanks to Mireille. 575 9. References 577 [1] Alvestrand, H., "Tags for the identification of languages", RFC 578 1766, UNINETT, March 1995. 579 581 [2] Berners-Lee, T., and D. Connolly, "HyperText Markup Language 582 Specification - 2.0", RFC 1866, MIT/LCS, November 1995. 583 585 [3] W3C XML Working Group (WG), "Extensible Markup Language (XML) 586 1.0", W3C Recommendation, February 1998. 587 589 [4] Weibel, S., Kunze, J., Lagoze, C., Wolf, M., "Dublin Core 590 Metadata Element Set" 592 [5] Weibel, S., Kunze, J., Lagoze, C., Wolf, M., "Dublin Core 593 Metadata for Resource Discovery" RFC-2413 594 596 [6] Date and Time Formats (based on ISO 8601), W3C Technical Note, 597 599 [7] Ohta, M., "Character Sets ISO-10646 and ISO-10646-J-1", RFC 600 1815, Tokyo Institute of Technology, Juy 1995. 601 603 [8] ISO-639, "Code for the representation of names of languages.", 604 International Standards Organization, 1988 606 [9] ISO-3166, "Codes for the Representation of Names of Countries", 607 International Standards Organization, May 1981. 609 10. Author's Address 611 Alain Van Kerckhoven 612 avenue Broustin 110 613 B-1083 Brussels 614 Belgium 616 Phone: +32 2 420.21.21 617 Fax : +32 2 420.05.05 618 EMail: alain@avk.org 620 11. Full Copyright Statement 622 Copyright (C) The Internet Society (2000). All Rights Reserved. 624 This document and translations of it may be copied and furnished to 625 others, and derivative works that comment on or otherwise explain it 626 or assist in its implementation may be prepared, copied, published 627 and distributed, in whole or in part, without restriction of any 628 kind, provided that the above copyright notice and this paragraph 629 are included on all such copies and derivative works. However, this 630 document itself may not be modified in any way, such as by removing 631 the copyright notice or references to the Internet Society or other 632 Internet organizations, except as needed for the purpose of 633 developing Internet standards in which case the procedures for 634 copyrights defined in the Internet Standards process must be 635 followed, or as required to translate it into languages other than 636 English. 638 The limited permissions granted above are perpetual and will not be 639 revoked by the Internet Society or its successors or assigns. 641 This document and the information contained herein is provided on an 642 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 643 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 644 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 645 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 646 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.