[MEI-L] revision of content model of <instrumentation>

Mon Sep 21 17:41:02 CEST 2015

Another opportunity to clean up or clarify the markup surrounding performing forces -

Can we drop the att.coded class and use att.canonical?  In fact, I don't see a difference between these two classes and I'd like to eliminate att.coded.

The problem with doing so, however, as it was with the instrVoice* elements, may be a matter of naming rather than function.  Is dbkey (borrowed from TEI) a reasonable name for an attribute that essentially holds a coded value?  "dbkey" indicates a very specific kind of coded value, so the name is probably too narrow.  Would "code" or "codedvalue" be better, but now in the att.canonical class?  Would either of those names still fit the database key use, especially if the documentation was changed to read -

" a coded value that identifies the element content or serves as a primary key in an external database"?

--
p.

From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h)
Sent: Monday, September 21, 2015 9:29 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] revision of content model of <instrumentation>

Hi Axel,

I think that simplifying the model of <perfMedium> is highly desirable.  Your suggested change is fine with me.  Better than fine, I embrace it wholeheartedly.

I'd like to hear from others too.  But if we don't, then I'm fine with taking silence as tacit agreement.

--
p.

From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger
Sent: Monday, September 21, 2015 5:41 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] revision of content model of <instrumentation>

Hi Perry

Yes, there is a difference between a list and a group. I have no objections to putting soloists or a single player on a list, of course. I just don't want to call them a group; so your suggestion naming the elements <perfRes> and <perfResList> instead is fine with me.
If we decide to rename <instrVoice> and <instrVoiceGrp>, however, I suggest dropping <instrumentation>. Of course, 'instrumentation' is a name easier to understand than 'perfResList'; I am not sure whether that is a problem. But it seems misleading to me having <perfResList> inside <instrumentation>, as the former is a more generic term than the latter. Why not make it

<perfMedium>
    <castList/>
    <perfResList/> <!-- zero or one perfResList at this level -->
</perfMedium>

and allowing <head> and any number of <perfRes> and <perfResList> elements inside <perfResList>?

- if we do want to change the schema, that is. I'd really like to hear some more opinions on this.

Best,
Axel

Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h)
Sendt: 18. september 2015 16:15
Til: Music Encoding Initiative
Emne: Re: [MEI-L] revision of content model of <instrumentation>

Axel,

Adding the extra layer of markup -

<instrumentation>
    <instrVoiceGrp>
        <instrVoice>piano</instrVoice>
    </instrVoiceGrp>
</instrumentation>

isn't particularly onerous since it's relatively easy to automate.  I'm also not particularly troubled by a list containing a single item.  To me, it's still a list.

<instrumentation> doesn't necessarily become obsolete as it can still be used to separate information about non-dramatic performing forces from dramatic ones -

But, you're right, we could do without <instrumentation>.  Here's where we can eliminate a level of nesting.  That's a good thing, right?  "Instrumentation" isn't a particular good name for the enumeration of performance resources anyway.

My example 4 was just a demonstration of a markup possibility.  The next example, no. 5, does not attempt to group the soloists.  Even so, soloists are still part of the larger group - orchestra + chorus + soloists - that is expected to perform the work, are they not?

I guess that if you're not excited about those changes, then you really won't like the following suggestion -

I'd like to eliminate <ensemble> and fold its functionality into <instrVoice>, *BUT* rename <instrVoice> to <perfRes> (performance resource).  At the same time, <instrVoiceGrp> should be renamed <perfResList>.  This will eliminate the cognitive dissonance created between "Grp" and "ensemble" and "instrVoice".  In this new paradigm, an instrumentalist, a singer, and an ensemble are all "performance resources" and a bunch of these resources can be gathered into a "performance resource list".  In addition to increased clarity, this change also better fits existing models of performing forces description (e.g., MARC).

As a compromise, I'm happy to leave most of the model of <instrumentation> in place, but remove <ensemble> and also remove PCDATA from <instrVoiceGrp>.  I could even see retaining a single <instrVoice> to accommodate your minimal nesting objection -

<ELEMENT instrumentation (instrVoice|instrVoiceGrp)

This would continue to validate

<instrumentation>
  <instrVoice>piano</instrVoice>
</instrumentation>

The upshot of this is that ensemble names will have to be placed in <instrVoice>, as in -

<instrumentation>
  <instrVoice>dance band</instrVoice>
</instrumentation>

If you're with me so far, then changing "instrVoice" to "perfRes" and "instrVoiceGrp" to "perfResList" resolves the mental confusion of calling a dance band a "voice", doesn't it?

--
p.

From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger
Sent: Friday, September 18, 2015 5:19 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] revision of content model of <instrumentation>

Hi Perry

First of all, I am afraid I still can't see the importance of changing the model; is it important enough to break backwards compatibility?

I can think of a very simple situation where the current model seems more appropriate:

<instrumentation>
    <instrVoice>piano</instrVoice>
</instrumentation>

This would have to be changed into

<instrumentation>
    <instrVoiceGrp>
        <instrVoice>piano</instrVoice>
    </instrVoiceGrp>
</instrumentation>

or

<instrumentation>
    <instrVoiceGrp>piano</instrVoiceGrp>
</instrumentation>

It bothers me that I would always have to define a group, even if there is just a single instrument. Or very few instruments: I actually like being able to make a distinction between a few single instruments playing together and a group of instruments (an ensemble). For instance, I regard an orchestra as a group in a very different way than, say, a piano and violin playing a sonata. I am happy that the current model allows me to describe the sonata players as

<instrumentation>
    <instrVoice>violin</instrVoice>
    <instrVoice>piano</instrVoice>
</instrumentation>

rather than

<instrumentation>
    <instrVoiceGrp>
        <instrVoice>violin</instrVoice>
        <instrVoice>piano</instrVoice>
    </instrVoiceGrp>
</instrumentation>

The difference may be a subtle one, I admit. But it fits may way of thinking of a group or an ensemble as something different from two musicians playing together, even if it wouldn't make any sense trying to define the exact line between the one and the other...

If wrapping all <instrVoice> and <instrVoiceGrp> into a single <instrVoiceGrp> - one of your suggestions to my cantata example - is to be the recommendation, their parent <instrumentation> would become obsolete as it would always contain just one (or zero) <instrVoiceGrp>.
Your other suggestion - grouping the soloists in a <instrVoiceGrp> - conflicts with my understanding of them being marked explicitly as soloists (as in: NOT part of a group or an ensemble).

Sorry if I don't get your point!

/axel

Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h)
Sendt: 17. september 2015 20:11
Til: Music Encoding Initiative
Emne: Re: [MEI-L] revision of content model of <instrumentation>

Sue me, I lied - this is still bugging me.  :)

I still want to constrain the content of <instrumentation>, but I think I've finally found a better solution.  Changing the model to

ELEMENT instrumentation (ensemble|instrVoiceGrp)*

will validate all the following examples -

Ex 1. Empty
<instrumentation/>

Ex 2. Single named ensemble
<instrumentation>
  <ensemble>Orchestra</ensemble>
</instrumentation>

Ex 3. Any number of enumerated performing groups
<instrumentation>
  <instrVoiceGrp>
    <instrVoice>air guitar</instrVoice>
     <instrVoice>nose flute</instrVoice>
  </instrVoiceGrp>
</instrumentation>

Ex 4. (Axel's example with the soloists wrapped using <instrVoiceGrp>)
<instrumentation>
    <instrVoiceGrp code="on" xml:id="instrVoiceGrp_ce2418ae">
        <instrVoice code="wa" count="2" solo="false" xml:id="instrVoice_35190376">fl.</instrVoice>
        <instrVoice code="wb" count="1" solo="false" xml:id="instrVoice_eb76cb3c">ob.</instrVoice>
        <instrVoice code="wc" count="3" solo="false" xml:id="instrVoice_2a3dad65">cl.</instrVoice>
        <instrVoice code="wd" count="1" solo="false" xml:id="instrVoice_8452f43c">fg.</instrVoice>
        <instrVoice code="ba" count="4" solo="false" xml:id="instrVoice_4af15a73">cor.</instrVoice>
        <instrVoice code="bc" count="2" solo="false" xml:id="instrVoice_b3ce4944">cnt.</instrVoice>
        <instrVoice code="bd" count="2" solo="false" xml:id="instrVoice_6abf5bd6">trb.</instrVoice>
        <instrVoice code="be" count="2" solo="false" xml:id="instrVoice_29d73610">tb.</instrVoice>
        <instrVoice code="pa" count="1" solo="false" xml:id="instrVoice_589f0915">timp.</instrVoice>
        <instrVoice code="pz" count="1" solo="false" xml:id="instrVoice_54e51406">cmplli.</instrVoice>
    </instrVoiceGrp>
    <instrVoiceGrp code="ca" xml:id="instrVoiceGrp_fc8fef4e">
        <head>Choir</head>
        <instrVoice code="va" count="1" xml:id="instrVoice_44c2685b">S.</instrVoice>
        <instrVoice code="vc" count="1" xml:id="instrVoice_ba0dcf90">A.</instrVoice>
        <instrVoice code="vd" count="1" xml:id="instrVoice_205d576b">T.</instrVoice>
        <instrVoice code="vf" count="1" xml:id="instrVoice_95d6fb3b">B.</instrVoice>
    </instrVoiceGrp>
    <instrVoiceGrp>
      <instrVoice code="va" count="1" solo="true" xml:id="instrVoice_069a4d9b">S.</instrVoice>
      <instrVoice code="vd" count="1" solo="true" xml:id="instrVoice_205d8825">T.</instrVoice>
  </instrVoiceGrp>
</instrumentation>

Ex 5. (Axel's example with the entire content wrapped using <instrVoiceGrp>, nested enumerated groups)
<instrumentation>
  <instrVoiceGrp>
    <instrVoiceGrp code="on" xml:id="instrVoiceGrp_ce2418ae">
        <instrVoice code="wa" count="2" solo="false" xml:id="instrVoice_35190376">fl.</instrVoice>
        <instrVoice code="wb" count="1" solo="false" xml:id="instrVoice_eb76cb3c">ob.</instrVoice>
        <instrVoice code="wc" count="3" solo="false" xml:id="instrVoice_2a3dad65">cl.</instrVoice>
        <instrVoice code="wd" count="1" solo="false" xml:id="instrVoice_8452f43c">fg.</instrVoice>
        <instrVoice code="ba" count="4" solo="false" xml:id="instrVoice_4af15a73">cor.</instrVoice>
        <instrVoice code="bc" count="2" solo="false" xml:id="instrVoice_b3ce4944">cnt.</instrVoice>
        <instrVoice code="bd" count="2" solo="false" xml:id="instrVoice_6abf5bd6">trb.</instrVoice>
        <instrVoice code="be" count="2" solo="false" xml:id="instrVoice_29d73610">tb.</instrVoice>
        <instrVoice code="pa" count="1" solo="false" xml:id="instrVoice_589f0915">timp.</instrVoice>
        <instrVoice code="pz" count="1" solo="false" xml:id="instrVoice_54e51406">cmplli.</instrVoice>
    </instrVoiceGrp>
    <instrVoiceGrp code="ca" xml:id="instrVoiceGrp_fc8fef4e">
        <head>Choir</head>
        <instrVoice code="va" count="1" xml:id="instrVoice_44c2685b">S.</instrVoice>
        <instrVoice code="vc" count="1" xml:id="instrVoice_ba0dcf90">A.</instrVoice>
        <instrVoice code="vd" count="1" xml:id="instrVoice_205d576b">T.</instrVoice>
        <instrVoice code="vf" count="1" xml:id="instrVoice_95d6fb3b">B.</instrVoice>
    </instrVoiceGrp>
    <instrVoice code="va" count="1" solo="true" xml:id="instrVoice_069a4d9b">S.</instrVoice>
    <instrVoice code="vd" count="1" solo="true" xml:id="instrVoice_205d8825">T.</instrVoice>
  </instrVoiceGrp>
</instrumentation>

Ex. 6 Named ensemble + enumerated (nested) groups
<instrumentation>
  <ensemble>Orchestra</ensemble>
  <instrVoiceGrp>
    <head>Weird collection o' players</head>
    <instrVoice>air guitar</instrVoice>
    <instrVoice>nose flute</instrVoice>
    <instrVoiceGrp count="1">
      <instrVoice>tambourine</instrVoice>
      <instrVoice>autoharp</instrVoice>
    </instrVoiceGrp>
  </instrVoiceGrp>
</instrumentation>

Ex. 7 Multiple named ensembles
<instrumentation>
  <ensemble>Band</ensemble>
  <ensemble>Orchestra</ensemble>
  <ensemble>Steel Band</ensemble>
</instrumentation>

If anyone can demonstrate problems with this model, please let me know.

--
p.

From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h)
Sent: Wednesday, September 16, 2015 3:57 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] revision of content model of <instrumentation>

Hi Axel,

I think you've got it.  Another layer of nesting using an outer <instrVoiceGrp> isn't necessary.  I would recommend that you use <head> within all the <instrVoiceGrp> elements, not just the one for the Choir.  You could also group the soloists, but it's not required, I'm just being foolishly consistent.  :)

Looking more carefully, I now think the current model for <instrumentation> can't really be improved, since all my so-called "improvements" result in not being able to handle works for a standard ensemble (e.g., orchestra) and an enumerated list of performers (for example, air guitar, nose flute, tambourine and autoharp, where one player uses 2 instruments) -

<instrumentation>
  <ensemble>Orchestra</ensemble>
  <instrVoiceGrp>
    <head>Weird collection o' players</head>
    <instrVoice>air guitar</instrVoice>
    <instrVoice>nose flute</instrVoice>
    <instrVoiceGrp count="1">
      <instrVoice>tambourine</instrVoice>
      <instrVoice>autoharp</instrVoice>
    </instrVoiceGrp>
  </instrVoiceGrp>
</instrumentation>

Sorry for the unnecessary thrashing,

--
p.

From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger
Sent: Wednesday, September 16, 2015 9:03 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] revision of content model of <instrumentation>

Hi Perry

I use several elements within <instrumentation> very often. I haven't been using <ensemble>, though.
But in a cantata like this one: http://www.kb.dk/dcm/cnw/document.xq?doc=cnw0113.xml , I have the following to define an orchestra, a choir and vocal soloists:

<instrumentation>
    <instrVoiceGrp code="on" xml:id="instrVoiceGrp_ce2418ae">
        <instrVoice code="wa" count="2" solo="false" xml:id="instrVoice_35190376">fl.</instrVoice>
        <instrVoice code="wb" count="1" solo="false" xml:id="instrVoice_eb76cb3c">ob.</instrVoice>
        <instrVoice code="wc" count="3" solo="false" xml:id="instrVoice_2a3dad65">cl.</instrVoice>
        <instrVoice code="wd" count="1" solo="false" xml:id="instrVoice_8452f43c">fg.</instrVoice>
        <instrVoice code="ba" count="4" solo="false" xml:id="instrVoice_4af15a73">cor.</instrVoice>
        <instrVoice code="bc" count="2" solo="false" xml:id="instrVoice_b3ce4944">cnt.</instrVoice>
        <instrVoice code="bd" count="2" solo="false" xml:id="instrVoice_6abf5bd6">trb.</instrVoice>
        <instrVoice code="be" count="2" solo="false" xml:id="instrVoice_29d73610">tb.</instrVoice>
        <instrVoice code="pa" count="1" solo="false" xml:id="instrVoice_589f0915">timp.</instrVoice>
        <instrVoice code="pz" count="1" solo="false" xml:id="instrVoice_54e51406">cmplli.</instrVoice>
    </instrVoiceGrp>
    <instrVoiceGrp code="ca" xml:id="instrVoiceGrp_fc8fef4e">
        <head>Choir</head>
        <instrVoice code="va" count="1" xml:id="instrVoice_44c2685b">S.</instrVoice>
        <instrVoice code="vc" count="1" xml:id="instrVoice_ba0dcf90">A.</instrVoice>
        <instrVoice code="vd" count="1" xml:id="instrVoice_205d576b">T.</instrVoice>
        <instrVoice code="vf" count="1" xml:id="instrVoice_95d6fb3b">B.</instrVoice>
    </instrVoiceGrp>
    <instrVoice code="va" count="1" solo="true" xml:id="instrVoice_069a4d9b">S.</instrVoice>
    <instrVoice code="vd" count="1" solo="true" xml:id="instrVoice_205d8825">T.</instrVoice>
</instrumentation>

Is that a misunderstanding of the concept? How would you organize this instrumentation? By another layer of nesting <instrVoiceGrp> and <instrVoice> elements?

Best,
Axel

Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h)
Sendt: 15. september 2015 23:00
Til: mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
Emne: [MEI-L] revision of content model of <instrumentation>

Hello everyone,

This is pretty arcane stuff, so I expect that it will only be of interest to those who are deeply involved in creating detailed metadata regarding instrumentation, especially from MARC-encoded metadata.  Consider yourself warned.  :)

The current model of <instrumentation> is very lax in order to allow liberal mixing of ensemble, instrVoice, and instrVoiceGrp elements -

<content>
  <rng:zeroOrMore>
    <rng:ref name="model.headLike"/>
  </rng:zeroOrMore>
  <rng:zeroOrMore>
    <rng:choice>
      <rng:ref name="ensemble"/>
      <rng:ref name="instrVoice"/>
      <rng:ref name="instrVoiceGrp"/>
    </rng:choice>
  </rng:zeroOrMore>
</content>

My original thinking on this was that a very loosely structured model would be helpful if <instrumentation> were ever allowed to occur with the textual parts of MEI, say in <p>.  However, I believe that it is unlikely that <ensemble> will ever occur in the presence of the other two possibilities.  Therefore, unless someone can prove my hunch to be incorrect, I'm inclined to allow only one sub-element to be used at a time -

<content>
  <rng:zeroOrMore>
    <rng:ref name="model.headLike"/>
  </rng:zeroOrMore>
  <rng:optional>
    <rng:choice>
      <rng:ref name="ensemble"/>
      <rng:ref name="instrVoice"/>
      <rng:ref name="instrVoiceGrp"/>
    </rng:choice>
  </rng:optional>
</content>

Using this approach, one can use <ensemble> to encode the name of a performing group, like "orchestra" or use <instrVoiceGrp> to enumerate the parts/players of the group, but not both.

However, this change re-focuses attention on the relationship between <ensemble> and <instrVoice> - possibly a distinction without a difference, as the expected content of both is text and both provide the same attributes (att.authorized and att.coded) for connecting the textual content to an authorized list.  With this in mind, it might be beneficial to modify the content model even further -

<content>
  <rng:zeroOrMore>
    <rng:ref name="model.headLike"/>
  </rng:zeroOrMore>
  <rng:optional>
    <rng:choice>
      <rng:ref name="instrVoice"/>
      <rng:ref name="instrVoiceGrp"/>
    </rng:choice>
  </rng:optional>
</content>

eliminating <ensemble> entirely.  The problem with this solution is that some confusion may be created as "instrVoice" doesn't immediately spring to mind as a way to name an ensemble.  Conversely, the "Grp" part of the name "instrVoiceGrp" may lead the unwary into thinking that it can be used to *label* an ensemble, when in fact it should be used to *describe* an ensemble.

So, I'm looking for advice on how to resolve this quandary - a model that's too lax vs. a model that's more tightly controlled but with elements that are not completely descriptive of the material we're trying to encode.  At this point, I'm leaning toward the most restrictive model.

Is everyone OK with using <instrVoice>Band</instrVoice> to name an ensemble without enumerating its constituents and using

<instrVoiceGrp>
  <head>Band</head>
  <instrVoice>Flutes</instVoice>
  <instrVoice>Clarinets</instrVoice>
  etc.

to provide detailed instrumentation when needed?  Also, has anyone created markup that this change would break?

Thanks for your input,

--
p.

________________________________
Perry Roland
University of Virginia
P. O. Box 400874
Charlottesville, VA, 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20150921/986798ab/attachment.html>