listing visual documentation with <listBibl type="visuals">

[arlogriffiths]

we have discussed this separately, I don't have the energy to look up where. other options for listing visual documentation were rejected, but I seem to recall that the <listBibl> option was not rejected outright, although it also has not (yet) been implemented. for many inscriptions, there is a variety of visual documentation, with an increasing number being accessible online. I'd like to be able to list the available documentation in a flexibly structured manner, to help avoid needing to search for na particular wording suited for the case in every epigraphic lemma.

example, current file tfc-campa-epigraphy/DHARMA_INSCIC00140.xml

<p>Previously unpublished. Edited by Arlo Griffiths and Salomé Pichon from the EFEO estampages n. 262 and from photogrammetric documentation in 2024.</p>

desired new format would be something like this (without checking if it is valid TEI, ability to use <ref> is crucial):

<p>Previously unpublished. This digital edition by Arlo Griffiths and Salomé Pichon.</p>
        	<listBibl type="visuals">
	<bibl><ref target="https://nakala.fr/10.34847/nkl.aeab806v">DHARMA images by Adeline Levivier</ref></bibl>
         <bibl>EFEO estampages n. 262</bibl>
		</listBibl>

[michaelnmmeyer]

For things like that, you should just use a <ref> element. The encoding you propose is too ad hoc.

[arlogriffiths]

sorry, I don't get your point. my proposal is indeed using a <ref> element, and I don't know what you mean by "too ad hoc", as I am actually proposing a common framework for listing visual document, to be used instead of any ad hoc solutions.

let's also see what @danbalogh has to say.

[michaelnmmeyer]

The <ref> is fine, it is the use of <listBibl type="visuals"><bibl>...</bibl></listBibl> I am objecting to. You can either use:

<p>Previously unpublished. Edited by Arlo Griffiths and Salomé Pichon from the
<ref target="https://nakala.fr/10.34847/nkl.aeab806v">EFEO estampages n. 262</ref>
and from photogrammetric documentation in 2024.</p>

... or add a bibliographic entry for the document and refer to that, as in:

<p>Previously unpublished. Edited by Arlo Griffiths and Salomé Pichon from the
EFEO estampages n. 262 (<bibl><ptr target="bib:Griffiths+al2008-2009_01"/></bibl>)
and from photogrammetric documentation in 2024.</p>

[danbalogh]

I'm perfectly OK with Michaël's proposal and suggest we go along with it:

<p>Previously unpublished. Edited by Arlo Griffiths and Salomé Pichon from the
<ref target="https://nakala.fr/10.34847/nkl.aeab806v">EFEO estampages n. 262</ref>
and from photogrammetric documentation in 2024.</p>

[arlogriffiths]

I believe @manufrancis had already mentioned that he encodes in such a way. I repeat that I would very much like to have the option to present lists of visual documentation in a structured way, precisely to avoid having to embed the information in a sentence, because this often costs me a lot of time trying to find a formulation that is suitable to the case. There are many variables (whether or not a previous editor also used all or part of the same visual documentation; whether or not the edition was essentially established before photogrammetry became available, etc. etc.), and having the option of a list outside of the context of the epigraphic lemma can help keep things simple.

I was also imagining that adding the option of a third @type of <listBibl> was not going to be technically difficult, and not going to cost much code-changing time to Michaël.

[danbalogh]

There seem to be two different points here and you are talking beside each other's heads. What @michaelnmmeyer said (imo) was that <bibl> should only be used for actual bibliographic references, which sounds reasonable to me. What @arlogriffiths wants (imo) is to present references in the bibliography division in a structured way. I certainly dislike the idea of adding a mandatory, or even optional, third bibliography, but what's to prevent Arlo from adding a paragraph containing a list in the epigraphic lemma?

<p>Previously unpublished. This digital edition by Arlo Griffiths and Salomé Pichon.
<list>
<item><ref target="https://nakala.fr/10.34847/nkl.aeab806v">DHARMA images by Adeline Levivier</ref></item>
</list>
</p>

The above is compatible with our schema and I assume it can be rendered for display without any additional code writing or revision.
Is it that you want a heading such as "visuals" to automatically appear at the top of such a list? Then perhaps just use

<list><head>Visuals:</head>
<item><ref target="https://nakala.fr/10.34847/nkl.aeab806v">DHARMA images by Adeline Levivier</ref></item>
</list>

This is flagged as an error by our schema, but it seems to be correct TEI so I think it needs only minimal schema revision to permit it.

[arlogriffiths]

I want to insist. I don't understand the resistance to offering a standard manner for encoding the availibility of physical surrogates, any digital images thereof, and any natively digital surrogates. These are archival documents. It is standard practise to list archival documents along with or as part of the bibliography if a publication. It was originally foreseen that this listing would take place by injection of information collected in metadata spreadsheets, but since setting up such injection whas been indefinitely postponed, an alternative solution must be offered, sooner or later. It seems relevant to me that @danbalogh is now actively working on the final revision of our encoding guide, and I have to assume that implementing any structured listing as part of <div type="bibliography"> should not cause any significant new coding work for @michaelnmmeyer, I obviously favor designing and implementing the solution now, and including it in the final release of the EGD, rather than waiting until the project is over.

The solution endorsed by @danbalogh is ad hoc, and I presume he did not intend for it to be described in EGD. This is precisely what I wish to avoid.

The TEI's definition of <listBibl> seems broad enough to cover listings of archival documents. so <listBibl type="surrogates"> could be one option. If that is nevertheless rejected, then perhaps we could try an optional <list type="surrogates">, before or after the standard two <listBibl> options, but in any case outside of the <p>(s) for the
epigraphic lemma.

Whatever we do, it should ideally be set up with a view to ease of conversion to real EpiDoc compliance which would mean using <surrogates> in the <msDesc> part of the teiHeader the https://epidoc.stoa.org/gl/latest/ref-surrogates.html.

[danbalogh]

The reason for my reluctance is that I see little point in devising a standard solution that has to be followed meticulously unless 1, we can expect all or at least most encoders to actually do this in all or at least many documents; and/or 2, we are planning to do some machine action on it that requires this rigour. Neither of these seem to apply here, so indeed, I prefer an ad hoc solution.

That said, I have nothing against the essence of Arlo's suggestion, which I understand to be as follows:

• devise an optional standard manner of listing surrogates in a structured way
• offer that in the EGD
• make sure it is displayed consistently

I think adding <surrogates> to the <msDesc> would be more difficult to display in the desired manner, so we'd better stick to content in the bibliography div.
Arlo says this has to be separate from the <p> of the epigraphic lemma, so we need Michaël to tell us what would be the best solution as regards good TEI practice and ease of implementing schema provisions and display.
We've had the following options so far:

• <listBibl type="visuals"> as a third list in the bibliography div; this would have to be optional or if that is difficult for the schema, an empty skeleton <listBibl type="visuals"><bibl/></listBibl> needs to be added to the template and the existing file
  • this would contain a series of <bibl> items which will contain a combination of plain text and/or <ref> elements pointing to a web URL, but no bibliographic pointers
  • I agree that TEI seems to have nothing against such a use of bibliographic elements, but if allowing this would cause difficulties with the schema and/or with display, then the other option should be considered
• <list type="visuals"> (or, as I suggested above, <list><head>Visuals:</head>, or we could use both @type and <head>) optionally added after the secondary bibliography
  • this would contain a series of <item> elements with the same content as the <bibl> element above

[arlogriffiths]

Just a detail: if introducing active, EpiDoc-compliant use of <surrogate> is a viable option at this stage of the development Michaël's system, then that would be preferable, of course. And in that case, is there anything that stands in the way of displaying the contents of <surrogate> right before or after the contents of our <listBibl>s, even though the contents isn't encoded in that part of the source file? Or if that is difficult, what about using the often empty space in the left side bar of our layout? See the red box in this screenshot:

[michaelnmmeyer]

@arlogriffiths You need to clarify what you want, because above you asked for <listBibl type="visuals">, but now you're talking about <listBibl type="surrogates"> and also about <surrogate>, and you also don't explain what you want to be displayed (and how) in the sidebard.