[MEI-L] revision of content model of <instrumentation>
Roland, Perry D. (pdr4h)
pdr4h at eservices.virginia.edu
Tue Sep 22 16:25:38 CEST 2015
Hi Peter,
Thanks for the info.
I don't agree that @code, @dbkey, @n, @label etc. are all _exactly_ the same. They all have a similar, but not the same function. For instance, as defined by MEI @label is a displayable string (think of it as a "tool tip") while @n is (typically) a number that identifies its bearer within a collection of objects (as @n identifies a particular measure in the collection of measures). As I mentioned yesterday, I do think that @code and @dbkey are similar enough to warrant merging them into a single attribute.
In MEI there's the att.authorized class (containing @authority and @authURI) and att.canonical (containing @dbkey). With @authURI one can provide an "authoritative Uniform Resource Identifier" for the content of the GI (similar to the proposed TEI @ref). That URI can be a complete one; that is, it can include the terminating point, or it may stop one step short, in which case the terminal (a particular database record or document fragment, for instance) is captured in the @dbkey attribute. When the URI is complete, there's no need for @dbkey. But sometimes there's a need for the labeling function of @dbkey _without_ a corresponding need for the URI. For example, one might use @dbkey to hold a canonical identifier (such as a Köchel designation for a title or a VIAF record number for a name) without providing a URI. In fact, there may be no corresponding internet resource to point to. We do, after all, sometimes have to cope with the "not-yet-completely-networked-real-world", so it's important to maintain a separation between these two attribute classes.
"dbkey" is probably not the best name for the thing that holds a canonical reference. I'm hesitant to use "ref" because it's too generic. The best I've come up with so far is "codedval". A "coded value" represents or identifies the element content (as, for example, "ka" represents the piano in the MARC Instruments and Voices Code List). Of course, it's the encoder's responsibility to provide the means (or at least a description of the means) to resolve the reference -- whether there's a URI or not.
The so-called "Private URI Scheme" solution seems sound, but let's allow TEI to explore this territory first. :-)
--
p.
> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces+pdr4h=virginia.edu at lists.uni-
> paderborn.de] On Behalf Of Peter Stadler
> Sent: Tuesday, September 22, 2015 4:27 AM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] revision of content model of <instrumentation>
>
> To me, @code, @dbkey, @n, @label et. al are all the same since they are
> some identifier, making sense only to (some) humans, because their way of
> identifying (and how to resolve the reference) is nowhere made explicit.
>
> The TEI is currently deprecating its @key attribute in favor of the more
> formally defined @ref, noting:
> "No particular syntax is proposed for the values of the key attribute, since its
> form will depend entirely on practice within a given project. For the same
> reason, this attribute is not recommended in data interchange, since there is
> no way of ensuring that the values used by one project are distinct from
> those used by another. In such a situation, a preferable approach for magic
> tokens which follows standard practice on the Web is to use a ref attribute
> whose value is a tag URI as defined in RFC 4151.“ [1]
>
> In fact, every local identifier ("magic token“) can easily be converted to a
> 'real‘ URI through the usage of private URI schemes [2].
>
> Just thought I’d mention this …
> Best
> Peter
>
>
> [1] http://www.tei-c.org/Vault/P5/2.8.0/doc/tei-p5-doc/en/html/ref-
> att.canonical.html
> [2] http://wiki.tei-c.org/index.php/Private_URI_Schemes
>
>
> > Am 21.09.2015 um 17:41 schrieb Roland, Perry D. (pdr4h)
> <pdr4h at eservices.virginia.edu>:
> >
> >
> > 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 –
> >
> > <perfMedium>
> > <castList><!—Dramatic roles, performers, voices, etc. --></castList>
> > <instrumentation><!—non-dramatic performers, instrumental and vocal
> > --></instrumentation> </perfMedium>
> >
> > 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. J
> >
> > 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. J
> >
> > 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
> > 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. J
> >
> > 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
> >
> > _______________________________________________
> > 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