<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Dear all,<br>
      <br>
      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.<br>
      <br>
      The Herzog August Bibliothek has their TEI code available on-line,
      see for example:<br>
      <a
href="http://diglib.hab.de/?db=mss&list=ms&id=27-2-aug-2f&catalog=Lesser&mode=xml">http://diglib.hab.de/?db=mss&list=ms&id=27-2-aug-2f&catalog=Lesser&mode=xml</a><br>
      <br>
      Just my to code-points ;-)<br>
      Benjamin<br>
      <pre class="moz-signature" cols="72">***********************************************************
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: <a class="moz-txt-link-abbreviated" href="mailto:bohl@edirom.de">bohl@edirom.de</a>

<a class="moz-txt-link-freetext" href="http://www.freischuetz-digital.de">http://www.freischuetz-digital.de</a>
***********************************************************</pre>
      Am 03.04.2014 21:32, schrieb Joachim Veit:<br>
    </div>
    <blockquote cite="mid:533DB74A.7060100@weber-gesamtausgabe.de"
      type="cite">Dear Perry,
      <br>
      thank you very much for these details and <annot
      type="naive">excuse my misunderstanding of the possibilities of
      "annotation"</annot>!!
      <br>
      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...;-) ).
      <br>
      And with <div> we should have the opportunity to squeeze al
      things in which are hidden in the 27 corners of our project...
      <br>
      Waiting for the discussion with Kristina and Johannes tomorrow,
      <br>
      meanwhile with cordial thanks and best greetings,
      <br>
      Joachim
      <br>
      <br>
      <br>
      Am 03.04.14 17:59, schrieb Roland, Perry D. (pdr4h):
      <br>
      <blockquote type="cite">Johannes and Joachim,
        <br>
        <br>
        <blockquote type="cite">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…
          <br>
        </blockquote>
        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:
        <br>
        <br>
        <rng:zeroOrMore>
        <br>
           <rng:choice>
        <br>
             <rng:text/>
        <br>
             <rng:ref name="date"/>
        <br>
             <rng:ref name="geogName"/>
        <br>
           </rng:choice>
        <br>
        </rng:zeroOrMore>
        <br>
        <br>
        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.
        <br>
        <br>
        For more "essay-like" content, you can use the other possible
        children of history; i.e., eventList and p.
        <br>
        <br>
        <rng:optional>
        <br>
           <rng:ref name="model.headLike"/>
        <br>
        </rng:optional>
        <br>
        <rng:optional>
        <br>
           <rng:ref name="creation"/>
        <br>
        </rng:optional>
        <br>
        <rng:zeroOrMore>
        <br>
           <rng:choice>
        <br>
             <rng:ref name="eventList"/>
        <br>
             <rng:ref name="p"/>
        <br>
           </rng:choice>
        <br>
        </rng:zeroOrMore>
        <br>
        <br>
        But contrary to what Joachim said, the most "book-like" and
        least restrictive model is actually that of <annot>:
        <br>
        <br>
        <rng:zeroOrMore>
        <br>
           <rng:choice>
        <br>
             <rng:text/>
        <br>
             <rng:ref name="model.textcomponentLike"/>
        <br>
             <rng:ref name="model.textphraseLike"/>
        <br>
             <rng:ref name="model.editLike"/>
        <br>
             <rng:ref name="model.transcriptionLike"/>
        <br>
           </rng:choice>
        <br>
        </rng:zeroOrMore>
        <br>
        <br>
        This allows just about everything under the sun!
        <br>
        <br>
        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:
        <br>
        <br>
        <rng:optional>
        <br>
           <rng:ref name="model.headLike"/>
        <br>
        </rng:optional>
        <br>
        <rng:optional>
        <br>
           <rng:ref name="creation"/>
        <br>
        </rng:optional>
        <br>
        <rng:zeroOrMore>
        <br>
           <rng:choice>
        <br>
             <rng:ref name="model.textcomponentLike"/>
        <br>
           </rng:choice>
        <br>
        </rng:zeroOrMore>
        <br>
        <br>
        where the members of model.textcomponentLike are:
        <br>
        <br>
        lgLike - lg
        <br>
        listLike - biblList, eventList, list
        <br>
        pLike -p
        <br>
        quoteLike - quote
        <br>
        tableLike - table
        <br>
        <br>
        or perhaps
        <br>
        <br>
        <rng:optional>
        <br>
           <rng:ref name="model.headLike"/>
        <br>
        </rng:optional>
        <br>
        <rng:optional>
        <br>
           <rng:ref name="creation"/>
        <br>
        </rng:optional>
        <br>
        <rng:zeroOrMore>
        <br>
           <rng:ref name="model.divLike"/>
        <br>
        </rng:zeroOrMore>
        <br>
        <br>
        where the membership of model.divLike is just <div> and
        members of model.divLike and model.textcomponentLike are
        permitted as content of <div>
        <br>
        <br>
        or
        <br>
        <br>
        <rng:optional>
        <br>
           <rng:ref name="model.headLike"/>
        <br>
        </rng:optional>
        <br>
        <rng:optional>
        <br>
           <rng:ref name="creation"/>
        <br>
        </rng:optional>
        <br>
        <rng:zeroOrMore>
        <br>
           <rng:choice>
        <br>
             <rng:ref name="model.divLike"/>
        <br>
             <rng:ref name="model.textcomponentLike"/>
        <br>
           </rng:choice>
        <br>
        </rng:zeroOrMore>
        <br>
        <br>
        making <history> into a more div-Like container that can
        wrap other components and divs (which is how you can get section
        headings).
        <br>
        <br>
        These modifications will also address your need to include a
        list of bibliographic citations within <history>.
        <br>
        <br>
        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>.
        <br>
        <br>
        <blockquote type="cite">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…
          <br>
        </blockquote>
        <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.
        <br>
        <br>
        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>.
        <br>
        <br>
        Does this help?
        <br>
        <br>
        --
        <br>
        p.
        <br>
        <br>
        __________________________
        <br>
        Perry Roland
        <br>
        Music Library
        <br>
        University of Virginia
        <br>
        P. O. Box 400175
        <br>
        Charlottesville, VA 22904
        <br>
        434-982-2702 (w)
        <br>
        pdr4h (at) virginia (dot) edu
        <br>
        ________________________________________
        <br>
        From: mei-l [<a class="moz-txt-link-abbreviated" href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>] on behalf of
        Johannes Kepper [<a class="moz-txt-link-abbreviated" href="mailto:kepper@edirom.de">kepper@edirom.de</a>]
        <br>
        Sent: Thursday, April 03, 2014 9:26 AM
        <br>
        To: Music Encoding Initiative
        <br>
        Subject: Re: [MEI-L] history of sources / items
        <br>
        <br>
        Am 03.04.2014 um 15:10 schrieb Roland, Perry D. (pdr4h)
        <a class="moz-txt-link-rfc2396E" href="mailto:pdr4h@eservices.virginia.edu"><pdr4h@eservices.virginia.edu></a>:
        <br>
        <br>
        <blockquote type="cite">Johannes,
          <br>
          <br>
          Sorry for arriving late to the party.  :-)
          <br>
          <br>
          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.
          <br>
        </blockquote>
        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…
        <br>
        <br>
        <blockquote type="cite">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.
          <br>
          <br>
          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.
          <br>
        </blockquote>
        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…
        <br>
        <br>
        <blockquote type="cite">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.
          <br>
        </blockquote>
        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…
        <br>
        <br>
        Hth,
        <br>
        Johannes
        <br>
        Ceterum censeo, don't forget to discuss the MEI organization,
        either here on MEI-L or at <a class="moz-txt-link-freetext" href="http://bit.ly/1hDyq4X">http://bit.ly/1hDyq4X</a>.
        <br>
        <br>
        <br>
        <blockquote type="cite">--
          <br>
          p.
          <br>
          <br>
          __________________________
          <br>
          Perry Roland
          <br>
          Music Library
          <br>
          University of Virginia
          <br>
          P. O. Box 400175
          <br>
          Charlottesville, VA 22904
          <br>
          434-982-2702 (w)
          <br>
          pdr4h (at) virginia (dot) edu
          <br>
          ________________________________________
          <br>
          From: mei-l
          [<a class="moz-txt-link-abbreviated" href="mailto:mei-l-bounces+pdr4h=virginia.edu@lists.uni-paderborn.de">mei-l-bounces+pdr4h=virginia.edu@lists.uni-paderborn.de</a>] on
          behalf of Johannes Kepper [<a class="moz-txt-link-abbreviated" href="mailto:kepper@edirom.de">kepper@edirom.de</a>]
          <br>
          Sent: Thursday, April 03, 2014 5:16 AM
          <br>
          To: Music Encoding Initiative
          <br>
          Subject: Re: [MEI-L] history of sources / items
          <br>
          <br>
          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.
          <br>
          <br>
          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…
          <br>
          <br>
          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?
          <br>
          <br>
          <br>
          Johannes
          <br>
          Ceterum censeo, don't forget to discuss the MEI organization,
          either here on MEI-L or at <a class="moz-txt-link-freetext" href="http://bit.ly/1hDyq4X">http://bit.ly/1hDyq4X</a>.
          <br>
          <br>
          <br>
          <br>
          Am 03.04.2014 um 02:50 schrieb Eleanor Selfridge-Field
          <a class="moz-txt-link-rfc2396E" href="mailto:esfield@stanford.edu"><esfield@stanford.edu></a>:
          <br>
          <br>
          <blockquote type="cite">"Provenance" is a standard item in
            catalogues of works in manuscript, but
            <br>
            it has a range of meanings, all of which might comfortable
            fit within
            <br>
            "history".  It sometimes identifies previously owners but
            equally often it
            <br>
            refers to a physical location (city, institution, performing
            group et
            <br>
            al.).
            <br>
            <br>
            Eleanor
            <br>
            <br>
            Eleanor Selfridge-Field
            <br>
            Consulting Professor, Music (and, by courtesy, Symbolic
            Systems)
            <br>
            Braun Music Center #129
            <br>
            Stanford University
            <br>
            Stanford, CA 94305-3076, USA
            <br>
            <a class="moz-txt-link-freetext" href="http://www.stanford.edu/~esfield/">http://www.stanford.edu/~esfield/</a>  +1/ 650 725-9242
            <br>
            <br>
            <br>
            -----Original Message-----
            <br>
            From: mei-l [<a class="moz-txt-link-freetext" href="mailto:mei-l-bounces@lists.uni-paderborn.de">mailto:mei-l-bounces@lists.uni-paderborn.de</a>] On
            Behalf Of
            <br>
            Johannes Kepper
            <br>
            Sent: Wednesday, April 02, 2014 2:39 AM
            <br>
            To: Music Encoding Initiative
            <br>
            Subject: [MEI-L] history of sources / items
            <br>
            <br>
            Dear list,
            <br>
            <br>
            while discussing the upcoming Weber Werkverzeichnis (Weber's
            work
            <br>
            catalogue) with Kristina Richts and Joachim Veit, I can't
            remember why we
            <br>
            dropped the <history> element from sources and items?
            We have it on works
            <br>
            and expressions, but not on these two. However, it might be
            interested to
            <br>
            write something about the creation of a source (which is not
            the same as
            <br>
            the provenance, which is available). Can someone please
            remind me of our
            <br>
            argument to drop it? Otherwise, it would be a fault that we
            might want to
            <br>
            correct.
            <br>
            <br>
            Btw., <bibl> seems to be equally hidden (you can get
            it from source at
            <br>
            source/physDesc/physMedium/bibl.).
            <br>
            <br>
            Best,
            <br>
            Johannes
            <br>
            <br>
            _______________________________________________
            <br>
            mei-l mailing list
            <br>
            <a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
            <br>
            <a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
            <br>
          </blockquote>
          <br>
          _______________________________________________
          <br>
          mei-l mailing list
          <br>
          <a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
          <br>
          <a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
          <br>
        </blockquote>
        <br>
        _______________________________________________
        <br>
        mei-l mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
        <br>
        <a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
        <br>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>