[mei-catalog-ig] Proposal on <perfRes/> (next step)

[Roland, Perry D (pdr4h)]

Hi Dennis, everyone,

I’m not sure to what extent I may be able to participate in the next interest group meeting (when is it?), so I offer some comments on the perfRes proposal here.

1.  Ambitus – I generally support the idea of adding <ambitus> inside <perfRes>, depending on the details of the implementation, of course.  For example, a better way of indicating alternative ranges than allowing more than 2 <ambNote> elements in <ambitus> would be to permit <ambitus> to occur multiple times within <perfRes>.


<perfRes>

  <ambitus>

    <ambNote pname="c" oct="4"/>

    <ambNote pname="d" oct="5"/>

  </ambitus>

  <ambitus type="alt">

    <ambNote pname="c" oct="4"/>

    <ambNote pname="f" oct="5"/>

  </ambitus>

</perfRes>

If necessary (though I think it probably won’t be), @type may be used to make a distinction between the uses of the <ambitus> elements.

2.  Tuning – The proposal to use @tune.pname conflicts with the use of this attribute elsewhere, a definite no-no in schema design.  It would be better to allow the use of @trans.diat and @trans.semi to indicate how the instrument transposes.

3.  Ad Libitum – I see no problem with adding an @adLib attribute to <perfRes>.  It may be useful to also allow it on <perfResList> to allow a *group* of resources to be marked ‘ad lib’.

4. <perfRes> is allowed to nest in order to accommodate complex situations like this, although I suspect the law of diminishing returns comes into play when you state explicitly that the piano is to be played with 2 hands, one of which is the left and the other, the right. It does beautifully allow for the very rare circumstance when one is confronted with a composition for a player who has 3 left hands! 😊  Seriously, I think one must remember that just because it’s possible to record increasing complexity, it’s not always practical or helpful.  It’s called ‘metadata’ for a reason – it’s ‘meta’; that is, it’s at a higher level of abstraction.

5. <perfResList> vs. <perfResGrp> – The name ‘perfResList’ was chosen as the name here because performing resources are typically ordered in the score.  Technically, a list and a group are conceptually interchangeable, the name taking a back seat to the fact that they both contain a ‘set’ of children.  Changing the name now would introduce a backward incompatibility that’s not worth the trouble, in my opinion.

6. It’s not exactly clear, but by mentioning <desc> in the context of <perfRes>, I presume you’re suggesting replacing the current model –


<content>

  <rng:zeroOrMore>

    <rng:choice>

      <rng:text/>

      <rng:ref name="model.textPhraseLike.limited" />

      <rng:ref name="perfRes" />

    </rng:choice>

  </rng:zeroOrMore>

</content>

with


<content>

  <rng:zeroOrMore>

    <rng:choice>

      <rng:ref name="desc" />

      <rng:ref name="perfRes" />

    </rng:choice>

  </rng:zeroOrMore>

</content>

Doing so would clear up the somewhat messy current content model.  However, it would also require an extra bit of hierarchy for those who want to describe resources in a textual fashion; that is,


<perfRes>

  <desc>Orchestra</desc>

</perfRes>

would be required instead of the currently allowed


<perfRes>Orchestra</perfRes>

the simplicity of which comes at the cost of complexity in the model.  Making this change, like the one above, would introduce backward incompatibility that must be assessed for practicality.

Best wishes,

--
p.



From: mei-catalog-ig <mei-catalog-ig-bounces at lists.uni-paderborn.de> On Behalf Of Dennis Ried
Sent: Monday, January 25, 2021 12:10 PM
To: mei-catalog-ig at lists.uni-paderborn.de
Subject: [mei-catalog-ig] Proposal on <perfRes/> (next step)

Dear Listeners,


Clemens and I have been working again on the proposal to extend <perfMedium/>. We have now reached a further stage, which we want to share with the interest group again. The document is read-only, but we would ask you to prepare comments on this paper likely for the next metadata-meeting – on 28th January (I guess).


Document:
https://docs.google.com/document/d/1ykdOncyCFEnU1hhQu5KTccHEHQ53blMYgkg5jtcCPdc/edit?usp=sharing

See also some Sample-encodings:
https://github.com/riedde/sample-encodings/tree/feature/perfResSamples/MEI_4.0/Header/PerfMedium


<https://github.com/riedde/sample-encodings/tree/feature/perfResSamples/MEI_4.0/Header/PerfMedium>All the best and stay healthy
Dennis & Clemens
P.S. If you can't join the meeting you can send us your comments directly (if you have some).


Mit freundlichen Grüßen aus Waldsee,


__________________________________

Dennis Ried, M.A.
Musikwissenschaft | Digital Humanities

Weimarer Straße 27
D-67165 Waldsee

Mobil: +49-176-30 53 57 83
ried-musikforschung at mail.de<mailto:ried-musikforschung at mail.de>
__________________________________





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-catalog-ig/attachments/20210125/d29f52d1/attachment.htm>