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

Tue Sep 15 23:00:06 CEST 2015

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/20150915/b72a2c14/attachment.html>