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.