[MEI-L] FW: changes to <eventList> and <event>
Johannes Kepper
kepper at edirom.de
Tue Nov 10 00:19:55 CET 2015
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
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 496 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151110/ec254d1e/attachment.sig>
More information about the mei-l
mailing list