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

Axel Teich Geertinger atge at kb.dk
Tue Nov 10 14:09:17 CET 2015


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] 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>:

> 
> 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] 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>:
>> 
>>> 
>>> 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] 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>:
>>>> 
>>>>> 
>>>>> 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
>>>>> 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-catalog-ig mailing list