Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong use of <subst> in guidelines for <supplied>? #97

Open
th-we opened this issue Nov 1, 2015 · 13 comments
Open

Wrong use of <subst> in guidelines for <supplied>? #97

th-we opened this issue Nov 1, 2015 · 13 comments

Comments

@th-we
Copy link
Member

th-we commented Nov 1, 2015

In my understanding, <subst> is for encoding scribal substitutions, not editorial substitutions. That's how I read the guideline chapter Substitutions, Restorations, and Handshifts, which seems to match how the TEI equivalent is designed to be used.

However, <subst> is used for grouping editorial additions in an example of chapter Omissions, Unclear Readings, Damage, and Supplied Readings. Being no edittrans expert, I feel this is probably improper use and the example should be changed - but how? <choice> wouldn't be a drop-in replacement for <subst> here, it neither allows <gap> nor <supplied> as content.

As a side note: All notes under the beam in that example are oddly encoded as quarter notes.

@raffazizzi
Copy link
Member

Indeed! That should be an orig/reg:

<choice>
    <orig>
        <gap extent="two eighth notes" reason="missing notes"/>
    </orig>
    <reg>
      <note pname="e" oct="3" dur="4"/>
      <note pname="f" oct="3" dur="4"/>
    </reg>
  </choice>

@th-we
Copy link
Member Author

th-we commented Nov 1, 2015

But then this isn't an illustration of the <supplied> element any more, so it needs to be replaced with something different.

@raffazizzi
Copy link
Member

Huh. I'm surprised that's the only example. Something with music ficta, or adding an accidental forgotten in a manuscript would be much more relevant.

@pe-ro
Copy link
Contributor

pe-ro commented Nov 2, 2015

I wouldn't say that the <subst> example is wrong, but that perhaps the "Substitutions, Restorations, and Handshifts" part of the Guidelines is incomplete. Without the use of <subst> to gather editorial interventions, what should be used instead? I don't think the TEI method; that is, <gap/> immediately followed by <supplied>, is helpful as it doesn't signal the alternative paths available. To rectify this problem, it was decided to use <subst>. I suppose the other option would be <choice>, but if we follow TEI's lead, this leads to a dead-end as well. So, the issue really is, since TEI doesn't provide a way to group editorial interventions, how faithful must we be to it?

@raffazizzi
Copy link
Member

@pe-ro what's wrong with my choice/orig/reg rewrite of the example above? That's how it would be done in TEI and it does what was intended in the original example with <subst>.

@pe-ro
Copy link
Contributor

pe-ro commented Nov 2, 2015

Nothing wrong with your rewrite. Please fix the Guidelines example.

But I'm looking for a way to group editorial interventions without resorting to app/rdg.

@raffazizzi
Copy link
Member

Maybe this is for a different ticket, but what do you mean by grouping editorial interventions? If it's akin to the example above, then choice/orig/reg is the obvious solution, no need for app/rdg.

@pe-ro
Copy link
Contributor

pe-ro commented Nov 2, 2015

How does one group <gap> and <supplied>?

@pe-ro
Copy link
Contributor

pe-ro commented Nov 2, 2015

Or, how can <supplied> be grouped with <damage>?

@raffazizzi
Copy link
Member

I would group them with choice/orig/reg.

<gap> is an editorial description of missing content (so not an intervention, per se), while <supplied> makes sense on its own, but in this case it's replaced by <reg> - also an editorial intervention that rather than supplying, it regularizes.

I would also do the same with <damage>: <orig> allows me to describe that something problematic was there; <reg> allows me to describe what I'm going to do about it.

If I wanted to use <supplied> in the <gap> example, I wouldn't use <gap> because supplied already implies that something is lacking. If what's lacking needs to be specified, then I need to distinguish between what was there and what was added (with choice/orig/reg). This is how TEI does it and it seems sound to me.

@pe-ro
Copy link
Contributor

pe-ro commented Nov 2, 2015

I see the logic, but that requires an extra layer in the hierarchy and it throws a significant wrench in the works re: the content models of choicePart and substPart. But, if this is the way to go, let's break them now rather than later.

@raffazizzi
Copy link
Member

I think that's worth it; so that we get to keep the definition of choice and subst well distinguished between editor and scribe. But we probably need to hear from @kepper as well.

@kepper
Copy link
Member

kepper commented Nov 2, 2015

Well, you certainly don't need to hear from me – but thanks for asking ;-) I'm not sure I really get the point of this discussion, but I totally agree that we need to be as clear as possible with a separation between "editor markup" and "scribal markup". It seems equally clear that this is the distinction between choice and x, but I'm not perfectly decided if x = subst. I guess everything a scribe does can be subsumed under the term substitution, but not everything can be subsumed under the tag subst. With the Beethoven, we moved away from wrapping a del/add combination with subst, as this subst effectively prevents us from using restore for the deleted part (it doesn't seem to be clear if the restore takes away the added material or not).
Also, I'm not sure what the nesting issues on the editor side will result in. My first take is that it's not a huge issue, but needs proper clarification in the guidelines. The only choice pairs I've used to far are orig+reg, sic+corr and abbr+expan, with direct music content. Nesting everything else into these pairs seems reasonable, but again, I'm not completely settled yet ;-)

@ahankinson ahankinson transferred this issue from music-encoding/music-encoding Apr 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants