Re: [jats-list] pub-id-type

Subject: Re: [jats-list] pub-id-type
From: "Pieter Lamers pieter.lamers@xxxxxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 13 Mar 2019 16:46:27 -0000
Dear all,

I agree with Mark that if the id that we are talking about is not an id 
of the article but rather the id of a different /version /of that 
article, then related-article would seem a better fit.

Best
Pieter

On 13/03/2019 17:14, Mark Donoghue m.donoghue@xxxxxxxx wrote:
>
> So, if you're using JATS 1.2 Publishing (Blue) then my initial 
> recommendation stands. That solution leverages the semantics of the 
> element (article-id) while allowing differentiation via the 
> pub-id-type and assigning-authority attributes.
>
> If you are restricted to JATS 1.1 Publishing (Blue) then, despite what 
> the documentationB says (!!!), you have to either abuse the 
> specific-use attribute (totally warranted in this case) or choose a 
> different element to represent that information. Because your stated 
> use is machine processing, standardizing on another element might be a 
> good choice.
>
> The scandalous yet understandable usage could be:
> <article-id pub-id-type="art-access-id" 
> specific-use="bioarxiv-id-linking">576355</article-id>
>
> I don't think that's a good solution but, it's expedient and 
> straightforward to code for. With any luck you'll have moved on to 
> your next job before it came around to bite you.
>
> Another element that also appears in article-meta is related-object. 
> You can use that element to store all sorts of related entities. For 
> example:
>
> <related-object object-type="preprint" object-id="576355" 
> object-id-type="bioarxiv-id" specific-use="external-linking"/>
>
> related-object takes a long list of attributes you can employ to 
> specify the semantics of the usage. The related-object content model 
> is defined in the file JATS-related-object1.ent. All of the attributes 
> defined specifically for that tag (vs. the imported ones) are CDATA, 
> not a fixed list.
>
> You'll no doubt have endless hours of fun working out the particulars :-)
>
> I think the related-object solution is more durable if using JATS 1.1 
> Blue.
>
> I'm out of ideas.
>
> -Mark
>
> - -- --- ----- -------- -------------
> Mark Donoghue
> IEEE
> (732) 562-6045
> m.donoghue@xxxxxxxx <mailto:m.donoghue@xxxxxxxx>
>
> IEEE - Advancing Technology for Humanity
>
>
> On Wed, Mar 13, 2019 at 11:16 AM Debbie Lapeyre 
> dalapeyre@xxxxxxxxxxxxxxxx <mailto:dalapeyre@xxxxxxxxxxxxxxxx> 
> <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx 
> <mailto:jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>> wrote:
>
>     Hi Allb
>
>     I really like the idea of preserving the
>     entire bioRxiv ID as an <article-id>, there
>     can be dozens of <article-id>s as needed.
>
>     bDebbie
>
>     > On Mar 13, 2019, at 5:25 AM, Mike Eden meden@xxxxxxxxxxxxx
>     <mailto:meden@xxxxxxxxxxxxx>
>     <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx
>     <mailto:jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>> wrote:
>     >
>     > Hi All
>     >
>     > Given JATS restrictive list of pub-id-types does anyone have a
>     suggestion for capturing bioRxiv id as an <article-id>
>     > There are more and more preprint services springing up that
>     might require the capture of their ids. Is there a best practise
>     for any value not currently on the list?
>     >
>     > Regards
>     > Mike Eden
>     > Cambridge University Press is the publishing business of the
>     University of Cambridge with VAT registered number GB 823 8476
>     09.B  Our principal office is at University Printing House,
>     Shaftesbury Road, Cambridge, CB2 8BS, United Kingdom.
>     >
>     > Disclaimer
>     >
>     > The information contained in this communication from the sender
>     is confidential. It is intended solely for use by the recipient
>     and others authorised to receive it. If you are not the recipient,
>     you are hereby notified that any disclosure, copying, distribution
>     or taking action in relation of the contents of this information
>     is strictly prohibited and may be unlawful.
>     >
>     > JATS-List info and archive
>     > EasyUnsubscribe (by email)
>
>
>     ================================================================
>     Deborah A LapeyreB  B  B  B  B  B  B  mailto:dalapeyre@xxxxxxxxxxxxxxxx
>     <mailto:dalapeyre@xxxxxxxxxxxxxxxx>
>     Mulberry Technologies, Inc. http://www.mulberrytech.com
>     17 West Jefferson StreetB  B  B  B  B Phone: 301-315-9631 (USA)
>     Suite 207B  B  B  B  B  B  B  B  B  B  B  B  Fax:B  B 301-315-8385
>     Rockville, MD 20850
>     ----------------------------------------------------------------
>     Mulberry Technologies: Consultancy for XML, XSLT, and Schematron
>     ================================================================
>
> JATS-List info and archive <http://www.mulberrytech.com/JATS/JATS-List/>
> EasyUnsubscribe 
> <http://lists.mulberrytech.com/unsub/jats-list/2854576> (by email 
> <>)

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