#465 Add @source to att.responsibility

[BODARD Gabriel]

As discussed in a side-note to FR 443, I propose that the attribute @source be added to the att.responsibility class. This will allow the identification of a (e.g.) bibliographical source for an encoded statement anywhere that one can currently point to editorial responsibility for the encoding. We should then consider adding egXML q quote writing to this class, rather than definiting att.source separately, making the availibility of these two attributes more consistent.

One use case: apparatus criticus in documentary works often describe readings and emendations proposed in previous editions, rather than merely different manuscript witnesses or editorial responsibility for readings. It would be useful to encode this as something like:

<app loc="4">
   <lem resp="#GB">Diana<supplied>e</supplied></lem>
   <rdg source="#gasperini1965">Dianae</rdg>
</app>

[Lou Burnard]

Why is this @source rather than @wit ? how does finding the reading
"Dianae" in Gasperini's edition differ from finding it in some other
manuscript?

[BODARD Gabriel]

It differs hugely from a reading found in another manuscript, surely. Source means, "This is the source of the current encoding" (the emendation by an editor in a previous modern edition of this work, or other secondary discussion of this work); it's much closer to @resp, indicating the responsibility for the encoding, but pointing to a bibliographical reference rather than an element indicating the person of an editor.

I would expect <rdg wit="#gasperini1965">Dianae</rdg> to mean, "the reading Dianae is found in another copy of this text, identified by that id", which is a completely different matter. And because of the nature of the publication of inscriptions and papyri and other documentary texts, it's not possible safely to distinguish between a bibliographical reference that is "secondary", and one that refers to the "primary" text itself. (Gasperini 1965 might also be the canonical citation for some other inscription that witnesses to a variant reading.)

If I were going to tag this incorrectly (as I'm forced to in the absense of @source) I'd use @resp, certainly not @wit.

[Lou Burnard]

I'm not saying that a reading found in another manuscript or a "primary"
source has the same status as a reading chosen by a critical editor:
that's clearly nonsense. But the <app> encoding you cite doesn't offer
any way of distinguishing amongst "primary" and "secondary" readings:
they're all just readings. So when you say "another copy of this text,
identified by that id" you've lost me. This is another version of the
text given by the lemma! You seem to be overloading the semantics of the <rdg> element by means of attributes intended for a different purpose.

What would <rdg wit="#x" resp="#y" source="#z"> mean (if it were possible) ?

[Lou Burnard]

On 10/07/13 16:11, Lou Burnard wrote:

What would mean (if it were possible) ?

Sorry, forgot about this pesky markdown. Make that

What would <rdg wit="#x" source="#y" resp="#z"> mean

[Hugh A. Cayless]

x, the textual witness, says this, the encoder, y, got this information from the publication z. In other words, y didn't see the textual witness (x), but is relying on the assertion of a published text (z) that x has the text inside the rdg.

I take Gabby's example to mean he (GB) asserts the text is "Diana[e]", while Gasperini (1965) printed "Dianae".

[BODARD Gabriel]

I don't want to get too hung up on this one apparatus example, because there are many other examples (some given in FR 443) where @source would be useful--in fact I think it was a certain Monsieur Burnard who suggested I was abusing @resp in the first place!

But, I think I wasn't clear in my objection to refering to Gasperini as a "witness", so I'll try again: a witness is a(nother) manuscript version of this text, so in the case of an inscription (which is usually a unique witness) it would be another inscription with a copy of "the same" text (poems, decress, letters from emperors sometimes exist in multiple copies). In a more conventional example, it would be one of several manuscripts attesting to a single Platonic text. I certainly didn't mean "a copy of this text" in the sense that every modern edition is a copy of it--which wouldn't be @wit at all, in my view.

In contrast, the "source" for an emendation or other reading (for example of a difficult or damaged line) might be an editor's intervention in a modern edition of (or of one witness to) our historical text. This is not a witness to or variant of that text, but an edition of, even an interpretation of it. Emendations aren't indicated via sigla, conventionally, but via editor's names or references to the publication in which they appear; this convention is because these are two quite different kinds of information.

I suspect that the ad absurdam example you gave at the end of that comment might be nonsense... but the possibility of tagging two pieces of incompatible information is not an argument for not being able to tag either of those two pieces of information. But I suppose, if you think about it, you could imagine <rdg wit="#x" resp="#y" source="#z"> to mean:

• #x points to an msDesc of a manuscript witness in which this reading is attested;
• #y points to a <person> the editor (of this edition) who encoded this <rdg> element;
• #z points to the bibliographical reference in which the reading given as #x above was interpreted and published thus.

I don't imagine I would ever want to say all of this, but they're clearly saying different things.

[BODARD Gabriel]

A better, less confusing example:

<faith @resp="#Bodard">Isiac Mystery Cult</faith>
means, "That fellow Bodard claims so-and-so was an adherent of the Isiac Mystery Cult".

<faith @source="#GoldenAss">Isiac Mystery Cult</faith>
means, "The publication The Golden Ass is the source for the claim that so-and-so was an adherent of the Isias Mystery Cult".

Not the same statement at all, and they might even be taken together.

[James Cummings]

I agree with Gabby on this one. Can Council see any reason why we shouldn't just implement this?

[Hugh A. Cayless]

I'm all for it! I can do it tomorrow after I arrive if nobody objects.

[Lou Burnard]

Well, I'm grateful to Gabby for clarifying the intention here, and I now see what he means. Would it be fair to say that @resp and @source are so unlikely to coexist on the same element we should actually add a constraint to preclude it? (just trying to make Hugh's self-appointed task more interesting)

[BODARD Gabriel]

I don't think I'd ever take them together myself, but I'm uncomfortable with the idea of precluding it. As we said above, I think there is a perfectly clear semantic to an element that carries both attributes. (And if this request is implemented, I'll pretty much stop [mis]using @resp altogether...)

[James Cummings]

Council decided in Oxford face-to-face to assign to Hugh to implement before end of January 2014.

[Hugh A. Cayless]

Fixed with r12701. Added att.responsibility to att.source