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

Subject: Re: [jats-list] Identifying the typesetter for an article
From: "Randall, Laura (NIH/NLM/NCBI) [E] laura.randall@xxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 13 Sep 2019 10:38:46 -0000
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

Current Thread