Subject: Re: [jats-list] aff in- or outside of contrib From: "Debbie Lapeyre dalapeyre@xxxxxxxxxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 25 May 2020 22:44:39 -0000 |
1) contrib/aff IMO: JATS allows <aff> as a child of <contrib> precisely for the single-author case (which is what Authoring was also designed for, although almost nobody uses Authoring.) In the modern STEM world, it is not unusual to have 100+ authors. I do not favor contrib/aff, as it can lead to a lot of redundant data. If, as is also common, a single author has 4 or 5 institutional affiliations, the data proliferation gets even worse. 2) contrib-group/aff IMO: This one was allowed, so that publishers could group authors by institution, and only need to input the <aff> once, for the whole group. Rare nowadays, I hope. 3) <aff>s all together AFTER last <contrib-group> IMO: This is the cleanest. Each <aff> is only present once, eliminating redundant data. Yes, you need to use an <xref> on each author pointing to each applicable <aff>. But it is easy for one author to have 5 affiliations and for 100 authors to have only 6 between them. I think this is cleanest for querying as well, as you can write an XPath to find all the <aff>s with the characteristic you want (all from one country or all NIH or whatever) and then get the contributors who have the @rid on their <xref> that matches the @id you found on the <aff> or <aff>s you wanted. This is a Lapeyre not a Mulberry opinion. I do not work for or with JATS4R (good folks though). --Debbie > On May 25, 2020, at 5:38 PM, Pieter Lamers pieter.lamers@xxxxxxxxxxxx <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > Hi All, > > We are looking into refactoring our article-meta structure with regards to affiliations. We now have two practices: > > 1. <aff> is a child of <contrib>, no xref linking needed. > 2. <aff> is a child of <article-meta> (or <contrib-group>), xref linking needed between <contrib> and <aff> > > We are a bit in doubt as to what the preferred format should be. > > A quick check on jats4r.org (https://jats4r.org/authors-and-affiliations) tells me that there is no preferred format for the choice we are facing: "It is the content-providerbs choice which to use". > > Sometimes it is suggested to follow the strictest variant of JATS where possible so we took a look at pumpkin (article-authoring). It appears that (2) is not possible, as <aff> cannot be a child of <contrib-group> or <article-meta>, even though the notes tell us that > > "The linkage from a contributor to an affiliation should be made using the ID/IDREF mechanism. The @id attribute of an <aff> element will be pointed to from one or more <contrib> elements." (https://jats.nlm.nih.gov/articleauthoring/tag-library/1.3d1/element/aff.html ) > > This means that moving away from pattern (1) is making the document less compatible with pumpkin. Not that this is a compelling argument I guess. What I am thinking is: > > a. having <aff> separate means less redundancy in the file (argument for choosing (2) ) > b. having <aff> inside <contrib> is closer to the semantics as I perceive them: affiliation is primarily a property of the author, not of the article (argument in favor of (1) ). > > The demand for statistics of any kind is growing. The other day we were asked to report numbers of articles with a first author affiliated with some affiliation in a list of German institutes. I could report this from an SQL copy of the data, but would like to see the JATS files with the flexible nature of XML as the place to ask, so we are going to add ROR if we can find it, and maybe other identifiers. This would save me from keeping all these data in sync with SQL. But in such a case it would be nice to have a single structure pattern to query and not multiple. > > Any thoughts, anyone? > > Best > Pieter > > > -- > Pieter Lamers > John Benjamins Publishing Company > Postal Address: P.O. Box 36224, 1020 ME AMSTERDAM, The Netherlands > Visiting Address: Klaprozenweg 75G, 1033 NN AMSTERDAM, The Netherlands > Warehouse: Kelvinstraat 11-13, 1446 TK PURMEREND, The Netherlands > tel: +31 20 630 4747 > web: www.benjamins.com > ================================================================ Deborah A Lapeyre mailto:dalapeyre@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Phone: 301-315-9631 (USA) Suite 207 Fax: 301-315-8385 Rockville, MD 20850 ---------------------------------------------------------------- Mulberry Technologies: Consultancy for XML, XSLT, and Schematron ================================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[jats-list] aff in- or outside of c, Pieter Lamers pieter | Thread | Re: [jats-list] aff in- or outside , Melissa Harrison m.h |
[jats-list] aff in- or outside of c, Pieter Lamers pieter | Date | Re: [jats-list] aff in- or outside , Melissa Harrison m.h |
Month |