Re: [jats-list] Identifying the typesetter for an article

Subject: Re: [jats-list] Identifying the typesetter for an article
From: "Pieter Lamers pieter.lamers@xxxxxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 13 Sep 2019 11:36:33 -0000
I'm with Laura and Sacha. Our solution was to use PIs for such info as 
below:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.1 20151215//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink"; article-type="research-article" xml:lang="en">
 B B B  <?version number="1" author="ccs" date="2018-11-10"?>
 B B B  <?version number="2" author="ccs" date="2018-11-28"?>
 B B B  <?version number="3" author="doi-lookup" date="2018-12-11"?>
 B B B  <?version number="4" author="ccs" date="2019-08-05"?>
 B B B  <?version number="5" author="ccs" date="2019-09-05"?>
 B B B  <front>
 B B B B B B B  <journal-meta>[...]

where 'ccs' is the name of the tagger.

Best
Pieter

On 13/09/2019 12:38, Randall, Laura (NIH/NLM/NCBI) [E] 
laura.randall@xxxxxxx wrote:
> JB> I would argue that this metadata, even if only used internally, can be integral to a **JATS XML file**
>
>
>
> This is where I take issue with the suggestion that this be something added to the Tag Suite. Yes, this information can be integral to an XML file, but we're really clear in the JATS rationales that the intent is to capture and preserve intellectual content of the *ARTiCLE*--not the file. The typesetter information belongs to a *FILE*, something that can change even if the intellectual content of the article does not.
>
>   
>
> To Vincent's comment about a need being identified by more than one user: Yes, clearly that's true. However, that need is very clearly (to me, anyway) outside the defined scope of the JATS. So while the JATS Standing Committee does take user needs into consideration, we must also adhere to the scope that's been defined for the project. File (not article) information is not within the scope of JATS
>
>
>
> Laura
>
>
>
>
>
> ________________________
>
> Laura Randall
>
> laura.randall@xxxxxxx
>
> NCBI/NLM/NIH
>
>
>
> -----Original Message-----
>
> From: Gareth Oakes goakes@xxxxxxx <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
>
> Sent: Thursday, September 12, 2019 6:04 PM
>
> To: jats-list@xxxxxxxxxxxxxxxxxxxxxx
>
> Subject: Re: [jats-list] Identifying the typesetter for an article
>
>
>
> Hi all,
>
>
>
>      
>
>
>
> TU> 1. This seems to me to be internal tracking information, not the sort of content that is interchanged. So I am not sure it is within the scope of JATS.
>
>
>
>      
>
>
>
> JB> I would argue that this metadata, even if only used internally, can be integral to a JATS XML file.
>
>
>
>      
>
>
>
> I think the trick will be to define what metadata should live in the JATS XML versus what should live in the production database you're using to store your XML articles. If you're not using a database then I guess you have nowhere else to put the metadata than the JATS XML. If you are using a database then you need to define which metadata is synced to the database and the directionality of the syncing e.g. at what points the XML should be considered authority versus at what points the database should be considered authority.
>
>
>
>
>
>
>
> In terms of how the metadata is represented there are good arguments to be made for each approach e.g. using/misusing existing tagging, peppering with your own PIs, or layering your own enhanced tagging schema over the top of JATS (then stripping back your enhancements for interchange purposes. We have clients using one or more of these approaches, sometimes in parallel, but I think if you are being rigorous about your system and have the opportunity to architect properly then the last approach is a pretty nice way to go.
>
>
>
>
>
>
>
> That's all my software engineering perspective anyway __ For reference, in S1000D, they have gone "all the way" and have pretty much every field from the CSDB (database) in each data module (XML file) as tagged metadata.
>
>
>
>
>
>
>
> I hope that helps the discussion.
>
>
>
>
>
>
>
> |G| Gareth Oakes
>
>
>
> |P| Chief Architect, GPSL
>
>
>
> |S|
>
>
>
> |L| www.gpsl.co
>
>
>
>
>
>
>
>
>
>
>
> 

-- 
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

Current Thread