TEIC / TEI

The Text Encoding Initiative Guidelines
https://www.tei-c.org
Other
273 stars 88 forks source link

Guidelines, p. 384 - number of <rdg> in <app> #1011

Closed TEITechnicalCouncil closed 8 years ago

TEITechnicalCouncil commented 12 years ago

"each <app> must contain at least one <rdg>."

Comment: The schema only requires one, but what is a <app> with only one <rdg> (and no <lem>) supposed to mean?

Original comment by: @jensopetersen

TEITechnicalCouncil commented 8 years ago

This issue was originally assigned to SF user: gabrielbodard Current user is: gabrielbodard

TEITechnicalCouncil commented 12 years ago

Original comment by: @jensopetersen

TEITechnicalCouncil commented 12 years ago

I suppose one might more accurately require that an app should contain either (a) one lem and one or more rdgs or (b) two or more rdgs The situation arises because some people want to record just <rdg>s without characterising any of them as <lem>s, while others insist on that possibility. If my supposition is correct, the appropriate action would probably be to add a schematron rule to enforce it.

Original comment by: @lb42

TEITechnicalCouncil commented 12 years ago

Original comment by: @lb42

TEITechnicalCouncil commented 12 years ago

I almost never use <lem> as I don't want to privilege one reading over another in the encoding.... that is what output is for.

I've had <app> with one <rdg> when using nested <app> but only to keep consistency in the markup to make processing easier. (I'm not recommending this as good practice).

Some people like to tessellate <app> entirely over their content even when all witnesses agree. That would be another case one might encounter a single rdg inside an app. I can see the argument that this should be considered poor practice.

-james

Original comment by: @jamescummings

TEITechnicalCouncil commented 12 years ago

The use-case where there's only one <rdg/> is something that we introduced a couple of years ago, to cater for the kind of apparatus that is not strictly variant readings, but possibly attributing the origin of a reading to a given editor or witness without necessarily having to give a lemma or other readings, adding an editorial note to a reading, etc.

I emphatically don't think this is a bug, therefore, even if it's something that you might not want to use in an old-fashioned critical apparatus of variant readings.

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 12 years ago

As Gabriel says, there are use cases for having just a rdg within an app. We propose to leave the content model unchanged and to add a schematron constraint to check for the existence of at least one rdg.

Original comment by: @lb42

TEITechnicalCouncil commented 12 years ago

Original comment by: @lb42

TEITechnicalCouncil commented 12 years ago

No, actually I think it was deliberate to allow an <app> with no <rdg> as well. (The use-case envisaged was just a <ptr> [to an app, choice, subst or similar construction in the transcription] and/or a <note> with editorial observations on it.) This again is the case of <app> used for something slightly wider than merely variant readings, as it is in (e.g.) epigraphy, as opposed to MS studies.

Can we revisit this decision, please?

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 12 years ago

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 12 years ago

As requested, I'm linking to the discussion in which we made the decisions I'm referring to below (which, it turns out, was way back in 2006-7).

The Sourceforge ticket: http://purl.org/tei/fr/1551357

The TEI-L discussion (2 threads): http://listserv.brown.edu/archives/cgi-bin/wa?A1=ind0607&L=TEI-L\#10

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 12 years ago

While I can see the use for <app>s with no or only a single <rdg>, my bug report was concerned with the text of the Guidelines, and such uses of <app> are nowhere discussed there. Therefore, until such a discussion is introduced, I would suggest to remove "; each <app> must contain at least one <rdg>", because it introduces the possibility of an <app> containing a single <rdg> (or a <lem> with no <rdg>, I presume), which will be mystifying to those who base themselves on the text of the Guidelines alone. I warmly support Gabriel's 2006 proposal: I see immediate use cases for this.

Original comment by: @jensopetersen

TEITechnicalCouncil commented 12 years ago

I agree that there is a problem in the Guidelines here. I suggest that the solution is not to insert a schematron rule to enforce the minimum-one-rdg rule, but to rewrite the guidelines to:

  1. remove the statement that at least 1 rdg is required;

  2. provide examples of usage of app with less than min <lem>+<rdg>

  3. provide examples of usage of app with <ptr> and <note>, both with and without rdg/lem

(I can provide examples of 2+3, but they'll be in Greek and Latin. English examples anyone?)

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 11 years ago

Council agrees with Gaby's last comment and assigns to him to implement. (face to face 2012-09)

Original comment by: @jamescummings

TEITechnicalCouncil commented 11 years ago

Original comment by: @jamescummings

TEITechnicalCouncil commented 11 years ago

Removed schematron constraint and changed description to read, "with an optional lemma and usually one or more reading or a note on the relevant passage." (at r10988).

Not closing ticket because examples of (2) and (3) below still need added.

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 11 years ago

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 11 years ago

Examples of <app> without <lem>, and with <ptr> and <note> added at r12269.

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 11 years ago

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 11 years ago

reopened, because it seems I mistakenly assumed <ptr> was available in <app> whenit has apparently never been. I suppose the function I have imagined for it (i.e. pointing to a choice or app element in the text itself) is more or less covered by @loc? (But @loc isn't a pointer?)

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 11 years ago

In that case isn't the recommendation to use @from which is a pointer? c.f. http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPLN

Original comment by: @jamescummings

TEITechnicalCouncil commented 11 years ago

I've recast the two examples with @loc or @corresp instead of , at r12272

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 11 years ago

Right, I was wondering about that, but was put off by the remark "This attribute is only used when the double-end point method of apparatus markup is used", and the examples I'm thinking of use the "location-referenced method". Does this matter?

(If not, should the remark be cleared up a bit?)

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 11 years ago

I would vote for the notes on app's @from and @to being changed or removed. I think the prose of the guidelines allows for using them in a location referenced method.

Original comment by: @jamescummings

TEITechnicalCouncil commented 11 years ago

Fair enough. I've changed the example to use @from instead of @corresp (r12273). Do you want to open a new ticket to discuss the GL change, or do that here?

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 11 years ago

Original comment by: @gabrielbodard

TEITechnicalCouncil commented 11 years ago

After discussion with the Council, I've changed the wording of those notes slightly to better reflect the reality of how @from is used (as a pointer in location-referenced as well as in double-end point), at [r12278], and am now closing this ticket.

Original comment by: @gabrielbodard