[MEI-L] FW: changes to <eventList> and <event>
Roland, Perry D. (pdr4h)
pdr4h at eservices.virginia.edu
Mon Nov 9 23:56:23 CET 2015
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
More information about the mei-l
mailing list