erc-dharma / project-documentation

DHARMA Project Documentation
Creative Commons Attribution 4.0 International
3 stars 3 forks source link

Textpart divisions headings #241

Closed michaelnmmeyer closed 6 months ago

michaelnmmeyer commented 11 months ago

The values of div/@subtype, div/@n and div/head are taken into account for generating texpart headings. The relation between these values and their purpose is not clearly understood by encoders.

Some people reproduce div/@n in div/head, or even use a different numbering schemes. Probably because the current behaviour is either to generate a heading from div/@subtype and div/@n (Face A, Fragment B, etc.), or to just display the contents of div/head, without displaying div/@n. We see e.g.

<div type="textpart" n="4">
<head xml:lang="eng">Face D</head>
<div type="textpart" subtype="fragment" n="1">
<head xml:lang="eng">Fragment 1</head>

There are also confusions between the contents of div/@subtype and div/head e.g.

<div type="textpart" n="C">
<head xml:lang="eng">Face</head>

Instead we should have:

<div type="textpart" subtype="face" n="C">

The format of div/head is also quite variable:

<div type="textpart" n="C" resp="part:argr">
<head xml:lang="eng">Plate : first translation</head>
<div type="textpart" subtype="trial" n="B">
<head xml:lang="eng">Trials unexposed. Left of the main text</head>
<div type="textpart" subtype="face" n="9">
<head xml:lang="eng">Front: Additional line at bottom</head>

I think we should always display the value of div/@n, whether a div/head is given or not, if only to make apparent the numbering scheme that will be used for referencing parts of the inscription. This would also discourage people from using several numbering schemes together, as seen above.

I propose to format headings as follows. We have 3 possible cases:

<div type="textpart" n="1">
<head xml:lang="eng">Upper leftcorner</head>
<div type="textpart" subtype="fragment" n="1">
<div type="textpart" subtype="fragment" n="1">
<head xml:lang="eng">Upper left corner</head>

These would produce respectively:

1. Upper left corner

Fragment 1

Fragment 1: Upper left corner (OR: Fragment 1. Upper left corner)

The value of div/@subtype would not be considered significant for referencing, so that you cannot have in the same document two textparts that bear the same div/@n, as in

<div type="textpart" subtype="fragment" n="A">
...
<div type="textpart" subtype="face" n="A">
danbalogh commented 11 months ago

Thank you, @michaelnmmeyer , for systematising your thoughts on all these topics, and for creating separate github issues for them.

danbalogh commented 11 months ago

I had in fact started writing a response to the first topic in original issue. Here it is.

Some people reproduce div/@n in div/head, or even use a different numbering schemes. Probably because the current behaviour is either to generate a heading from div/@subtype and div/@n (Face A, Fragment B, etc.), or to just display the contents of div/head, without displaying div/@n.

The reason why div/head, when present, replaces (instead of supplements) the info in the attributes on the div is that numbers in textpart headings are not desirable in certain cases. Thus, in copperplate sets with a seal, numbering the parts "Seal" and "Plates" would not make much sense, and those dealing with Southeast Asian stelae with four inscribed faces prefer titles such as "South Face" or "Front Face". I personally have no strong objection to displaying numbers nonetheless when a head is also present, but I am quite sure I recall correctly that Arlo did object to that. See also the other examples in EGD §3.4.3 where textparts are of a disparate nature, so @subtype would not be relevant. On the other hand, even when a head is present, we do need a number for machine-actionable identification.

So cases where encoders have used conflicting numbering schemes in @n and <head>, redundantly encoded a <head> where @n and @subtype suffice, or encoded a <head> with too little information content (probably unaware that this would replace the n and subtype) are encoding errors and need correction.

I think we should always display the value of div/@n, whether a div/head is given or not, if only to make apparent the numbering scheme that will be used for referencing parts of the inscription. This would also discourage people from using several numbering schemes together, as seen above.

I propose to format headings as follows. We have 3 possible cases:

<div type="textpart" n="1">
<head xml:lang="eng">Upper leftcorner</head>
<div type="textpart" subtype="fragment" n="1">
<div type="textpart" subtype="fragment" n="1">
<head xml:lang="eng">Upper left corner</head>

These would produce respectively:

  1. Upper left corner

    Fragment 1

    Fragment 1: Upper left corner (OR: Fragment 1. Upper left corner)

All in all, I think your suggestion makes sense (actually I think this is pretty much the same as what I had originally suggested for the EGD). The question is whether people who deal with "Front Face" of a stele or "South Doorjamb" of a temple gate are happy with encoding

<div type="textpart" n="A">
<head xml:lang="eng">Front face</head>

and getting "A. Front face" in display, and whether there are any other use cases where the presence of a number in the textpart heading is strongly undesirable. I think this question is mainly for @arlogriffiths to answer.

I would also like you to heed the EGD's guidance that unless there is a reason to do otherwise, textpart numbering should consist of uppercase Latin letters - so use those in your examples instead of "1" etc.

The value of div/@subtype would not be considered significant for referencing, so that you cannot have in the same document two textparts that bear the same div/@n, as in

...

I agree in principle. It is, however, extremely unlikely in my opinion that anyone will ever want to encode an inscription with two or more different kinds of textparts. The EGD (§3.4.2) explicitly says that textparts should not be nested within each other, and as for the serial use of different kinds of textparts, it is implicit in §3.4.3 (but should perhaps be made explicit) that if necessary, these should be handled without @subtype, using only the <head> to clarify the nature of each part. Still, depending on the extent to which we rewrite the guidelines on this topic, it will probably be a good idea for me to add a point to this effect.