[MEI-L] history of sources / items
Benjamin Wolff Bohl
bohl at edirom.de
Fri Apr 4 11:03:37 CEST 2014
Dear all,
not that I have too much experience in cataloguing sources or writing
verbose source description, but it might help to have a look at the TEI
way of doing things. Some nice example applications concerning
manuscripts were presented during the Edirom-Summer-School 2013 by
Torsten Schaßan.
The Herzog August Bibliothek has their TEI code available on-line, see
for example:
http://diglib.hab.de/?db=mss&list=ms&id=27-2-aug-2f&catalog=Lesser&mode=xml
Just my to code-points ;-)
Benjamin
***********************************************************
Musikwissenschaftliches Seminar Detmold/Paderborn
BMBF-Projekt "Freischütz Digital"
Benjamin Wolff Bohl
Gartenstraße 20
D--32756 Detmold
Tel. +49 (0) 5231 / 975-669
Fax: +49 (0) 5231 / 975-668
E-Mail: bohl at edirom.de
http://www.freischuetz-digital.de
***********************************************************
Am 03.04.2014 21:32, schrieb Joachim Veit:
> Dear Perry,
> thank you very much for these details and <annot type="naive">excuse
> my misunderstanding of the possibilities of "annotation"</annot>!!
> Indeed your proposal to transfer the possibiliies of <annot> to
> <history> would be excellent in my eyes because - at least in our case
> - the history will be so detailed that <annot> seems to be
> semantically inadequate (at least if we consent that the content of an
> essay should not be hidden in the footnotes but in the main text...;-) ).
> And with <div> we should have the opportunity to squeeze al things in
> which are hidden in the 27 corners of our project...
> Waiting for the discussion with Kristina and Johannes tomorrow,
> meanwhile with cordial thanks and best greetings,
> Joachim
>
>
> Am 03.04.14 17:59, schrieb Roland, Perry D. (pdr4h):
>> Johannes and Joachim,
>>
>>> Sometimes you have a copy, and you would like to tell the story
>>> behind it -- why it has been copied, under which conditions it
>>> happened, etc. Basically, I want to get hold of <creation> for
>>> source (and maybe item, even though I think this might be less
>>> important). Of course, people may confuse the histories of works and
>>> sources, but this doesn't explain why there shouldn't be a source
>>> history in MEI...
>> I understand your motivation better, but <creation> is not the thing
>> you're looking for (ala Obi-wan Kenobi). <creation> is intended to
>> hold a *brief* statement of the circumstances of creation. That's
>> why it's content model is very restrictive:
>>
>> <rng:zeroOrMore>
>> <rng:choice>
>> <rng:text/>
>> <rng:ref name="date"/>
>> <rng:ref name="geogName"/>
>> </rng:choice>
>> </rng:zeroOrMore>
>>
>> It's nothing more than a string with <date> and <geogName> thrown in
>> to capture important dates and places. You could think of <creation>
>> as the "quick and dirty" or "headline" version of the content that
>> follows it.
>>
>> For more "essay-like" content, you can use the other possible
>> children of history; i.e., eventList and p.
>>
>> <rng:optional>
>> <rng:ref name="model.headLike"/>
>> </rng:optional>
>> <rng:optional>
>> <rng:ref name="creation"/>
>> </rng:optional>
>> <rng:zeroOrMore>
>> <rng:choice>
>> <rng:ref name="eventList"/>
>> <rng:ref name="p"/>
>> </rng:choice>
>> </rng:zeroOrMore>
>>
>> But contrary to what Joachim said, the most "book-like" and least
>> restrictive model is actually that of <annot>:
>>
>> <rng:zeroOrMore>
>> <rng:choice>
>> <rng:text/>
>> <rng:ref name="model.textcomponentLike"/>
>> <rng:ref name="model.textphraseLike"/>
>> <rng:ref name="model.editLike"/>
>> <rng:ref name="model.transcriptionLike"/>
>> </rng:choice>
>> </rng:zeroOrMore>
>>
>> This allows just about everything under the sun!
>>
>> On the issue of <history>, what I hear you saying is that you'd like
>> its content model to be more like that of <annot>, something like:
>>
>> <rng:optional>
>> <rng:ref name="model.headLike"/>
>> </rng:optional>
>> <rng:optional>
>> <rng:ref name="creation"/>
>> </rng:optional>
>> <rng:zeroOrMore>
>> <rng:choice>
>> <rng:ref name="model.textcomponentLike"/>
>> </rng:choice>
>> </rng:zeroOrMore>
>>
>> where the members of model.textcomponentLike are:
>>
>> lgLike - lg
>> listLike - biblList, eventList, list
>> pLike -p
>> quoteLike - quote
>> tableLike - table
>>
>> or perhaps
>>
>> <rng:optional>
>> <rng:ref name="model.headLike"/>
>> </rng:optional>
>> <rng:optional>
>> <rng:ref name="creation"/>
>> </rng:optional>
>> <rng:zeroOrMore>
>> <rng:ref name="model.divLike"/>
>> </rng:zeroOrMore>
>>
>> where the membership of model.divLike is just <div> and members of
>> model.divLike and model.textcomponentLike are permitted as content of
>> <div>
>>
>> or
>>
>> <rng:optional>
>> <rng:ref name="model.headLike"/>
>> </rng:optional>
>> <rng:optional>
>> <rng:ref name="creation"/>
>> </rng:optional>
>> <rng:zeroOrMore>
>> <rng:choice>
>> <rng:ref name="model.divLike"/>
>> <rng:ref name="model.textcomponentLike"/>
>> </rng:choice>
>> </rng:zeroOrMore>
>>
>> making <history> into a more div-Like container that can wrap other
>> components and divs (which is how you can get section headings).
>>
>> These modifications will also address your need to include a list of
>> bibliographic citations within <history>.
>>
>> Going farther, we could even drop <creation> from <history>, moving
>> any content in former versions of MEI to subordinate <p> elements.
>> This would eliminate the privileging of data-like uses of <creation>.
>>
>>> I still think that <history> might be a better parent for
>>> <provenance> than <physDesc>. We agree that the provenance of an
>>> item is not part of the physical description, do we? I'm not saying
>>> we must move it to history, but I wonder if we could, possibly with
>>> additional means to prevent it from showing up on work and
>>> expression...
>> <physDesc> was a convenient place to locate <provenance> since in
>> library land, as Joachim confirms, "provenance> often has clear
>> connections with <physDesc> because stamps and librarian's or
>> auctioneer's entries are often mentioned in this context." But
>> there's no reason why it should remain there if there's a compelling
>> reason to move it.
>>
>> We could move <provenance> up a level into <item> itself rather than
>> placing it inside <history> and then making <history> available
>> inside <item>. Taking this approach would put <provenance> where it
>> needs to be (on <item>) and not everywhere <history> can occur; that
>> is, <work>, <expression>, and <source> (should we decide to allow
>> <history> there too). It also maintains separation between the
>> history of "handing down" (quoting Joachim) of the item and the
>> production history of the item, which is the proper content for
>> <item>/<history>.
>>
>> Does this help?
>>
>> --
>> p.
>>
>> __________________________
>> Perry Roland
>> Music Library
>> University of Virginia
>> P. O. Box 400175
>> Charlottesville, VA 22904
>> 434-982-2702 (w)
>> pdr4h (at) virginia (dot) edu
>> ________________________________________
>> From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of
>> Johannes Kepper [kepper at edirom.de]
>> Sent: Thursday, April 03, 2014 9:26 AM
>> To: Music Encoding Initiative
>> Subject: Re: [MEI-L] history of sources / items
>>
>> Am 03.04.2014 um 15:10 schrieb Roland, Perry D. (pdr4h)
>> <pdr4h at eservices.virginia.edu>:
>>
>>> Johannes,
>>>
>>> Sorry for arriving late to the party. :-)
>>>
>>> The <history> element wasn't provided in source (manifestation) and
>>> item in order to encourage the use of work/history or
>>> expression/history. The assumption was that what folks often have
>>> to say about a manifestation or item is really about the work and
>>> expression anyway.
>> Sometimes you have a copy, and you would like to tell the story
>> behind it -- why it has been copied, under which conditions it
>> happened, etc. Basically, I want to get hold of <creation> for source
>> (and maybe item, even though I think this might be less important).
>> Of course, people may confuse the histories of works and sources, but
>> this doesn't explain why there shouldn't be a source history in MEI...
>>
>>> A notesStmt/annot element (perhaps with a label of "history" in this
>>> case) can be used as a "catch all" to capture any information not
>>> easily shoe-horned into the other available elements in work,
>>> expression, source, and item. But, since the models of source and
>>> item are essentially lists of optional children, it's also not
>>> difficult to add <history> in all these places without creating any
>>> backwards compatibility problems. Before doing so, however, I'd
>>> like to know more about what you'd like to say about source and/or
>>> item history that makes this necessary.
>>>
>>> I'm not in favor of moving <provenance> inside <history> because
>>> doing this would mean breaking compatibility. It would also make
>>> provenance available inside work, expression, and source (e.g.,
>>> work/history/provenance) where its presence could lead to abuse.
>>> What exactly is the provenance (that is, the custodial history) of a
>>> work or expression? I don't there is such a thing.
>> Well, I see your point, and I agree with that. There is certainly no
>> provenance of a work or expression. The kind of information someone
>> would be looking for is about the transmission of the work, which
>> should go into history. However, I still think that <history> might
>> be a better parent for <provenance> than <physDesc>. We agree that
>> the provenance of an item is not part of the physical description, do
>> we? I'm not saying we must move it to history, but I wonder if we
>> could, possibly with additional means to prevent it from showing up
>> on work and expression...
>>
>>> I don't understand what problem you're having with <bibl> inside
>>> <source>. Are you looking to provide bibliographic citations for
>>> whatever arguments you present in <history>? I need more
>>> information, please.
>> I have no problem with bibl inside source, except that it isn't
>> allowed. I'd like to be able to put in literature about a specific
>> source (like a review of a printed edition etc.), that's it. The
>> current means to get a bibl into source seem to be too complicated...
>>
>> Hth,
>> Johannes
>> Ceterum censeo, don't forget to discuss the MEI organization, either
>> here on MEI-L or at http://bit.ly/1hDyq4X.
>>
>>
>>> --
>>> p.
>>>
>>> __________________________
>>> Perry Roland
>>> Music Library
>>> University of Virginia
>>> P. O. Box 400175
>>> Charlottesville, VA 22904
>>> 434-982-2702 (w)
>>> pdr4h (at) virginia (dot) edu
>>> ________________________________________
>>> From: mei-l
>>> [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf
>>> of Johannes Kepper [kepper at edirom.de]
>>> Sent: Thursday, April 03, 2014 5:16 AM
>>> To: Music Encoding Initiative
>>> Subject: Re: [MEI-L] history of sources / items
>>>
>>> I was hoping to get a reply from Perry, especially since I think
>>> this dates back to the days before FRBR, when there were work and
>>> source elements. expression and item just inherited their standard
>>> models with little modifications, so I'm not surprised about their
>>> behavior.
>>>
>>> However, I also prefer to add a history element to source and item,
>>> and moving provenance in there seems like a logical modification
>>> then. I wouldn't worry too much about backward compatibility. I
>>> think we're past the point where we'd have to make huge changes to
>>> the model, and little modifications should require only little
>>> modifications in software. Also, providing a XSLT to go back and
>>> forth between MEI2013 and MEI201x is not an issue, so that people
>>> could use whatever is most appropriate to them. This might result in
>>> putting the history somewhere nested into a notesStmt when going
>>> back to 2013, but so be it...
>>>
>>> I remember discussions about structured vs. prose-based content
>>> models for a number of elements, among them bibl and annot. Does
>>> this relate to the initial question, and should we revise it as well?
>>>
>>>
>>> Johannes
>>> Ceterum censeo, don't forget to discuss the MEI organization, either
>>> here on MEI-L or at http://bit.ly/1hDyq4X.
>>>
>>>
>>>
>>> Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field
>>> <esfield at stanford.edu>:
>>>
>>>> "Provenance" is a standard item in catalogues of works in
>>>> manuscript, but
>>>> it has a range of meanings, all of which might comfortable fit within
>>>> "history". It sometimes identifies previously owners but equally
>>>> often it
>>>> refers to a physical location (city, institution, performing group et
>>>> al.).
>>>>
>>>> Eleanor
>>>>
>>>> Eleanor Selfridge-Field
>>>> Consulting Professor, Music (and, by courtesy, Symbolic Systems)
>>>> Braun Music Center #129
>>>> Stanford University
>>>> Stanford, CA 94305-3076, USA
>>>> http://www.stanford.edu/~esfield/ +1/ 650 725-9242
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of
>>>> Johannes Kepper
>>>> Sent: Wednesday, April 02, 2014 2:39 AM
>>>> To: Music Encoding Initiative
>>>> Subject: [MEI-L] history of sources / items
>>>>
>>>> Dear list,
>>>>
>>>> while discussing the upcoming Weber Werkverzeichnis (Weber's work
>>>> catalogue) with Kristina Richts and Joachim Veit, I can't remember
>>>> why we
>>>> dropped the <history> element from sources and items? We have it on
>>>> works
>>>> and expressions, but not on these two. However, it might be
>>>> interested to
>>>> write something about the creation of a source (which is not the
>>>> same as
>>>> the provenance, which is available). Can someone please remind me
>>>> of our
>>>> argument to drop it? Otherwise, it would be a fault that we might
>>>> want to
>>>> correct.
>>>>
>>>> Btw., <bibl> seems to be equally hidden (you can get it from source at
>>>> source/physDesc/physMedium/bibl.).
>>>>
>>>> Best,
>>>> Johannes
>>>>
>>>> _______________________________________________
>>>> 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
-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140404/e6ed3b6f/attachment.html>
More information about the mei-l
mailing list