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

["Mike Eden meden@xxxxxxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Mark, Pieter,
Good point well made. Thank you
I will have to consider further.
________________________________
From: Pieter Lamers pieter.lamers@xxxxxxxxxxxx
<jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Sent: 13 March 2019 16:53:08
To: jats-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [jats-list] pub-id-type


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<mailto: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
documentation 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@xxxxxxxxxx
errytech.com>> wrote:
Hi All

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.

Debbie

> On Mar 13, 2019, at 5:25 AM, Mike Eden
meden@xxxxxxxxxxxxx<mailto:meden@xxxxxxxxxxxxx>
<jats-list-service@xxxxxxxxxxxxxxxxxxxxxx<mailto:jats-list-service@xxxxxxxxxx
errytech.com>> 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. 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 Lapeyre
mailto:dalapeyre@xxxxxxxxxxxxxxxx<mailto:dalapeyre@xxxxxxxxxxxxxxxx>
Mulberry Technologies, Inc.
http://www.mulberrytech.com<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
================================================================

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<http://www.benjamins.com>

JATS-List info and archive<http://www.mulberrytech.com/JATS/JATS-List/>
EasyUnsubscribe<http://lists.mulberrytech.com/unsub/jats-list/176260> (by
email<>)