[MEI-L] source-type metadata

Axel Teich Geertinger atge at kb.dk
Wed Sep 15 16:33:19 CEST 2010


Hi Laurent & Raffaele,

I see your point, and I am not happy with mixing information such as “print”, “score” and “first edition” either! It was an quick way to sort sources in the order we wanted, but that’s a bad excuse (for the “first edition” information we could of course use <editionstmt>...)

Somewhere in <physdesc> could be the right place for the “print”/”manuscript”/”annotated print” etc. information, but using the @type on <physdesc> itself does not seem quite logical to me: “print” is not a type of physcial description, but a type of source (as a physical object).
The “score” or “parts” type is describing the source’s content and should probably be placed somewhere else, though I would prefer something more specific than <source><notesstmt><annot>.

Best wishes,
Axel


Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Raffaele Viglianti
Sendt: 15. september 2010 15:04
Til: Music Encoding Initiative
Emne: Re: [MEI-L] source-type metadata

Hi all,

It seems to me that <mei:source> acts both as description of the source and as bibliographical entry, therefore it is not a good idea to add a typing directly on the element itself, because what is "typed" can be unclear (is it the bibliographical entry, the description, the physical object or its content?). Instead, I think, how the editor classifies the source should live somewhere within the elements that deal with the description of the source (and not with its bibliographical entry). So something along the lines of what Laurent suggests seems to me a sensible choice.

The TEI handles the description of sources for critical editions with the <tei:witness> element, which only contains a limited amount of elements for a textual description.
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-witness.html
Its wrapper, <tei:witList>, can be contained in <tei:sourceDesc> that is the equivalent of <mei:source>.

Although I don't think it is necessary to add to MEI an equivalent to <tei:witness>, <mei:source> might still need an element that allows textual content for its description and categorisation without relying on <mei:notestmt> (mainly to avoid tag and @type abuse).

Best,
Raffaele


On Wed, Sep 15, 2010 at 1:29 PM, Laurent Pugin <laurent at music.mcgill.ca<mailto:laurent at music.mcgill.ca>> wrote:
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<mailto: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> [mailto: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<mailto: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<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l


_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto: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/ea32e63e/attachment.htm>


More information about the mei-l mailing list