[MEI-L] source-type metadata

Wed Sep 15 21:54:53 CEST 2010

Hi,

I will leave the details of tag names and order to all of you, but I would
like to expand on Laurent’s comments with respect to our own work at CCARH
for full-score encoding and part production (see http://www.musedata.org).

1.       Parts

Parts have their own physical/layout requirements that are different from
scores. This extends to fonts (parts are generally in larger type); they
may also be on a smaller page size (so it does not fall off a music stand)
or they may conform to a different aspect ratio. They often require
multi-bar rests, which as physical symbols are different in number and
presentation from what the rests in a score. The largest number of
consecutive bar-rests occurring in tandem in our work has so far been 67
(a Handel oratorio).

2.       Multibar rests with respect to parts and scores

The multi-bar rest problem points to a much larger problem in the
presentation of scores with individual parts that blink on and off. Most
publishers want to conserve as much paper as possible, and acres of staves
with rests in a score can consume many extra pages. The widespread
practice is to reduced the number of staves where ever possible. In
digital environments, solutions to this problem can become very tangled up
with the treatment of divisi parts (the number of individual/combined
parts for a specific instrument keep changing), or of tremolandi (their
use is rarely mandatory, but it saves reams of paper).

In the case of orchestral music and opera, the later the date of the
composition, the more likely it is to be affected by this problem. Since
many MEI-ers are working on the nineteenth century, this may be a good
time to think about how many hooks (if any) MEI wants to offer to those
converting its material to print.

3.       Relationships/Differentiation between printed and electronic
scores/parts

A whole new layer of complexity to any system of description is introduced
by facilitating both printed and electronic publication. If it is intended
that any of the editions generated by MEI are to be “born digital,” then
it is necessary to have a rather extensive set of tags to facilitate it.
The critical software question is where to branch off between paper and
electronic formats in the process of getting from encoding to
implementation(s).

Electronic publishing of a musical score can take the format of a
continuous horizontal or vertical “scroll” to which concepts of page break
and page layout (with or without paper-saving features) are irrelevant.
Currently, though, no one can perform from these formats, and they are
very difficult to print without the loss of some detail. Th crux of the
problem is non-convertibility between one end product and another via its
encoding. All the post-processing fixes become specific to one graphical
instantiation (as, for example, with some basso continuo figures in
commercial notation packages).

4.       Amalgamations of different clusters of parts (also with cue-sized
notes) to produce short scores

There seems to be no end to the imaginative combinations of instruments
today’s musicians want to be able to view in one short score. Typically,
they also want cue-size notes in selected passages. Last week one of our
colleagues wanted a violin-viola short score for a piece of chamber music
(for several instruments) he is preparing. It is good that people are
thinking of this kind of flexibility, but it remains difficult to provide
the equivalent of printed conventions without undo time and effort. We
undertook quite an effort in this area several years ago with Handel’s
Messiah. You can study some of the differences at
http://scores.ccarh.org/handel/messiah/.

There may be no perfect solutions to these questions, but my belief is
that #1 and #2 potentially affect many of the repertories considering the
use of MEI. Most people have not dealt with #3 or #4 yet in any systematic
way, but we have because of our current emphasis on PDF generation
directly from musical data. You can see some results at these links:

                http://www.ccarh.org/publications/beethoven-symphonies/

                To study the score/part problem, see the parts for
Beethoven’s Seventh Symphony at
http://www.musedata.org/encodings/beet/bh/sym/no7/

                MEI has a real chance to address some of the lapses in
commercial software.

Eleanor

esfield at stanford.edu

From: mei-l-bounces at lists.uni-paderborn.de
[mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin
Sent: Wednesday, September 15, 2010 5:29 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] source-type metadata

Hi,

I would suggest to try to keep information related to the physical
description and information related to the edition separated. I have the
impression that something like 'print_score_later' mixes several types of
information, with the risk to have exponential possible combination. And
the order might be problematic too if we want to use it as a search
criteria.

I would personally store within <physdesc> whether it is a 'print' a
'manuscript' etc. The @type could be an option. At the RISM, we use the
following values, which might have to be extended:
- print
- autograph
- doubtful autograph
- manuscript
- manuscript with autograph annotations

To me, score/parts information does not seem to be related to the physical
description. For example, In MARC21, the information is typically stored
in a 254 tag (25X-28X tags being used for Edition, Imprint, Etc.):
http://www.loc.gov/marc/bibliographic/bd254.html

In a cross-walk from MARC21 to TEI I've been looking at, the 254 tag goes
into a <noteStmt> within the <bibFull> element. If we want do something
similar with what we have now in MEI, we would probably get something
like:

<sourcedesc>
    <source>
        <notestmt>
            <annot>Full score</annot>
        </notestmt>
    </source>
</sourcedesc>

But maybe we would need something more specific than an annotation?

All the best,
Laurent

On Wed, Sep 15, 2010 at 12:19 PM, Axel Teich Geertinger <atge at kb.dk>
wrote:

Hi Benjamin

I think @type on the source element would be a good idea. We are having
the same problem, but have solved it for now by using @n instead to
categorize the source type, but obviously @type would be more appropriate.

We are using the following values so far:

manuscript_sketch

Manuscript, sketch

manuscript_score_autograph

Manuscript, score, autograph

manuscript_score_copy

Manuscript, score, copy

manuscript_parts_autograph

Manuscript, parts, autograph

manuscript_parts_copy

Manuscript, parts, copy

print_score_first

Printed score, first edition

print_score_later

Printed score, later edition

print_parts

Printed parts

text_ms

Textual source, manuscript

text_print

Textual source, print

other

Other

We then use the source/titlestmt/title element to provide a more specific
description of the source, e.g. “Score, fair copy, printer’s source” or
“Printed part, Ove Scavenius' copy”.

If anyone knows a better solution, I’d be happy to know about it.

All the best,

Axel

Fra: mei-l-bounces at lists.uni-paderborn.de
[mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Benjamin Wolff
Bohl
Sendt: 15. september 2010 11:25
Til: mei-l at lists.uni-paderborn.de
Emne: [MEI-L] source-type metadata

Hi Mei-List(eners)!

I got a question concerning the location of some metadata I would like to
put into an MEI-file.

I just don't know where I should put it.

I would like to store a type on a source element I have, specifying
whether it is a print or an autograph, maybe even more like a copyists
copy or an edition.

So in my code I have the following:

<sourcedesc>
                <source
xml:id="source_3c94e494-bc7e-4233-a27d-17671fc8d933">
                    <titlestmt>
                        <title>Londoner Abschrift</title>
                    </titlestmt>
                   <pubstmt>
                        <date reg="2010">2010</date>
                       <identifier type="siglum">K2</identifier>
                    </pubstmt>

Now I wondering whether the right place of such data would be an
editionstmt or maybe the physdesc, which could contain even more detailed
data concerning the creation of the source? (see below)

                    <physdesc>
                        <physmedium n="type">
                        <physmedium n="support"></physmedium>
                        <physmedium n="content"></physmedium>
                        <physloc/>
                    </physdesc>
                </source>
            </sourcedesc>

O would it be best/easiest to have @type on source? (which currently is
not possible)

Cheers,

Benjamin

***********************************************************

Projekt "Digitale Musikedition"

Musikwissenschaftliches Seminar Detmold/Paderborn

Gartenstraße 20

D – 32756 Detmold

Tel. +49 (0) 5231 / 975-665

Fax: +49 (0) 5231 / 975-668

***********************************************************

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20100915/bb3e775a/attachment.htm>