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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [jats-list] Identifying the typ, Gareth Oakes goakes@ | Thread | Re: [jats-list] Identifying the typ, Pieter Lamers pieter |
Re: [jats-list] Identifying the typ, Gareth Oakes goakes@ | Date | Re: [jats-list] Identifying the typ, Pieter Lamers pieter |
Month |