[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