[MEI-L] FW: changes to <eventList> and <event>
Axel Teich Geertinger
atge at kb.dk
Fri Nov 13 09:53:31 CET 2015
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] 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
> 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] 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
>
>
> _______________________________________________
> mei-catalog-ig mailing list
> mei-catalog-ig at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-catalog-ig
_______________________________________________
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-l
mailing list