search

TEIC / TEI

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

Feature Request: <listFigure> element #1861

Open joeytakeda opened 5 years ago

joeytakeda commented 5 years ago

Currently, there is no specific way of listing out figures used within a project, so I propose a new <listFigure> element, which, like <listBibl> and <listPerson>, would work as a database for a centralized list of figures for use throughout a project.

This would be greatly beneficial for projects that are particularly image heavy, but would also be nice for ones that want to store the information about the various site images (logos, favicons, and other images used across the site) without having to necessarily hardcode them into their processing. A <listFigure> would mean that, rather than duplicating s across the project whenever an image is used, the encoder could simply use the following (where "fig" is defined in the <prefixDef>):

<figure copyOf="fig:myFigure1/>

<!--In the figure database-->

<listFigure>
<figure xml:id="myFigure1">
<head>Some head for a figure</head>
<bibl>Some citation for my figure</bibl>
<figDesc>My figure description</figDesc>
<p>Some comments/notes about the figure in question</p>
<graphic url="path/to/my/figure.png"/>
</figure>
</listFigure>

In terms of content model, I think <listFigure> would be a member of model.listLike and the content model would be similar to other <list*> elements: containing an optional <head>, <figure> or <listFigure>s. 

<content>
 <sequence>
  <classRef key="model.headLike"
   minOccurs="0" maxOccurs="unbounded"/>
  <alternate minOccurs="1"
   maxOccurs="unbounded">
   <elementRef key="figure"/>
   <elementRef key="listFigure"/>
  </alternate>
 </sequence>
</content>
sydb commented 5 years ago

To be clear, I am not against this proposal, but I am suspicious about it. I am not sure it is within the TEI’s purview to establish a data structure for graphics used all over a project, particularly those like logos, favicons, and other images used across the site. TEI is not for building websites, it’s for encoding extant humanities texts. If there is a compelling use case in that realm, I’m all in favor. But just for building sites I am far more hesitant.

joeytakeda commented 5 years ago

Hi @sydb --you're absolutely right and my apologies here for muddying that distinction! (Although, I recall reading somewhere about something called "render" (not rend or rendition, but render) for default styling instructions in an ODD. Am I mistaken?)

But, the actual use-case is about encoding extant textual materials: we're building an archive for a writer whose novels often appeared in previous incarnations in serials. These serials and the novels often recycled the same illustrations. We also want to be able to use these images within our born digital essays/materials. So, we need to construct a database-like thing (like in <listPerson> or <listBibl>) of the images used throughout the texts where we can keep the canonical reference of a figure and its metadata (primarily, its illustrator).

sydb commented 5 years ago

Thank you, @joeytakeda; I feel a lot better about this idea now. But rather than @copyOf on <figure>, it might make more sense for a new @ref on either <figure> or <graphic> (or both). Have to think about this a bit …

joeytakeda commented 5 years ago

FWIW, adding @ref on one or both of them sounds right to me.

lb42 commented 5 years ago

A more plausible use case for this might be an archive of early printed books/ illustrated incunabula in which the same woodcut images are re-used. A classic case would be the Bodleian's "wandering jew chronicle" http://wjc.bodleian.ox.ac.uk/

sydb commented 5 years ago

Indeed @lb42, that’s the kind of use case I thought might come up. I have this very vague recollection of my father showing me 2 of his antique books that had the same woodcut illustration, but different captions. But I do not recall which books they were, and skimming the list of his antique books (which were sold in 2015), I don’t see any 2 that are candidates for sharing an image like that. So maybe it’s a partially false memory, he was perhaps just explaining how the same woodcut could be re-used like that.

This @ref vs @copyOf has my head spinning at the moment, though.

And @joeytakeda, perhaps you are thinking of <outputRendition>?

martindholmes commented 5 years ago

There are instances of shared woodcut images in Trish Baer's MyNDIR repository if I remember correctly: http://myndir.uvic.ca. And I think we also see illustrations re-used in Victorian periodicals.

ebeshero commented 5 years ago

Council F2F in Graz recognizes a couple of distinct possible use-cases for a list of figures, but at the moment is not completely convinced that <listFigure> is necessary for the use-case presented here. However, we may want to consider the ways in which we represent metadata about objects (2D and 3D), as well as ways to store representation of a collection of graphics. Action on me (@ebeshero) to work with @joeytakeda on some proposals of what we need for referencing and working with lists of figures in TEI projects.

ebeshero commented 4 years ago

Council notes: <listFigure> would contain canonical identifiers. Think about @sydb 's suggestion that <figure> and/or <graphic> should have @ref or if @copyOf is indeed more appropriate. We're thinking that @copyOf is available globally so it's probably better.

joeytakeda commented 1 year ago

Per council meeting (and drawing on discussion from Graz & Guelph):

Some questions as we move forward:

Martin-de-la-Iglesia commented 11 months ago

We discussed this at this year's SIG Text & Graphics meeting, and we found that it would make sense to encode printed lists of figures using the proposed <listFigure> element, similar to <castList> for printed dramatis personae. (This implies the necessity of @ref in <figure>.)

sydb commented 11 months ago

But the content of a figure reference in a printed list is quite different from that of a figure, isn’t it? My instinct (which may be nutso) is that 

<div type="figureList">
  <head>List of Woodcuts</head>
  <list>
    <item><label>1.</label> [THING1] <ref type="pageNum">8</ref></item>
    <item><label>2.</label> [THING2] <ref type="pageNum">12</ref></item>
    <!-- ... -->
  </list>

(where THINGs are <ref>s, or <name>s, or <figDesc>s, or some such) provides a lot more flexibility than a series of <figure>s would. I am not even sure how one would encode such a list using a series of <figure>s, even if they had @ref. That said, it would only take the addition of <ref> to its content model to allow

<div type="figureList">
  <head>List of Photographs</head>
  <list>
    <figure><label>1.</label> <figDesc>A grainy B&amp;W of John playing a harmonica</figDesc> <ref type="pageNum">10</ref></figure>
    <figure><label>2.</label> <figDesc>Paul playing a bass guitar backwards</figDesc> <ref type="pageNum">12</ref></fiugre>
    <figure><label>3.</label> <figDesc>George grinning broadly while playing guitar</figDesc> <ref type="pageNum">14</ref></fiugre>
    <figure><label>4.</label> <figDesc>Ringo playing the bongos</figDesc> <ref type="pageNum">16</ref></fiugre>
  </list>

This works because I made up descriptions of the photographs; many lists would have the captions or headings instead, no? How would that be encoded?

Martin-de-la-Iglesia commented 11 months ago

Sorry, I don't see where the problem is. Are you saying that you wouldn't want to put captions or headings in <figDesc>? Why not? Isn't "Paul playing a bass guitar backwards" etc. a caption?

lb42 commented 11 months ago

I think theres quite a difference between a caption present in the source being transcribed and a description of the image supplied by the encoder.

Martin-de-la-Iglesia commented 11 months ago

The Guidelines give lots of options for encoding captions inside <figure> (cf. https://tei-c.org/release/doc/tei-p5-doc/en/html/FT.html#FTGRA): head, p, ab type="caption". (There's even an example using figDesc, although I'm not sure how correct that is, but that's not the point here.)