jTEI: Allowing <notesStmt> ?

[FrederikeNeuber]

Hi, as I've already mentioned in thread #1692 the review journal RIDE plans to switch to jTEI. RIDE is a review journal of digital resources (at the moment for digitial scholarly editions and digital text collections but other types of resources will follow). With every review we provide basic information about the reviewed source. Right now we encode this information in <notesStmt>:

      <notesStmt>
        <relatedItem>
          <biblStruct>
            <monogr>
              <title xml:id="resource_title">CELT - Corpus of Electronic texts</title>
              <editor xml:id="resource_editors">Hiram Morgan</editor>
              <respStmt>
                <resp>Editor</resp>
                <persName>
                  <name>Hiram Morgan</name>
                </persName>
              </respStmt>
              <imprint>
                <date xml:id="resource_date_publication">1997</date>
              </imprint>
            </monogr>
            <idno xml:id="resource_uri">http://celt.ucc.ie/</idno>
          </biblStruct>
        </relatedItem>
        <note>
          <date xml:id="resource_date_access">2017-05-31</date>
        </note>
      </notesStmt>

I can't really see where to put this information in the current jTEI.

I think review sections are very common in humanities journals, so not only RIDE would benefit from the inclusion of <notesStmt> in jTEI but also other potential users of jTEI.

[martindholmes]

I would argue very strongly against <biblStruct>, and in favour of <bibl> instead; it's far more flexible and much easier to process. Whether the info about the document being reviewed belongs in <notesStmt> is a broader question that I'd like other people to chime in on.

[FrederikeNeuber]

We decided for biblStruct because of the way this data is recorded. Alongside with the reviews we provide a factsheet, so each review is a mix of prose and structured data. The bibliographical description belongs to the latter. Reviewers are asked to enter in a web form all collaborators of an edition with their respective roles. The idea behind was to credit not only the work of the editors-in-chief but to also of the programmers, encoders, etc. people, that usually disappear in bibliographic descriptions. Maybe the example above is not a good one because it is rather short and really more <bibl>-case. This one explains it better:

<notesStmt>
        <relatedItem>
          <biblStruct>
            <monogr>
              <title xml:id="resource_title">The Shelley-Godwin Archive</title>
              <editor xml:id="resource_editors">Elizabeth C. Denlinger, Neil Fraistat</editor>
              <respStmt>
                <resp>Editor</resp>
                <persName>
                  <name>Elizabeth C. Denlinger</name>
                </persName>
              </respStmt>
              <respStmt>
                <resp>Editor</resp>
                <persName>
                  <name>Neil Fraistat</name>
                </persName>
              </respStmt>
              <respStmt>
                <resp>Encoder</resp>
                <persName>
                  <name>Trevor Munoz</name>
                </persName>
              </respStmt>
              <respStmt>
                <resp>Programmer</resp>
                <persName>
                  <name>Travis Brown</name>
                </persName>
              </respStmt>
              <respStmt>
                <resp>Encoder</resp>
                <persName>
                  <name>David Brookshire</name>
                </persName>
              </respStmt>
              <respStmt>
                <resp>Programmer</resp>
                <persName>
                  <name>Raffaele Viglianti</name>
                </persName>
              </respStmt>
              <respStmt>

<!-- other contributors - long list -->

             <respStmt>
                <resp>Advisor</resp>
                <persName>
                  <name>Wendell Piez</name>
                </persName>
              </respStmt>
              <respStmt>
                <resp>Advisor</resp>
                <persName>
                  <name>Josh Wilner</name>
                </persName>
              </respStmt>
              <imprint>
                <date xml:id="resource_date_publication">2013</date>
              </imprint>
            </monogr>
            <idno xml:id="resource_uri">http://shelleygodwinarchive.org/</idno>
          </biblStruct>
        </relatedItem>
        <note>
          <date xml:id="resource_date_access">2013-11-30</date>
        </note>
      </notesStmt>

This should explain the use of biblStruct. Maybe a possible solution in jTEI might include both the use of bibl and of biblStruct.

[lb42]

I tend to agree with Martin in preferring bibl to biblStruct: you can constrain the order of its contents if you need to by adding a schematron rule or redefining its content in your ODD, and it already includes all the elements you need (including respStmt).

However the real question is where to put this bibliographic description. notesStmt is not wrong but it seems a bit arbitrary. Since you are describing the item which is actually the subject of the review, I wonder whether sourceDesc or even titleStmt might be a better home for it. It would be interesting to know what other cataloguers do with such items.

[lb42]

I forgot to add (but presumably you're aware) that that example is not actually valid against TEI All: <idno> isnt permitted there.

[rvdb]

This makes me wonder if we're dealing with a "research article" here, which currently is the only use case for the journal, and for which we've defined some specific Schematron constraints that might not apply to a review (article). Or, put differently: would allowing <notesStmt> (or finding a more appropriate place for this information) solve all issues of encoding reviews in jTEI, or would that require a different kind of article type in jTEI?

[martindholmes]

I think it would need a different article type, for sure, and I'm inclined to think we should address that need with more careful thought than simply adding features that are currently in use in other contexts. I share Lou's slight unease about <notesStmt>, and indeed we do use <titleStmt> for basic information about the reviewed text in the Scandinavian Canadian Studies Journal, although we also include full bibliographic information in the <front> (because it needs to be rendered out for readers, of course). (We used to use <biblStruct> but switched to <bibl> a long time ago.) I think I would argue that the information about the text being reviewed does need to be in the <text> itself, since the reader needs to see it.

The problem with <biblStruct> is that it's horrendous to process into output that conforms with any styleguide. If you use <bibl>, you can put the items in the exact order that your target styleguide requires, with all the intervening punctuation, and then processing is trivial; meanwhile, all the core info is still tagged, so any harvesting processor can find the information it needs. From a strictly practical point of view, the jTEI format needs to be processible into three different forms (ODT, PDF and OpenEdition), and I think adding <biblStruct> into the mix would make that extremely difficult.

[FrederikeNeuber]

we also include full bibliographic information in the (because it needs to be rendered out for readers, of course). (We used to use but switched to a long time ago.) I think I would argue that the information about the text being reviewed does need to be in the itself, since the reader needs to see it.

I am not sure whether I understand the argumentation. I think the decision what is rendered to the user or not has nothing to do with <teiHeader> oder <text>. But anyway, I think we have a different conception of front and teiHeader. So far, I have understood the former as something that encodes the preceding information of a document. I have always understood "document" as a source found here, which can be edited; usually a book or manuscript (cf. Guidelines "found at the start of a document"). If I create a new source myself, I would not conceive it like a "book", but would write data about the data in text into the teiHeader. Maybe I got the scope of <front> and <back>wrong so far or there are diffent ways to interprete it?

the jTEI format needs to be processible into three different forms (ODT, PDF and OpenEdition)

.. and "normal" HTML? A general question: Is the format now primarily designed for the TEI Journal or should it become a general format for digital publishing in the future? If the former, we would simply take care of our own extensions to the current scheme. If the latter I continue to create issues..

[martindholmes]

@FrederikeNeuber there are indeed lots of ways to look at academic articles when you're treating them as born-digital files; Laurent and I wrote at length about this some years ago: https://hal.archives-ouvertes.fr/hal-00390966/fr/. Over the years I've ended up taking different approaches, but I think my general feeling is that anything a reader would expect to see in a printed version of the article should be in <text>, while the header should contain all metadata (including title, author etc., but not limited to that).

The jTEI format was designed initially for the Journal of the TEI only (and hence it has built-in transformations to ODT, PDF and OpenEdition, which are the outputs the journal needs, but not [yet] to HTML, because revues.org does that from the OpenEdition version automatically). However, I would like to see it become broadly used, so we're open to adding features not currently used by the journal. I would definitely vote against <biblStruct>, though. Personally I'd like to see it removed from TEI completely.

[FrederikeNeuber]

@martindholmes sorry for the late reply and thanks for the clarification. We will consider switching to <bibl> instead of <biblStruct>. Do you think would be more appropriate than to give information about the reviewed resource, e.g. as follows:

      <sourceDesc>
        <bibl>
          <title xml:id="resource_title">The Shelley-Godwin Archive</title>
          <editor xml:id="resource_editors">Elizabeth C. Denlinger, Neil Fraistat</editor>
          <respStmt>
            <resp>Editor</resp>
            <persName>
              <name>Elizabeth C. Denlinger</name>
            </persName>
          </respStmt>
          <respStmt>
            <resp>Editor</resp>
            <persName>
              <name>Neil Fraistat</name>
            </persName>
          </respStmt>
          <respStmt>
            <resp>Encoder</resp>
            <persName>
              <name>Trevor Munoz</name>
            </persName>
          </respStmt>
          <respStmt>
            <resp>Programmer</resp>
            <persName>
              <name>Travis Brown</name>
            </persName>
          </respStmt>
          <respStmt>
            <resp>Encoder</resp>
            <persName>
              <name>David Brookshire</name>
            </persName>
          </respStmt>
          <date xml:id="resource_date_publication">2013</date>
          <idno xml:id="resource_uri">http://shelleygodwinarchive.org/</idno>
        </bibl>
      </sourceDesc>

[FrederikeNeuber]

In general, I am not sure, if it would really make sense to distinct types of articles with different encoding models. The only difference that I can see between a review and a "normal" research article is that in the former case you need to capture information about the reviewed source somewhere.

I still think that <notesStmt> would be maybe the better option than <sourceDesc>. The latter would maybe work to include information about a reviewed source, but in other cases, where one would need to give further bibliographic information that is relevant for an article, its definition would be to restrictive. For instance, in conference proceedings one would want to provide a link to the original call for papers, the conference web site or the book of abstracts. I think <notesStmt> could be a proper place to put such additional or related (bibliographic) information.

[laurentromary]

In one of our projects where we have various types of sources, we have introduced typed listBibl's in sourceDesc to contextualize our various bibliographical descriptions.

[rvdb]

@FrederikeNeuber Well, since jTEI encoding is quite output-oriented (or at least tightly bound to a processing layer of XSLT stylesheets that produce different output formats for jTEI articles), it does make sense to make the expectations for the processing layer as explicit as possible. For example, when publishing a research article, there's no place in the output for the kind of source description you're proposing. On the other hand, it would probably be required for a review, in a very specific form, with matching processing rules in the XSLT stylesheets. Therefore, some kind of differentiation mechanism would help to keep the different "templates/genres/article types" and their processing logic clean, and separate them into either specific Schematron constraints or specific ODD files (if the differences are substantial), IMO.

[martindholmes]

@FrederikeNeuber I'm following up on this rather belatedly to see if you made a decision about bibl vs biblStruct, and to push the discussion forward a little. Laurent's suggestion is a good one; I think a stucture such as this:

   <sourceDesc>
      <listBibl type="reviewedText">
         <bibl>
            <title xml:id="resource_title">The Shelley-Godwin Archive</title>
            <editor xml:id="resource_editors">Elizabeth C. Denlinger, Neil Fraistat</editor>
            [...]
         </bibl>
      </listBibl>
   </sourceDesc>

would work nicely. I'd argue for a listBibl in every case, because often multiple texts or resources are reviewed simultaneously; if there's only one, the listBibl is rather superfluous, but it would be simpler to be consistent and use it every time.

Any comments, anyone?

[martindholmes]

@FrederikeNeuber I didn't get any response to my last question from anyone. As far as I can see, the only issue preventing you from using the encoding specified above (listBibl/bibl in sourceDesc) is the absence of <respStmt> and <resp> in the jTEI schema. If you concur, let me know, and I'll raise a ticket for adding those elements (which I think would be perfectly justified -- a jTEI article may be translated or proofread by someone, after all, and we should use a standard method of crediting them). If I don't hear anything, though, I'll just close this ticket.

[FrederikeNeuber]

Hi and sorry for the late reply, I got lost in other work.

In the meantime, not least because of the discussion in this issue, we moved from biblStruct to bibl. Transferring the information about the reviewed resource to sourceDesc would be in my opinion a good option. Also using type-attributes for listBibl is a good idea and necessary for us, since we include also a reference to our reviewing guidelines. Here the current encoding:

`

Steven Olsen-Smith; Peter Norberg; Dennis C. Marnon Editor Peter Norberg Editor Dennis C. Marnon 2008 http://martianus.huygens.knaw.nl 13.04.2014 Criteria for Reviewing Scholarly Digital Editions

`

Besides the respStmt, it the type-attributes are currently not allowed, but I guess there is also no option to allow them, since this would make the jTEI scheme of course to fuzzy. So, a conclusion I guess an extra ticket for respStmt in bibl for jTEI would be great! Thanks everyone for the input!

[edit: sorry, I closed the issue accidentally. I leave it to you @martindholmes whether we move to a new ticket or continue here]

[martindholmes]

Closing: moving the discussion to issue #1812.