From atge at kb.dk  Thu Apr 14 10:04:51 2016
From: atge at kb.dk (Axel Teich Geertinger)
Date: Thu, 14 Apr 2016 08:04:51 +0000
Subject: [mei-catalog-ig] Proposed changes to <event> in MEI 3.0.0
In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D1013FA0ADC0@EXCHANGE-03.kb.dk>
References: <0B6F63F59F405E4C902DFE2C2329D0D1013FA07F16@EXCHANGE-03.kb.dk>
 <BBCC497C40D85642B90E9F94FC30343D9D52E961@grant1.eservices.virginia.edu>,
 <0B6F63F59F405E4C902DFE2C2329D0D1013FA091E6@EXCHANGE-03.kb.dk>
 <BBCC497C40D85642B90E9F94FC30343D9D52EA5E@grant1.eservices.virginia.edu>
 <0B6F63F59F405E4C902DFE2C2329D0D1013FA0ADC0@EXCHANGE-03.kb.dk>
Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1014626E794@EXCHANGE-03.kb.dk>

Dear list

Perry and I have had a few more takes on the <event> content model since we started this discussion. We arrived at suggesting the following <event> content model for the proposed MEI 3.0.0 specification:

<element name="event">
   <zeroOrMore>
      <ref name="mei_model.headLike"/>
   </zeroOrMore>
   <choice>
      <zeroOrMore>
         <choice>
            <ref name="mei_model.eventPart"/>
            <ref name="mei_castList"/>
            <ref name="mei_eventList"/>
         </choice>
      </zeroOrMore>
      <zeroOrMore>
         <choice>
            <ref name="mei_model.pLike"/>
            <ref name="mei_model.tableLike"/>
            <ref name="mei_list"/>
         </choice>
      </zeroOrMore>
   </choice>
   <zeroOrMore>
      <ref name="mei_biblList"/>
   </zeroOrMore>
   <ref name="mei_att.bibl.attributes"/>
   <ref name="mei_att.calendared.attributes"/>
   <ref name="mei_att.common.attributes"/>
   <ref name="mei_att.datable.attributes"/>
   <ref name="mei_att.edit.attributes"/>
   <ref name="mei_att.facsimile.attributes"/>
   <ref name="mei_att.lang.attributes"/>
   <ref name="mei_att.typed.attributes"/>
   <empty/>
</element>

... roughly meaning that basically there will be two options: A rather structured approach consisting of the elements included in the eventPart model, cast list(s), and/or nested event list(s). The eventPart model now includes these elements:

<define name="mei_model.eventPart">
   <choice>
      <ref name="mei_model.addressLike"/>
      <ref name="mei_model.dateLike"/>
      <ref name="mei_desc"/>
      <ref name="mei_name"/>
      <ref name="mei_model.nameLike.agent"/>
      <ref name="mei_model.nameLike.geogName"/>
   </choice>
</define>

In addition to the database-like elements like names, places, and dates, the (semi-)structured approach thus allows a (short) descriptive text in a <desc> element.
The other option is a rather free, that is, text-like approach including any number of paragraphs of text, tables and lists.

>From my point of view this is a useful solution. Please let us know if you see any problems.

Best,
Axel


Fra: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-paderborn.de] På vegne af Axel Teich Geertinger
Sendt: 17. marts 2016 09:33
Til: MEI Metadata and Cataloging Interest Group
Emne: Re: [mei-catalog-ig] Proposed changes to <event> in MEI 3.0.0

Yes, sounds good to me! :-)
Thanks.

/axel

Fra: mei-catalog-ig [mailto:mei-catalog-ig-bounces+atge=kb.dk at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h)
Sendt: 16. marts 2016 19:27
Til: MEI Metadata and Cataloging Interest Group
Emne: Re: [mei-catalog-ig] Proposed changes to <event> in MEI 3.0.0


Just a quick response --

Not finding multiple <p> elements in anyone's usage of <event> was one of the reasons I went ahead with the change.

Sounds like we're agreed on using <desc> instead of <label>.  Here's what I have in mind --

<element name="event">
   <optional>
      <ref name="mei_model.headLike"/>
   </optional>
   <choice>
      <zeroOrMore>
         <ref name="mei_model.eventPart"/>
      </zeroOrMore>
      <zeroOrMore>
         <choice>
            <ref name="mei_model.pLike"/>
            <ref name="mei_model.tableLike"/>
            <ref name="mei_castList"/>
            <ref name="mei_eventList"/>
            <ref name="mei_list"/>
         </choice>
      </zeroOrMore>
   </choice>
   <zeroOrMore>
      <ref name="mei_biblList"/>
   </zeroOrMore>
   <ref name="mei_att.bibl.attributes"/>
   <ref name="mei_att.calendared.attributes"/>
   <ref name="mei_att.common.attributes"/>
   <ref name="mei_att.datable.attributes"/>
   <ref name="mei_att.edit.attributes"/>
   <ref name="mei_att.facsimile.attributes"/>
   <ref name="mei_att.lang.attributes"/>
   <ref name="mei_att.typed.attributes"/>
   <empty/>
</element>

that is, a return to using <head> at the top of <event> and adding <desc> as a member of model.eventPart.  Just to be absolutely clear, allowing multiple <desc> elements is intended to accommodate multiple languages, not multi-part descriptions.

Sound good?

--
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-catalog-ig [mei-catalog-ig-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk]
Sent: Wednesday, March 16, 2016 12:24 PM
To: MEI Metadata and Cataloging Interest Group
Subject: Re: [mei-catalog-ig] Proposed changes to <event> in MEI 3.0.0
Hi Perry

MerMEId has never been set up to allow more than a single <p> within <event>, so at least among MerMEId users I am pretty sure no-one has actually produced events containing several paragraphs. From this perspective, a single element allowing mixed content would be fine. But I still think there is need for something else than <label> (or <head>). To me, both 'label' and 'head' signify something that goes before or above the text/data, like 'Label: Data'.
I am not convinced that the text in my example is in fact a label. I at least don't think of it that way. In MerMEId, the corresponding input is labeled 'Description', indicating the intention we had. In the context of <provenance> we provide two input fields: one for the date of the event and one for the 'Description'. What I had in mind was an output like:

2016-03-16: [Description of the event]

For the description, we give the example 'Purchased by The Royal Library from John Doe'. That's not really a label for the date, is it? I'd definitely prefer adding <desc> (which I think is also a much better name than the layout-oriented <p>); then I'd be perfectly happy with the 'structured' choice.

As to the label/head name: Technically, renaming <head> to <label> is no problem, of course. Semantically I don't really see the difference, so I just wonder why we need to break compatibility at that point. But if you prefer renaming it to <label> then go ahead :-)

Oh, watching the repo... Well. Here comes the embarrassing part: I still haven't figured out how to work with GitHub. SVN was manageable, but Git goes beyond my abilities. I vaguely understand the principle, but I haven't found a way to work with it that actually works for me. I also tried several tools but had to give it up every time because I realized that I really don't know what I am doing - or what I am supposed to do. Sorry, but I've given up on it.

Suddenly feeling old,
Axel


Fra: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h)
Sendt: 16. marts 2016 16:02
Til: MEI Metadata and Cataloging Interest Group
Emne: Re: [mei-catalog-ig] Proposed changes to <event> and <history> in MEI 3.0.0


Hi Axel,

In your example I think the text "Concert for the benefit of the poor. First performance." is in fact a label for data provided in the <date>, <geogName>, and <persName> elements.  Perhaps I wasn't as thorough as I could have been, but in my examination of the way <event> has been used (by you and others), I didn't find any use of <p> that made it significantly different from <label>.  In all cases I saw, the <p> element contained fairly short text strings without any other internal structure common to paragraphs, such as line breaks, internal lists, etc.  In addition, the name "paragraph" usually implies a certain presentation, often as a distinct block of text , that I believe doesn't apply in this case.

In spite of my earlier statement, I now think it *is* important to draw a distinction between structured and unstructured content for <event>.  Leaving the parsing/teasing apart a mixed model to a downstream processor is not a good choice.  As painful as it might be now, I'd rather have the choice made at the time of encoding rather than at the point of publishing/rendering.

I agree that using <desc> as a grouping mechanism for multiple <p> elements or adding a grouping element for multiple <desc> children isn't necessary.  I would also add that if we agree that "grouping 'loose' paragraphs mixed in between the more 'data-like' elements" tends "to make the encoding quite messy", then we should also agree that allowing even a single paragraph between data-like elements is just as messy.

Thanks for speaking up.  Believe me, I struggled with this quite a bit.  I'm sorry I didn't consult you directly.  I naively thought that you were watching the GitHub repo and that your silence indicated agreement with the proposed changes.  Although I am a little wary of the pressure it might create to add <desc> in many other places, I'm not completely opposed to adding <desc> to model.eventPart, where <desc> has the same content model as <label>.  This would allow us to "have our cake and it eat it too"; that is, allow a somewhat more expansive description within an otherwise database-like model for <event> while simultaneously permitting an unstructured (or, if you will, more loosely structured) model.  The most important thing for me is to avoid the ambiguous content model that is created when <p> is part of both options.  By the way, to minimize the amount of change we could even go back to using <head> instead of <label>. :-)

There's still time to make these changes before the official release, I think.  But, I will defer to Johannes, who's in the process of preparing the Guidelines, web site, etc.

--
p.



From: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-paderborn.de<redir.aspx?REF=QTCkjsXf1j47mM0GmbQHh8cQ5oaBg1u03hX18fbCZ-uktoPRxk3TCAFtYWlsdG86bWVpLWNhdGFsb2ctaWctYm91bmNlc0BsaXN0cy51bmktcGFkZXJib3JuLmRl>] On Behalf Of Axel Teich Geertinger
Sent: Wednesday, March 16, 2016 5:22 AM
To: 'mei-catalog-ig at lists.uni-paderborn.de'
Subject: [mei-catalog-ig] Proposed changes to <event> and <history> in MEI 3.0.0


Hi Perry & metadata group



Finally I have found some time to review the proposed changes to the header in the MEI 3.0.0 pre-release. I noticed a change in the <event> model that I'd like to ask about. It has to do with the combination of structured and non-structured content. In our discussion in November (below) we were focusing on the grouping of events within event lists. This has been implemented in the new schema as agreed. No problem. In your original post you also addressed the content of the <event> model (semi-structured vs. non-structured). I am sorry that I didn't respond to that earlier.



The current schema (2.1.0) has the following model for <event>:



<element name="event">
   <optional>
      <ref name="model.headLike"/>
   </optional>
   <zeroOrMore>
      <choice>
         <ref name="model.eventPart"/>
         <ref name="model.pLike"/>
         <ref name="model.tableLike"/>
         <ref name="list"/>
         <ref name="castList"/>
      </choice>
   </zeroOrMore>
   <zeroOrMore>
      <ref name="biblList"/>
   </zeroOrMore>
   <ref name="att.bibl.attributes"/>
   <ref name="att.calendared.attributes"/>
   <ref name="att.common.attributes"/>
   <ref name="att.datable.attributes"/>
   <ref name="att.edit.attributes"/>
   <ref name="att.lang.attributes"/>
   <empty/>
</element>



whereas the proposed 3.0.0 schema has



<element name="event">
   <optional>
      <ref name="mei_model.labelLike"/>
   </optional>
   <choice>
      <zeroOrMore>
         <ref name="mei_model.eventPart"/>
      </zeroOrMore>
      <zeroOrMore>
         <choice>
            <ref name="mei_model.pLike"/>
            <ref name="mei_model.tableLike"/>
            <ref name="mei_castList"/>
            <ref name="mei_eventList"/>
            <ref name="mei_list"/>
         </choice>
      </zeroOrMore>
   </choice>
   <zeroOrMore>
      <ref name="mei_biblList"/>
   </zeroOrMore>
   <ref name="mei_att.bibl.attributes"/>
   <ref name="mei_att.calendared.attributes"/>
   <ref name="mei_att.common.attributes"/>
   <ref name="mei_att.datable.attributes"/>
   <ref name="mei_att.edit.attributes"/>
   <ref name="mei_att.facsimile.attributes"/>
   <ref name="mei_att.lang.attributes"/>
   <ref name="mei_att.typed.attributes"/>
   <empty/>
</element>



You and I had a private discussion about this in February/March 2013. Your conclusion then was:



>I now think the best course of action is not to try to create two choices (semi-structured vs. free),

>but rather to return to intermingling the elements of both options and letting the chips fall where they may.



Then why did we end up having to choose between the two approaches now? If I have forgotten or overlooked something, please remind me.



It causes me problems because personally, and because of the way MerMEId works, I prefer a rather structured approach. However, I still would like to be able to add an explanatory or descriptive text to the event also. The new <label> doesn't seem to be the right place. Back in 2013 you suggested adding a <desc> element to the event model, and that would be just fine. A <label> is described as 'a text that identifies the feature to which it is attached'. That's something quite different, isn't it? Why not <desc>?



Basically, I would prefer not having to choose either a structured or a non-structured model. I am quite fond of this combination of some basic, precisely defined, 'data-like' information and some prose added to it. We use it all the time.



The suggested <event> model prevents me for from this kind of use both when listing performances within <history> and when describing source transmission in <provenance>. In both cases I have some quite well-defined information such as the date and the persons involved, and some descriptive text.



An example. Here's a performance encoded as an MEI 2.1.0 event:



<event xml:id="event_d1e66836522">
    <date isodate="1846-03-23">23 March 1846</date>
    <geogName role="venue" xml:id="geogName_d910d5f3">Gewandhaus</geogName>
    <geogName role="place" xml:id="geogName_b69c0299">Leipzig</geogName>

    <persName role="conductor" xml:id="persName_b598dc1e">Gade</persName>
    <persName role="soloist" xml:id="persName_ed9dabab">Franziska Schwarzbach</persName>
    <p xml:id="p_4222N215DA">Concert for the benefit of the poor. First performance.</p>
    <biblList xml:id="listBibl_65b1553d-ff51-420d-aea3-a335d66069d06553">
       <head>Reviews</head>
       <bibl xml:id="bibl_d1e67206558">
            <genre>article</genre>
            <genre>journal</genre>
            <title level="j">Neue Zeitschrift für Musik</title>
            <imprint>
                <date isodate="1846-04-12">1846-04-12</date>
            </imprint>
            <biblScope unit="vol">30</biblScope>
            <biblScope unit="page">119-120</biblScope>
        </bibl>
    </biblList>
</event>



The <p> containing the descriptive text - which could be any length - would have to be converted to <label> in MEI 3.0.0, which doesn't sound quite right to me. And what if I have more than one <p>? There can be only one <label>. And above all: In what way does the existing <p> element - ruin the structuredness of the encoding more than <label> does? They both may contain mixed, that is, non-structured, content. So even with the new model, the 'structured' option is likely to contain non-structured information. I don't see that as a problem. Non-structured content can easily be ignored by software dealing with the structured parts only. So why bother changing the <event> model at all?



I do think that introducing a <desc> element or the like to wrap the potential unlimited number of paragraphs would be a good idea, though. Those 'loose' paragraphs mixed in between the more 'data-like' elements do tend to make the encoding quite messy. I'd be happy to have them wrapped in some container to isolate them from the other information.



Best, Axel





-----Oprindelig meddelelse-----
Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de<redir.aspx?REF=VTlrnYjkkM7Ws2KZkC9ntUXxmEax1nDl919RLgrbqycLGIbRxk3TCAFtYWlsdG86bWVpLWwtYm91bmNlcythdGdlPWtiLmRrQGxpc3RzLnVuaS1wYWRlcmJvcm4uZGU.>] På vegne af Roland, Perry D. (pdr4h)
Sendt: 13. november 2015 12:06
Til: Music Encoding Initiative
Emne: Re: [MEI-L] FW: changes to <eventList> and <event>



Hi Axel,



I'm happy we could reach consensus on this.  Unless I hear objections in the next couple of days, I'll go ahead with this change.



--

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 Axel Teich Geertinger [atge at kb.dk]

Sent: Friday, November 13, 2015 3:53 AM

To: Music Encoding Initiative

Subject: Re: [MEI-L] FW: changes to <eventList> and <event>



Hi Perry



Your eventList model looks fine to me.



/axel





-----Oprindelig meddelelse-----

Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de<redir.aspx?REF=VTlrnYjkkM7Ws2KZkC9ntUXxmEax1nDl919RLgrbqycLGIbRxk3TCAFtYWlsdG86bWVpLWwtYm91bmNlcythdGdlPWtiLmRrQGxpc3RzLnVuaS1wYWRlcmJvcm4uZGU.>] På vegne af Roland, Perry D. (pdr4h)

Sendt: 11. november 2015 17:43

Til: Music Encoding Initiative

Emne: Re: [MEI-L] FW: changes to <eventList> and <event>





Hi Axel,



I was coming to a similar conclusion, so thanks for proposing a compromise solution.  Your model of eventGrp, however, doesn't allow for continued nesting of <eventGrp> elements.  So, I'd like to counter with the following models which merge eventList and eventGrp into a single entity --



For eventList:



<content>

  <rng:zeroOrMore>

    <rng:ref name="model.headLike"/>

  </rng:zeroOrMore>

  <rng:zeroOrMore>

    <rng:group>

      <!-- an organizing data element  -->

      <rng:optional>

        <rng:ref name="model.eventPart"/>

      </rng:optional>

      <!-- an event description or another list of events -->

      <rng:choice>

      <rng:ref name="event"/>

        <rng:ref name="eventList"/>

      </rng:choice>

    </rng:group>

  </rng:zeroOrMore>

  <!-- at the very end, lists of citations -->

  <rng:zeroOrMore>

    <rng:ref name="biblList"/>

  </rng:zeroOrMore>

</content>



For event:



<content>

  <rng:optional>

    <rng:ref name="model.labelLike"/>

  </rng:optional>

<rng:choice>

    <!-- data-like organization -->

    <rng:zeroOrMore>

      <rng:choice>

        <rng:ref name="model.eventPart"/>

        <rng:ref name="eventList"/>

      </rng:choice>

    </rng:zeroOrMore>

    <!-- free-form organization -->

    <rng:zeroOrMore>

      <rng:choice>

        <!-- model.listLike is expanded here in order to disallow biblList -->

        <rng:ref name="model.pLike"/>

        <rng:ref name="model.tableLike"/>

        <rng:ref name="castList"/>

        <rng:ref name="eventList"/>

        <rng:ref name="list"/>

      </rng:choice>

    </rng:zeroOrMore>

  </rng:choice>

  <rng:zeroOrMore>

<rng:ref name="biblList"/>

  </rng:zeroOrMore>

</content>



By making the "grouping key" optional, the model of <eventList> does allow for mixing of events grouped on a date, place, person, etc. and a "simple" list of events, but I see that as a good thing, not an impediment.  This makes it possible to eliminate <eventGrp> and matches the behavior of other list-like structures (where a list contains a mixture of item and subordinate lists).  Most importantly, the model of <event> now meets the original goal -- a clear distinction between a database-like approach to recording the event description and a free-text approach.



I've removed the <listHead> formatting element.  We can always take that up again at a later date.  I still maintain that they're useful, but I'll also forego the @mark and @order formatting attributes.  That battle can wait, too.



--

p.





> -----Original Message-----

> From: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-

> paderborn.de] On Behalf Of Axel Teich Geertinger

> Sent: Tuesday, November 10, 2015 8:10 AM

> To: Music Encoding Initiative

> Cc: mei-catalog-ig at lists.uni-paderborn.de<redir.aspx?REF=4p1o0o0yjs_E7hwTHFZvnc3fkKIuL4lznypxqwRIP2cLGIbRxk3TCAFtYWlsdG86bWVpLWNhdGFsb2ctaWdAbGlzdHMudW5pLXBhZGVyYm9ybi5kZQ..>

> Subject: Re: [mei-catalog-ig] [MEI-L] FW: changes to <eventList> and

> <event>

>

> Hi Johannes & Perry

>

> This discussion is started on both MEI-L and MEI-Catalog-IG; I'm

> posting my reply to both lists, but in order not to exclude anyone now

> I suggest we continue the discussion on MEI-L only.

>

> I agree with Johannes that an alternating sequence of date and event

> elements would be a way of looking for trouble. If I want to delete an

> event or change the order of events, I would have to make sure always

> to do the same with the preceding date sibling. If there is any. I

> would definitely prefer being able to address an event or group of

> events as a single element without having to care about any siblings.

> Also, Perry's model (if I read your suggestion correctly) implies that

> it would not be possible to have an <event> without a preceding

> <date>. But we are not always able to date events. Even if <date>

> could be left empty, the construct would seem somehow awkward to me.

> Finally, from a purely practical perspective, the way we handle

> elements would make it a pain to maintain and edit such a list of alternating elements.

>

> If we are introducing <eventGrp>, we have a clear way of

> distinguishing a list of events (that is, a possibly unordered,

> non-grouped <eventList>) from a group of events that have something in

> common. Let's not mix them up. If we want to group events by date, we

> could do so by allowing <date> or any eventPart element within <eventGrp> (but not in <eventList>):

>

> <eventList>

>   <event><!-- some single event --></event>

>   <eventGrp>

>     <!-- a group of events -->

>     <date><!-- the grouping parameter - could also be geogName etc.

> instead -

> -></date>

>     <event><!-- event 1 --></event>

>     <event><!-- event 2 etc. --></event>

>   </eventGrp>

> </eventList>

>

> Alternatively, the @isodate approach could be used on <eventGrp>.

>

> /axel

>

> -----Oprindelig meddelelse-----

> Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de<redir.aspx?REF=VTlrnYjkkM7Ws2KZkC9ntUXxmEax1nDl919RLgrbqycLGIbRxk3TCAFtYWlsdG86bWVpLWwtYm91bmNlcythdGdlPWtiLmRrQGxpc3RzLnVuaS1wYWRlcmJvcm4uZGU.>] På

> vegne af Johannes Kepper

> Sendt: 10. november 2015 00:20

> Til: Music Encoding Initiative

> Emne: Re: [MEI-L] FW: changes to <eventList> and <event>

>

> Hi Perry,

>

> I understand (and fully support) your motivation to clean up events.

> However, could you please refresh my memory and indicate the current /

> planned content of event? Maybe I understand your proposal to move all

> these things out of events better with that model in mind. As you

> know, we use even annots in a data-like way, and while I agree that

> both annots and events are perfectly valid to take free-form content,

> I'm still in love with structured things - maybe just a couple of

> attributes. Or would it be an alternative to provide separate elements

> for free-form and structured content, like <annot> and <annotStruct> or <event> and <eventStruct>?

>

> Just guessing.

> jo

>

>

> Am 09.11.2015 um 23:56 schrieb Roland, Perry D. (pdr4h)

> <pdr4h at eservices.virginia.edu<redir.aspx?REF=7XAu6VvCFqNmnP5hpouIrL2ivGvWtJQrQbOqb1jbkwULGIbRxk3TCAFtYWlsdG86cGRyNGhAZXNlcnZpY2VzLnZpcmdpbmlhLmVkdQ..>>:

>

> >

> > Our current handling of <eventList> is a mess, which reduces its

> > effectiveness for data interchange and interoperability.  Clarifying

> > its possible content can counteract this tendency.  It's relatively

> > easy to provide alternative grouping mechanisms.  For instance, a

> > content model for <eventList> like --

> >

> > <content>

> >  <rng:zeroOrMore>

> >    <rng:ref name="model.headLike"/>

> >  </rng:zeroOrMore>

> >  <rng:optional>

> >    <rng:ref name="listHead"/>

> >  </rng:optional>

> >  <rng:zeroOrMore>

> >    <rng:group>

> >      <rng:choice>

> >        <rng:ref name="model.eventPart"/>

> >      </rng:choice>

> >      <rng:choice>

> >        <rng:ref name="event"/>

> >        <rng:ref name="eventGrp"/>

> >      </rng:choice>

> >    </rng:group>

> >  </rng:zeroOrMore>

> >  <rng:zeroOrMore>

> >    <rng:ref name="biblList"/>

> >  </rng:zeroOrMore>

> > </content>

> >

> > would allow any member of model.eventPart to act as the organizing

> > "term".  For instance,

> >

> > <eventList>

> >  <date><!-- date of event --></date>

> >  <event><!-- event description --></event>

> >  <!-- and so on -->

> > </eventList>

> >

> > or

> >

> > <eventList>

> >  <geogName><!-- place of event --></geogName>

> >  <event><!-- event description --></event>

> >  <!-- and so on -->

> > </eventList>

> >

> > or

> >

> > <eventList>

> >  <persName><!-- personal name, of conductor for example --

> ></persName>

> >  <event><!-- event description --></event>

> >  <!-- and so on -->

> > </eventList>

> >

> > are all possible.  This is the essentially the model used by HTML

> > for <dl>, by

> EAD for <chronlist>, and by TEI for <list> of @type "gloss".  The

> difficulty, of course, is ensuring that each event in a list is

> preceded by the same kind of element.  I'm not sure if this is

> possible using RNG alone, but it can certainly be enforced using Schematron.

> >

> > --

> > p.

> >

> >

> >> -----Original Message-----

> >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<redir.aspx?REF=4mcsmYr3jFTRyQdFq94Jz27B8457V7mf2GA-fgNjr_MLGIbRxk3TCAFtYWlsdG86bWVpLWwtYm91bmNlc0BsaXN0cy51bmktcGFkZXJib3JuLmRl>] On Behalf

> >> Of Johannes Kepper

> >> Sent: Monday, November 09, 2015 4:40 PM

> >> To: Music Encoding Initiative

> >> Subject: Re: [MEI-L] FW: changes to <eventList> and <event>

> >>

> >>

> >> Am 09.11.2015 um 22:28 schrieb Roland, Perry D. (pdr4h)

> >> <pdr4h at eservices.virginia.edu<redir.aspx?REF=7XAu6VvCFqNmnP5hpouIrL2ivGvWtJQrQbOqb1jbkwULGIbRxk3TCAFtYWlsdG86cGRyNGhAZXNlcnZpY2VzLnZpcmdpbmlhLmVkdQ..>>:

> >>

> >>>

> >>> An <eventGrp> element containing <event> with the current model

> >>> makes

> >> no sense as there's no indication of the grouping criterion.  The

> >> <date> followed by <eventGrp> construct makes it clear that the

> >> events are grouped by date.  In fact, that's the only way to group

> >> them

> using this model.

> >>

> >> Ok, what constitutes a group of events? What does it mean to have

> >> events grouped? Is there any other grouping mechanism other than by

> >> date? Does it make sense to have events grouped by place? If so,

> >> why don't we factor in groups (by date, for instance) and subgroups

> >> (by place)? Or is it maybe better to let the grouping be done by

> >> applications, based on structured markup like @isodate, @resp,

> >> @type

> and similar options?

> >>

> >>>

> >>> It is nothing like the concept of chords that you raise.

> >>

> >> I need to look into the preceding sibling to fully understand the

> >> current element...

> >>

> >>> Order is a good thing here as it makes the structure of the data clear.

> >>>

> >>

> >> jo

> >>

> >>> --

> >>> p.

> >>>

> >>>

> >>>> -----Original Message-----

> >>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<redir.aspx?REF=gNXfP_sSizw7CzwdZIwgnyljYrlu28NC4dgYaOh8ktpyeYjRxk3TCAFtYWlsdG86bWVpLWwtYm91bmNlc0BsaXN0cy51bmktcGFkZXJib3JuLmRl>] On

> >>>> Behalf Of Johannes Kepper

> >>>> Sent: Monday, November 09, 2015 4:20 PM

> >>>> To: Music Encoding Initiative

> >>>> Subject: Re: [MEI-L] FW: changes to <eventList> and <event>

> >>>>

> >>>> I'm sorry to say, but I'm not convinced by this one either. I see

> >>>> the point to have an eventGroup element, but everything else

> >>>> seems rather dubious to me. By all means, I would like to keep

> >>>> the date inside events, even for free- form text-driven events

> >>>> (in contrast to data-driven events). Also, I hate the idea to

> >>>> have an alternation of events and something, and have to rely on

> >>>> document order to understand the meaning of something - this gets

> >>>> pretty close to MusicXML's concept of chords, doesn't it? Are

> >>>> there any real-world limitations that motivate this proposal? If

> >>>> so, could we discuss it with

> >> those examples on the table?

> >>>>

> >>>> jo

> >>>>

> >>>>

> >>>> Am 09.11.2015 um 22:07 schrieb Roland, Perry D. (pdr4h)

> >>>> <pdr4h at eservices.virginia.edu<redir.aspx?REF=fURQOiTQIIkfg7MHtf8-6lOrLjfABgO8ynrEjBiX4VFyeYjRxk3TCAFtYWlsdG86cGRyNGhAZXNlcnZpY2VzLnZpcmdpbmlhLmVkdQ..>>:

> >>>>

> >>>>>

> >>>>> I sent this message to the cataloging interest group list earlier.

> >>>>> I apologize if

> >>>> you receive it twice, but I thought it would be a good idea to

> >>>> post to this list as well in the interest of generating as much

> >>>> discussion as

> >> possible.

> >>>>>

> >>>>> BTW, this is not a new feature, but rather a remedy for an

> >>>>> existing bug. But

> >>>> I think it's finally squashed this time.

> >>>>>

> >>>>> --

> >>>>> p.

> >>>>>

> >>>>>

> >>>>> From: Roland, Perry D. (pdr4h)

> >>>>> Sent: Monday, November 09, 2015 3:46 PM

> >>>>> To: 'mei-catalog-ig at lists.uni-paderborn.de'

> >>>>> Subject: changes to <eventList> and <event>

> >>>>>

> >>>>>

> >>>>> I know we've had a few rounds of discussion about the content

> >>>>> models of

> >>>> <eventList> and <event> in the past.  I think there are basically

> >>>> 2 issues currently facing us:

> >>>>>

> >>>>> *       eventList contains a bug that doesn't allow grouping events that

> >> share

> >>>> the same date

> >>>>> *       the model of event is too vague

> >>>>>

> >>>>> I propose to remedy the first problem by using the following

> >>>>> content model

> >>>> for <eventList>:

> >>>>>

> >>>>> eventList   (head*, listHead?, (date, (event | eventGrp))*, biblList*)

> >>>>>

> >>>>> By placing <date> outside the model of <event>, the main content

> >>>>> of <eventList> can be constrained to be any number of pairs of

> >>>>> <date> and <event> elements, like so -

> >>>>>

> >>>>> <eventList>

> >>>>> <date><!-- when "it" happened --></date>

> >>>>> <event><!-- what happened -->

> >>>>> <date><!-- another happening --></date>

> >>>>> <event><!-- another description -->

> >>>>> <!-- and so on -->

> >>>>> </eventList>

> >>>>>

> >>>>> Or, when multiple events share the same date, like so --

> >>>>>

> >>>>> <eventList>

> >>>>> <date><!-- the date --></date>

> >>>>> <eventGrp>  <!-- the events occurring on the date -->

> >>>>>   <event>Event 1</event>

> >>>>>  <event> Event 2</event>

> >>>>>  <!-- and so on -->

> >>>>> </eventGrp>

> >>>>> </eventList>

> >>>>>

> >>>>> The new model also introduces listHead, a new formatting element.

> >>>>> <listHead> contains a pair of <head> elements, one for each

> >>>>> column in the eventList date-event pair.  This makes it possible

> >>>>> to treat the list of events as though it were a table with a

> >>>>> column heading for the dates and a heading for the descriptions.

> >>>>> Of course, eventList/head continues to contain a heading for the

> >>>>> entire list

> >>>>> --

> >>>>>

> >>>>> <eventList>

> >>>>> <head>My List o' Special Events</head>  <listHead>

> >>>>>   <head>When</head>

> >>>>> <head>What</head>

> >>>>> </listHead>

> >>>>> <event/>

> >>>>> <event/>

> >>>>> </eventList>

> >>>>>

> >>>>> I plan to investigate how this might work for other lists as

> >>>>> well, such as

> >>>> <biblList>, <castList>, and <list>.  Any list that allows a label

> >>>> preceding its "items" could benefit from this treatment, I think.

> >>>>>

> >>>>> One more change -- <eventList> is now a member of

> >>>>> model.listLike,

> >>>> meaning it can occur not just in the header but anywhere a "regular"

> >>>> list can happen.

> >>>>>

> >>>>> The <event> element now has the following model (switching to

> >>>>> RNG as it's somewhat clearer than DTD syntax) --

> >>>>>

> >>>>> <content>

> >>>>> <rng:optional>

> >>>>>   <rng:ref name="model.labelLike"/>  </rng:optional>  <rng:choice>

> >>>>>   <!-- data-like organization -->

> >>>>>   <rng:zeroOrMore>

> >>>>>     <rng:choice>

> >>>>>       <rng:ref name="model.eventPart"/>

> >>>>>       <rng:ref name="eventList"/>

> >>>>>     </rng:choice>

> >>>>>   </rng:zeroOrMore>

> >>>>>   <!-- free-form organization -->

> >>>>>   <rng:zeroOrMore>

> >>>>>     <rng:choice>

> >>>>>       <!-- model.listLike is expanded here in order to disallow biblList -->

> >>>>>       <rng:ref name="model.pLike"/>

> >>>>>       <rng:ref name="model.tableLike"/>

> >>>>>       <rng:ref name="castList"/>

> >>>>>       <rng:ref name="eventList"/>

> >>>>>       <rng:ref name="list"/>

> >>>>>     </rng:choice>

> >>>>>   </rng:zeroOrMore>

> >>>>> </rng:choice>

> >>>>> <rng:zeroOrMore>

> >>>>>   <rng:ref name="biblList"/>

> >>>>> </rng:zeroOrMore>

> >>>>> </content>

> >>>>>

> >>>>> English translation is "an optional label, followed by EITHER

> >>>>> some data-like

> >>>> elements or nested eventLists OR any number of paragraphs,

> >>>> tables, castLists, eventLists, or lists, followed by any number

> >>>> of lists of bibliographic citations."

> >>>>>

> >>>>> The central choice (a data-centric organization OR a free-form

> >>>>> text

> >>>>> one) is the important factor here.  In purely practical terms,

> >>>>> any file that formerly used a group of data elements followed by

> >>>>> a paragraph will have to be translated into --

> >>>>>

> >>>>> <event>

> >>>>> <label><!-- former paragraph content -->  <geogName/><persName/>

> >>>>> <!-- etc. --> </event>

> >>>>>

> >>>>> This element re-naming and re-ordering is not a difficult task

> >>>>> and can be

> >>>> made part of the 2013 -> 2015 XSLT transformation.  If the

> >>>> re-ordering poses a significant issue (that is, you *must* have

> >>>> the data elements followed by the label), I think it's not a

> >>>> problem to allow

> >> that, but please let me know.

> >>>>>

> >>>>> As always, I apologize for the length of the message and the XML

> >>>>> "gobbledy-gook".  I just don't know of any other way to communicate.

> >>>>> ;-)

> >>>>>

> >>>>> --

> >>>>> p.

> >>>>>

> >>>>> ________________________________ Perry Roland University of

> >>>>> Virginia P. O. Box 400874 Charlottesville, VA, 22904

> >>>>> 434-982-2702 (w)

> >>>>> pdr4h (at) virginia (dot) edu

> >>>>>

> >>>>> _______________________________________________

> >>>>> mei-l mailing list

> >>>>> mei-l at lists.uni-paderborn.de<redir.aspx?REF=Kagr97-GvkdDMN3EWz5VK-ysH6o7N4e8byTP_QBtXzJyeYjRxk3TCAFtYWlsdG86bWVpLWxAbGlzdHMudW5pLXBhZGVyYm9ybi5kZQ..>

> >>>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l<redir.aspx?REF=d-tSJaieKUjeOF_MPKChMcJLCRFHilMH3wtp-SOZnylyeYjRxk3TCAFodHRwczovL2xpc3RzLnVuaS1wYWRlcmJvcm4uZGUvbWFpbG1hbi9saXN0aW5mby9tZWktbA..>

> >>>

> >>>

> >>> _______________________________________________

> >>> mei-l mailing list

> >>> mei-l at lists.uni-paderborn.de<redir.aspx?REF=Kagr97-GvkdDMN3EWz5VK-ysH6o7N4e8byTP_QBtXzJyeYjRxk3TCAFtYWlsdG86bWVpLWxAbGlzdHMudW5pLXBhZGVyYm9ybi5kZQ..>

> >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l<redir.aspx?REF=d-tSJaieKUjeOF_MPKChMcJLCRFHilMH3wtp-SOZnylyeYjRxk3TCAFodHRwczovL2xpc3RzLnVuaS1wYWRlcmJvcm4uZGUvbWFpbG1hbi9saXN0aW5mby9tZWktbA..>

> >

> >

> > _______________________________________________

> > mei-l mailing list

> > mei-l at lists.uni-paderborn.de<redir.aspx?REF=Kagr97-GvkdDMN3EWz5VK-ysH6o7N4e8byTP_QBtXzJyeYjRxk3TCAFtYWlsdG86bWVpLWxAbGlzdHMudW5pLXBhZGVyYm9ybi5kZQ..>

> > https://lists.uni-paderborn.de/mailman/listinfo/mei-l<redir.aspx?REF=d-tSJaieKUjeOF_MPKChMcJLCRFHilMH3wtp-SOZnylyeYjRxk3TCAFodHRwczovL2xpc3RzLnVuaS1wYWRlcmJvcm4uZGUvbWFpbG1hbi9saXN0aW5mby9tZWktbA..>

>

>

> _______________________________________________

> mei-catalog-ig mailing list

> mei-catalog-ig at lists.uni-paderborn.de<redir.aspx?REF=0o2fKOtVR7IFILW_izgSVSw6n99Uwp9mlNxlXFMjdUdyeYjRxk3TCAFtYWlsdG86bWVpLWNhdGFsb2ctaWdAbGlzdHMudW5pLXBhZGVyYm9ybi5kZQ..>

> https://lists.uni-paderborn.de/mailman/listinfo/mei-catalog-ig<redir.aspx?REF=PMVeqbifuwWBLfKfCl6egXRmxDW9HJkmD3_buVbYUS9yeYjRxk3TCAFodHRwczovL2xpc3RzLnVuaS1wYWRlcmJvcm4uZGUvbWFpbG1hbi9saXN0aW5mby9tZWktY2F0YWxvZy1pZw..>

_______________________________________________

mei-l mailing list

mei-l at lists.uni-paderborn.de<redir.aspx?REF=Kagr97-GvkdDMN3EWz5VK-ysH6o7N4e8byTP_QBtXzJyeYjRxk3TCAFtYWlsdG86bWVpLWxAbGlzdHMudW5pLXBhZGVyYm9ybi5kZQ..>

https://lists.uni-paderborn.de/mailman/listinfo/mei-l<redir.aspx?REF=d-tSJaieKUjeOF_MPKChMcJLCRFHilMH3wtp-SOZnylyeYjRxk3TCAFodHRwczovL2xpc3RzLnVuaS1wYWRlcmJvcm4uZGUvbWFpbG1hbi9saXN0aW5mby9tZWktbA..>

_______________________________________________

mei-l mailing list

mei-l at lists.uni-paderborn.de<redir.aspx?REF=Kagr97-GvkdDMN3EWz5VK-ysH6o7N4e8byTP_QBtXzJyeYjRxk3TCAFtYWlsdG86bWVpLWxAbGlzdHMudW5pLXBhZGVyYm9ybi5kZQ..>

https://lists.uni-paderborn.de/mailman/listinfo/mei-l<redir.aspx?REF=d-tSJaieKUjeOF_MPKChMcJLCRFHilMH3wtp-SOZnylyeYjRxk3TCAFodHRwczovL2xpc3RzLnVuaS1wYWRlcmJvcm4uZGUvbWFpbG1hbi9saXN0aW5mby9tZWktbA..>



_______________________________________________

mei-l mailing list

mei-l at lists.uni-paderborn.de<redir.aspx?REF=Kagr97-GvkdDMN3EWz5VK-ysH6o7N4e8byTP_QBtXzJyeYjRxk3TCAFtYWlsdG86bWVpLWxAbGlzdHMudW5pLXBhZGVyYm9ybi5kZQ..>

https://lists.uni-paderborn.de/mailman/listinfo/mei-l<redir.aspx?REF=d-tSJaieKUjeOF_MPKChMcJLCRFHilMH3wtp-SOZnylyeYjRxk3TCAFodHRwczovL2xpc3RzLnVuaS1wYWRlcmJvcm4uZGUvbWFpbG1hbi9saXN0aW5mby9tZWktbA..>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20160414/0e44421b/attachment.html>

From klaus.rettinghaus at gmail.com  Mon Apr 25 17:27:21 2016
From: klaus.rettinghaus at gmail.com (Klaus Rettinghaus)
Date: Mon, 25 Apr 2016 17:27:21 +0200
Subject: [mei-catalog-ig] Repetition of <extend>
Message-ID: <CAB481HHpKO8hn46Q6F18rpDbsNn4epCH6HFadx1CbXQ8KSjKtQ@mail.gmail.com>

Hi there,
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20160425/8b860dd6/attachment.html>

From pdr4h at eservices.virginia.edu  Mon Apr 25 17:33:29 2016
From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h))
Date: Mon, 25 Apr 2016 15:33:29 +0000
Subject: [mei-catalog-ig] Repetition of <extend>
In-Reply-To: <CAB481HHpKO8hn46Q6F18rpDbsNn4epCH6HFadx1CbXQ8KSjKtQ@mail.gmail.com>
References: <CAB481HHpKO8hn46Q6F18rpDbsNn4epCH6HFadx1CbXQ8KSjKtQ@mail.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343DA50C642C@grant1.eservices.virginia.edu>


Hello Klaus,

Looks like you hit the send button just a little too soon!  :-)

--
p.


From: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-paderborn.de] On Behalf Of Klaus Rettinghaus
Sent: Monday, April 25, 2016 11:28 AM
To: mei-catalog-ig at lists.uni-paderborn.de
Subject: [mei-catalog-ig] Repetition of <extend>

Hi there,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20160425/6fd788ab/attachment.html>

From klaus.rettinghaus at gmail.com  Mon Apr 25 17:34:57 2016
From: klaus.rettinghaus at gmail.com (Klaus Rettinghaus)
Date: Mon, 25 Apr 2016 17:34:57 +0200
Subject: [mei-catalog-ig] Repetition of <extend>
Message-ID: <1461598497.3490.0@smtp.gmail.com>

Hi there again,

yes, Perry I did. :)

Is there any point of allowing <extend> multiple times in <item> and 
<source> but to limit it on one entity within <expression>?

What if you want to give information about the "extend" of a song in 
different "units" like bars, seconds and verses?

Klaus





From pdr4h at eservices.virginia.edu  Mon Apr 25 19:12:42 2016
From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h))
Date: Mon, 25 Apr 2016 17:12:42 +0000
Subject: [mei-catalog-ig] Repetition of <extend>
In-Reply-To: <1461598497.3490.0@smtp.gmail.com>
References: <1461598497.3490.0@smtp.gmail.com>
Message-ID: <BBCC497C40D85642B90E9F94FC30343DA50C686D@grant1.eservices.virginia.edu>


Hi Klaus,

There's no reason not to make it repeatable within <expression>.  However, this might provide a starting point for a discussion here about repeated elements within the header generally.  For instance, what other elements would it be useful to make repeatable and why?

--
p.


> -----Original Message-----
> From: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-
> paderborn.de] On Behalf Of Klaus Rettinghaus
> Sent: Monday, April 25, 2016 11:36 AM
> To: MEI Metadata and Cataloging Interest Group
> Subject: [mei-catalog-ig] Repetition of <extend>
> 
> Hi there again,
> 
> yes, Perry I did. :)
> 
> Is there any point of allowing <extend> multiple times in <item> and
> <source> but to limit it on one entity within <expression>?
> 
> What if you want to give information about the "extend" of a song in
> different "units" like bars, seconds and verses?
> 
> Klaus
> 
> 
> 
> 
> _______________________________________________
> mei-catalog-ig mailing list
> mei-catalog-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-catalog-ig