[MEI-L] source-type metadata - once more
Roland, Perry (pdr4h)
pdr4h at eservices.virginia.edu
Mon Oct 4 15:23:56 CEST 2010
Hi, Benni,
Since I wrote it, I suppose I'm biased, but "Groups information which describes the nature or topic of a musical work" seems clear to me. Perhaps it just doesn't go far enough. Can you write more/different text for this explanation? We can put it into the next revision.
--
p.
__________________________
Perry Roland
Digital Curation Services
University of Virginia Library
P. O. Box 400155
Charlottesville, VA 22904-4155
434-982-2702 (w)
pdr4h at virginia.edu
________________________________________
From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Benjamin Wolff Bohl [bohl at edirom.de]
Sent: Monday, October 04, 2010 9:01 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] source-type metadata - once more
Hi everybody,
due to quite a lot of work concerning our Edirom Editor and our Edirom Summerschool I missed thanking all of you for your rich input concerning my source-type question.
Although I still have to change it in our software I will follow Perry's hint of putting it in the classification. I had thought of that earlier but due to the misleading description of the element in the tag-library I had decided of not even mentioning he idea.
If I understand right changing the element-description of "classification" will be another thing to be change in the next release.
Thanks,
Benjamin
Am 27.09.2010 um 17:15 schrieb Roland, Perry (pdr4h):
> Hi, Axel,
>
> This looks fine except that classcode isn't supposed to have text content according to the tag library! I think this constitutes an "oops" moment. :)
>
> My original intent was only to allow a label for the classification code. Textual content was later allowed in order to capture a short descriptive phrase for the ontology. I don't think an MEI file is the place to list or describe all the possible values of an ontology so I wouldn't recommend doing so even if your range of values is limited (as they are in this case). It opens the door for tag abuse.
>
> Unfortunately, I forgot to change the documentation. This will be addressed in the next release, tentatively scheduled for early next year.
>
> Currently, there's no way to refer to an external list of values, but I can see how that could be useful. I think the best option is to add an external linking attribute (href) to classcode. For example --
>
> <classification>
> <classcode xml:id="DcmContentClass" href="pointer.to.ontology" />
> <classcode xml:id="DcmPresentationClass" href="pointer.to.ontology"/>
> <classcode xml:id="DcmAuthorityClass" href="pointer.to.ontology"/>
> <classcode xml:id="DcmScoringClass" href="pointer.to.ontology"/>
> <classcode xml:id="DcmStageClass" href="pointer.to.ontology"/>
> <keywords>
> <term classcode="DcmContentClass">music</term>
> <term classcode="DcmPresentationClass">manuscript</term>
> <term classcode="DcmAuthorityClass">autograph</term>
> <term classcode="DcmScoringClass">parts</term>
> <term classcode="DcmStageClass">fair copy</term>
> </keywords>
> </classification>
>
> We can take care of this in the next release too.
>
> The classcode attribute on term can refer to a classcode element located anywhere, but, yes, you can place all classcode elements in profiledesc/classification for convenience. (I just noticed a problem, however, with the schematron rule that checks @classcode that will have to be fixed. One more thing for the next release.)
>
> Best wishes,
>
> --
> p.
>
> __________________________
> Perry Roland
> Digital Curation Services
> University of Virginia Library
> P. O. Box 400155
> Charlottesville, VA 22904-4155
> 434-982-2702 (w)
> pdr4h at virginia.edu
> ________________________________________
> From: Axel Teich Geertinger [atge at kb.dk]
> Sent: Monday, September 27, 2010 6:08 AM
> To: Roland, Perry (pdr4h)
> Subject: source-type metadata - once more
>
> Hi Perry
>
> I am trying to improve on our source typing using <classification> as you suggested, at the same time sorting out the independent parameters. I am arriving at something like this:
>
> <classification>
> <classcode xml:id="DcmContentClass">music | text</classcode>
> <classcode xml:id="DcmPresentationClass">print | annotated print | manuscript</classcode>
> <classcode xml:id="DcmAuthorityClass">autograph | doubtful autograph | partly autograph | copy</classcode>
> <classcode xml:id="DcmScoringClass">score | reduction | parts</classcode>
> <classcode xml:id="DcmStageClass">sketch | draft | fair copy | printer's copy | first edition | later edition</classcode>
> <keywords>
> <term classcode="DcmContentClass">music</term>
> <term classcode="DcmPresentationClass">manuscript</term>
> <term classcode="DcmAuthorityClass">autograph</term>
> <term classcode="DcmScoringClass">parts</term>
> <term classcode="DcmStageClass">fair copy</term>
> </keywords>
> </classification>
>
> I am not sure whether the possible (or suggested) values should be stated explicitly or better just described in <classcode>. Alternatively, I could refer to some external list of values.
> Also there may be several sources, so I guess I would have to move the <classcode> definitions to <profiledesc>.
> Does it make sense, in your opinion?
>
> All the best,
> Axel
>
>
>
>
> -----Oprindelig meddelelse-----
> Fra: mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På vegne af Roland, Perry (pdr4h)
> Sendt: 15. september 2010 17:12
> Til: Music Encoding Initiative
> Emne: Re: [MEI-L] source-type metadata
>
> Hi all,
>
> I think Laurent and Raffaele have it right -- @type leads to more confusion than it solves. Remember that (quoting the MEI Tag Library) -- "type ... characterizes the *element* in some sense, using any convenient classification scheme or typology." It's important to make the distinction between characterizing the element and characterizing the content of the element. Based on this understanding of @type, <source> purposefully doesn't permit it.
>
> Editionstmt/edition contains "[a] word or text phrase that indicates a difference in either content or form between the item being described and a related item previously issued by the same publisher/distributor (e.g. 2nd edition, version 2.0, etc.), or simultaneously issued by either the same publisher/distributor or another publisher/distributor (e.g. large print edition, British edition, etc.). " This definition is drawn directly from TEI and reflects the library practice of requiring that the distinguishing phrase be somewhere on the physical item being cataloged and that the publisher/distributor source of the item be considered. So, it doesn't seem like <edition> is a good place for this kind of info either.
>
> I agree with Laurent that MARC 254/musical presentation describes the physical attributes of a source. However, in an attempt to guide users toward <classification>, I intentionally did not create a <presentation> element within <physdesc>.
>
> Instead, the encoding of a musical presentation statement, like "score", "parts", "autograph", etc., is a kind of classification -- classification based on "physicality" instead of "topicality" -- but classification none-the-less. <classification> allows any kind of classification scheme and any combination of controlled and uncontrolled terms. So, to finally answer Bennie's question, <classifcation> is where this info belongs:
>
> <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>
> <classification>
> <classcode xml:id="RISMclass">RISM musical presentation values</classcode>
> <classcode xml:id="AxelClass">Axel's musical presentation values</classcode>
> <keywords classcode="RISMclass">
> <term>
> print | autograph | doubtful autograph | manuscript |
> manuscript with autograph annotations etc.
> </term>
> </keywords>
> <keywords classcode="AxelClass">
> <term>
> manuscript_sketch | manuscript_score_autograph |
> manuscript_score_copy etc.
> </term>
> </keywords>
> </classification>
> </source>
> </sourcedesc>
>
> --
> p.
>
> __________________________
> Perry Roland
> Digital Curation Services
> University of Virginia Library
> P. O. Box 400155
> Charlottesville, VA 22904-4155
> 434-982-2702 (w)
> pdr4h at virginia.edu
>
>
>
> From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti [raffaeleviglianti at gmail.com]
> Sent: Wednesday, September 15, 2010 9:04 AM
> To: Music Encoding Initiative
> Subject: 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> 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> 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_sketchManuscript, sketch
> manuscript_score_autographManuscript, score, autograph
> manuscript_score_copyManuscript, score, copy
> manuscript_parts_autographManuscript, parts, autograph
> manuscript_parts_copyManuscript, parts, copy
> print_score_firstPrinted score, first edition
> print_score_laterPrinted score, later edition
> print_partsPrinted parts
> text_msTextual source, manuscript
> text_printTextual source, print
> otherOther
>
>
> 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
>
>
>
>
> _______________________________________________
> mei-l mailing list
> 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
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> _______________________________________________
> mei-l mailing list
> 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
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
More information about the mei-l
mailing list