TEIC / TEI

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

location of model.ptrLike elements within biblStruct #1788

Closed kshawkin closed 5 years ago

kshawkin commented 6 years ago

According to https://github.com/TEIC/TEI/issues/385 , Council once decided that idno should not be used as a child of biblStruct but should instead only be used as a child of analytic, monogr, or series.

However, I've just discovered an instance where ref is given as a child of biblStruct: see the Coombs, Renear, and DeRose example at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COBICOL . In this example, it seems that the ref should be moved to be a child of analytic since the URL relates to the article, not the journal issue.

If we accept that a ref should only be a child of that to which it most closely relates, that the Sukovic example at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COBIXR should also be revised to move the ref from under monogr to under analytic.

The rest of P5, especially the bibliography, should be reviewed as well for consistency.

sydb commented 6 years ago

The good new, @kshawkin, is that the one you noticed (“Markup Systems and The Future of Scholarly Text Processing” in Communications of the ACM 30:11) is the only case of <ptr> or <ref> (or <idno>) as a child of <biblStruct> either in the Guidelines themselves (including the bibliography) or the examples therein.

kshawkin commented 6 years ago

I should add that it's worth considering whether to deprecate model.ptrLike as a child of biblStruct, as was done for idno ( https://github.com/TEIC/TEI/issues/385 ).

sydb commented 6 years ago

My first reaction is that is exactly the right thing to do. But I’d prefer for a few others (besides just you & me) to chime in before actually doing so.

ebeshero commented 6 years ago

I'm assigning this to @jamescummings to see if he agrees with @sydb and @kshawkin . The description of biblStructdoes seem to preclude anything that isn't a "bibliographic sub-element"...

jamescummings commented 6 years ago
  1. I agree that both these examples should be changed to have the ref under analytic.
  2. I'm wary of deprecating model.ptrLike as a child of biblStruct just in case it has been used en masse by anyone. Have you encountered people doing this at all?
kshawkin commented 6 years ago

Regarding (2) ...

The Coombs, Renear, and DeRose example is given in the Guidelines, so I think it's safe to assume that people have imitated this in their encoding. That said, the <ref> in the Coombs, Renear, and DeRose citation was only added in P5 in version 2.2.0 (published 2012-10-25).

But, to the original question, I don't have any direct evidence of this markup in practice.

laurentromary commented 6 years ago

Since it breaks backward compatibility we should deprecate the construct enough in advance rather than changing the content model on the fly. This would prevent discontent.

sydb commented 6 years ago

So it looks to me like we are all in agreement, that a) both examples should be changed b) schema should be changed so that model.ptrLike as a child of <biblStruct> is deprecated; the deprecation period should be a long time, perhaps 3–4 years.

Unless I hear an objection, I will start rolling this ball.

emchateau commented 6 years ago

I’m heavilly using idno as child of biblStruct and find it very convenient to give references for the record separately from the analytic or the monogr elements. For exemple I’ve got a bibliographic list of all printed books for a given title in my corpus. Each BiblStruct is derived from a catalog record wich have an id and is available as linked open data. So I refer to this record through an idno :

<biblStruct xml:id="brice1717" type="manifestation">
               <monogr>
                  <author> <persName ref="#briceGermain"> <forename>Germain</forename>
                     <surname>Brice</surname> </persName> </author>
                  <title level="m"
                     >Description de la ville de Paris et de tout ce qu’elle contient de plus remarquable, par Germain Brice ; enrichie d’un nouveau plan et de figures dessinées et gravées correctement. 7e édition, revue et augmentée par l’auteur</title>
                  <imprint>
                     <date when="1717">1717</date>
                     <pubPlace>Paris</pubPlace>
                     <publisher>F. Fournier</publisher>
                  </imprint>
                  <extent>In-12</extent>
               </monogr>
               <idno type="catBnf">http://catalogue.bnf.fr/ark:/12148/cb30160624f/</idno>
            </biblStruct>

The idno is not the one of the book, neither the one of the exemplar, but the one of the record. In the french national library catalog, p.e., there are multiple records for one single exemplar. The book in itself could have an id, for exemple, in a national bibliography system. And sometimes, one record for multiple exemplars wich are individualy identified by their "cote".

So there are use cases where it’s needed to describe the source of the description distinctly from the object itself. And that‘s my case for the digital edition of a large corpora of travel books about Paris where we are giving, in parallel of the edited exemplar, a systematic bibliography of the published editions and localised exemplars in some french collections.

All the more we should consider the possibility to use biblstuct according to the FRBR which is currently not possible with the TEI

kshawkin commented 6 years ago

Emmanuel, thank you for this interesting example. My first thought was to say that, even though your identifier is for the catalog record, there's no reason the <idno> should not be a child of <monogr>. However, if you were encoding an analytic catalog record (a rarity in libraries, but one that exists), then parts of the record would be encoded within <analytic> and other parts in <monogr>, and the only sensible place for the identifier for the catalog record would be as a child of <biblStruct>.

So, it seems that the way forward is to adjust the examples currently in the Guidelines (what Syd lists as (a) above) but not change the schema. It would be helpful if the Guidelines could include your example and explain that <idno> should only be used as a child of <biblStruct> as an identifier for the bibliographic description itself (such as a catalog record), not for any component of the bibliographic item (such as a DOI, ISSN, or ISBN).

emchateau commented 6 years ago

Yes, it’s a matter of semantic because it is not describing the same thing ! I think, that’s really important, especially in the perspective of the semantic web.

The idno child of a monogr is describing the monogr element. Currently my idno is describing the bibliographical description, that’s why it is child of the biblStruct. All the more, the fact that idno doesn’t allow other attributes than @type to categorize them, makes it difficult to distinct them if we are not using the TEI hierarchy of elements.

What do you mean by not changing the schema ? that it wouldn‘t be allowed by default, at least that we customise it with ODD ? How would this use of idno as child of biblStruct would then be conformant with TEI-all ? (currently it seems that it is not allowed anymore with TEI-all)

By the way, in monogr and analytic, I don’t see any reason why the order of idno is prescribed in the childs sequence.

And an other matter about idno, there are cases when we need to use it with various king of identifiants. For exemple, ISNI have ISNI numbers and ISNI uris, the same for ORCID, etc. In library catalogs, you often have an id for a record which is sometime different from the permalink URI or handle, purl, and so on. Curently, the fact that you can’t categorize by other mean the idno element that by @type, doesn’t allo to say this is an URI or an ID and is from xxx source.


<listBibl>
  <!-- ... -->
  <biblStruct xml:id="brice1717" type="manifestation">
    <monogr>
      <author>
        <persName ref="#briceGermain"> 
          <forename>Germain</forename>
          <surname>Brice</surname>
       </persName>
      </author>
      <title level="m">Description de la ville de Paris et de tout ce qu’elle contient de plus remarquable, par Germain Brice ; enrichie d’un nouveau plan et de figures dessinées et gravées correctement. 7e édition, revue et augmentée par l’auteur</title>
    <imprint>
      <date when="1717">1717</date>
      <pubPlace>Paris</pubPlace>
      <publisher>F. Fournier</publisher>
    </imprint>
    <extent>3 vol. ; In-12</extent>
    <idno type="bnf">8-LK7-6002 (A,1)</idno>
    <idno type="bnf">8-LK7-6002 (A,2)</idno>
    <idno type="bnf">8-LK7-6002 (A,3)</idno>
    <!-- <idno type="frenchNationalBibliography">if I had one</idno> -->
  </monogr>
  <idno type="catBnf">http://catalogue.bnf.fr/ark:/12148/cb30160624f/</idno>
</biblStruct>
</listBibl>```
kshawkin commented 6 years ago

See below ...

What do you mean by not changing the schema ? that it wouldn‘t be allowed by default, at least that we customise it with ODD ? How would this use of idno as child of biblStruct would then be conformant with TEI-all ? (currently it seems that it is not allowed anymore with TEI-all)

I was referring to the discussion above on this issue, which Syd summarized as item (b) in his list of things to implement: deprecating use of all model.ptrLike elements as a child of <biblStruct>, instead only allowing them as children of <analytic>, <monogr>, or <series>.

But now I realize that you are discussing use of <idno> in these locations, not model.ptrLike elements! That, in turn, refers back to #385, where <idno> was deprecated as a child of <biblStruct> and in fact has been removed entirely as an allowed child of <biblStruct>:

https://github.com/TEIC/TEI/commit/c9279125b98c125502be42ed740c546409927c32#diff-e971f879792ed08d3991da2c0cb08bf9

As you'll see in the comment on lines 49-51 at the link above, Council had decided that you should use <ptr/> or <ref> for identifiers. Thus your example would better be:

<biblStruct xml:id="brice1717" type="manifestation">
    <monogr>
      <author>
        <persName ref="#briceGermain"> 
          <forename>Germain</forename>
          <surname>Brice</surname>
       </persName>
      </author>
      <title level="m">Description de la ville de Paris et de tout ce qu’elle contient de plus remarquable, par Germain Brice ; enrichie d’un nouveau plan et de figures dessinées et gravées correctement. 7e édition, revue et augmentée par l’auteur</title>
    <imprint>
      <date when="1717">1717</date>
      <pubPlace>Paris</pubPlace>
      <publisher>F. Fournier</publisher>
    </imprint>
    <extent>3 vol. ; In-12</extent>
    <idno type="bnf">8-LK7-6002 (A,1)</idno>
    <idno type="bnf">8-LK7-6002 (A,2)</idno>
    <idno type="bnf">8-LK7-6002 (A,3)</idno>
    <!-- <idno type="frenchNationalBibliography">if I had one</idno> -->
  </monogr>
  <ptr type="catBnf" target="http://catalogue.bnf.fr/ark:/12148/cb30160624f/"/>
</biblStruct>

(or replace <ptr/> with <ref> if you prefer).

If you don't think this is appropriate for your need, I suggest creating a new issue here in GitHub, proposing that <idno> be added back as a child of <biblStruct>.

By the way, in monogr and analytic, I don’t see any reason why the order of idno is prescribed in the childs sequence.

If I understand correctly, you are saying that do not see any particular reason for <idno> to occur in a particular order among the child elements of <biblStruct>. As you can see from the content model of <biblStruct>, the order of child elements is flexible following <series>.

And an other matter about idno, there are cases when we need to use it with various king of identifiants. For exemple, ISNI have ISNI numbers and ISNI uris, the same for ORCID, etc. In library catalogs, you often have an id for a record which is sometime different from the permalink URI or handle, purl, and so on. Curently, the fact that you can’t categorize by other mean the idno element that by @type, doesn’t allo to say this is an URI or an ID and is from xxx source.

Germain Brice Description de la ville de Paris et de tout ce qu’elle contient de plus remarquable, par Germain Brice ; enrichie d’un nouveau plan et de figures dessinées et gravées correctement. 7e édition, revue et augmentée par l’auteur 1717 Paris F. Fournier 3 vol. ; In-12 8-LK7-6002 (A,1) 8-LK7-6002 (A,2) 8-LK7-6002 (A,3) http://catalogue.bnf.fr/ark:/12148/cb30160624f/ ```

Remember that you should use <ptr/> or <ref> rather than <idno> for URIs rather. Also keep in mind that @subtype is available on <idno> in addition to @type.

emchateau commented 6 years ago

Thanks a lot for your reply. It‘s my mistake because I’ve confond te two issues. I’m really concerned by the suppression of idno from biblStruct and I don’t understand why it have been done. So, I may reopen the issue. Thanks also for @subtype, didn’t knew about it, it solve the issue for links.

sydb commented 6 years ago

Right, @emchateau is clearly talking about <idno> child of <biblStruct>, and thus should re-open (or otherwise re-raise) #385.

on @emchateau’s question

That ticket was opened in 2012 and resolved in 2014, so I would not hold my breath for it to change, especially given that the use case you’re talking about probably calls for <ptr>, not <idno>.

Note, BTW, @emchateau, that <ptr> also has

It does not, however, have all the dating attributes that <idno> has. It (<ptr>) does have @cRef (intended as an alternate to @target), but I think it is better to use a locally abbreviated URI and a <prefixDef> these days.

on the real point of this ticket

So … does the discussion of <idno>, above, make us think we should not deprecate the use of model.ptrLike as a direct child of <biblStruct>? (I.e., negating my (b), above, as @kshawkin pointed out 12 days ago

kshawkin commented 6 years ago

That's right, I believe the consensus is to do just the following:

  1. Adjust the Coombs, Renear, and DeRose example to move the <ref> under <analytic>.
  2. Add Emmanuel's first example to P5 except change <idno type="catBnf">http://catalogue.bnf.fr/ark:/12148/cb30160624f/</idno> to <ptr type="catBnf" target="http://catalogue.bnf.fr/ark:/12148/cb30160624f/"/>.

No schema changes needed.

martinascholger commented 5 years ago

Do you mind if I steal this from you, @jamescummings?

In addition to the Coombs, Renear, and DeRose example, the Sukovic example at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COBIXR should also be adjusted (make ref a child of analytic instead of monogr), right? @kshawkin mentioned it at the beginning.

I would add Emmanuel's example at the end of http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COBIXR and propose this description

"The <ptr> element may be used as a child element of <biblStruct> to refer to a bibliographic description itself, such as a catalog record:"

Can we mark this green?

jamescummings commented 5 years ago

Feel free. Thanks! I concur with your plan.

lb42 commented 5 years ago

"to refer to a bibliographic description itself, such as..."

This doesn't sound right. What is the "itself" doing in there? Given that a biblStruct is a bibliographic description, it would be plausible to write "to refer to the bibliographic description itself..." if you meant to specify that the ptr element can refer to its containing element, but I don't think you did (the "such as..." suggests that you did not). A simpler rewording:

"to refer to any related bibliographic description such as a ..."

which reminds me that somewhere you need to explain whether this is an alternative to or an improvement on using <relatedItem> or something entirely different.

martinascholger commented 5 years ago

At F2F Washington, Council agreed with this rewording: "The <ptr> element may be used as a child element of <biblStruct> to refer to the online catalog record of this bibliographic item:"

emchateau commented 5 years ago

Thanks a lot for the follow up. I’ll correct my encoding with this solution. Best regards, Emmanuel

Le 12 juin 2019 à 02:51, Martina Scholger notifications@github.com a écrit :

At F2F Washington, Council agreed with this rewording: "The element may be used as a child element of to refer to the online catalog record of this bibliographic item:"

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TEIC/TEI/issues/1788?email_source=notifications&email_token=AAGH3PMW2VT3SPS5C5KZ6BLP2CMF3A5CNFSM4FJYOHWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXPNVEY#issuecomment-501144211, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGH3PKNTIQLQYXZFS2T3LLP2CMF3ANCNFSM4FJYOHWA.

martinascholger commented 5 years ago

Close, 00615f2

glorieux-f commented 1 year ago

I’m working on the TEI translator for Zotero, thanks for this interesting discussion. The translator should be corrected, the output of URL of an item is odd (?? ), but there is a nice idea for @emchateau, a @corresp attribute for the URL of the record.

<biblStruct type="journalArticle" xml:id="de_Rougemont2010" corresp="http://zotero.org/users/8989645/items/DITJYYQ3">
    <analytic>
      <title level="a">Le théâtre en France sous l'Ancien Régime : à l'origine de l'exception culturelle française.</title>
      <idno type="DOI">10.3917/rip.252.0199</idno>
      <title type="short">Le théâtre en France sous l'Ancien Régime</title>
      <author><forename>Martine</forename><surname>de Rougemont</surname></author>
    </analytic>
    <monogr>
      <title level="j">Revue internationale de philosophie</title>
      <idno type="ISSN">0048-8143</idno>
      <imprint>
        <biblScope unit="volume">252</biblScope>
        <biblScope unit="issue">2</biblScope>
        <biblScope unit="page">199-206</biblScope>
        <date>2010</date>
        <note type="accessed">2023-06-13T15:09:31Z</note>

        <note type="url">https://www.cairn.info/revue-internationale-de-philosophie-2010-2-page-199.htm</note>

      </imprint>
    </monogr>
  </biblStruct>