Re: [jats-list] Versions of an article

Subject: Re: [jats-list] Versions of an article
From: Alexander Schwarzman <aschwarzman@xxxxxxxxx>
Date: Thu, 9 May 2013 16:22:15 -0400
This is a bit off-topic but I just wanted to note that CrossMark makes
it possible to mark one version of the article as being the official
one, and then link to the other versions via their own DOIs. This,
however, still won't help solving the citation miscounting problem.

Alexander ('Sasha') Schwarzman
Content Technology Architect
OSA - The Optical Society
2010 Massachusetts Ave., NW
Washington, DC 20036  USA
Direct: +1.202.416.1979
Email: aschwarzman@xxxxxxx
http://www.osa.org


On Thu, May 9, 2013 at 4:12 PM, Alf Eaton <eaton.alf@xxxxxxxxx> wrote:
> That is indeed a good point about the difficulty of resolving metadata
> to a DOI when there are multiple versions of the same metadata (and
> presumably also finding that the same article shows up multiple times
> in search indexes that use the DOI as a key, such as CrossRef's).
>
> I do quite like the idea of registering the DOI for each version as a
> component of a parent article (which would have the generic DOI).
> While CrossRef makes the "component" relationship explicit, DataCite
> operates differently, and has this guidance in its schema[1], for the
> "Version" field:
>
> "Register a new DOI (or primary identifier) when the version of the
> resource changes to enable the citation of the exact version of a
> research dataset (or other resource). May be used in conjunction with
> properties 11 and 12 (AlternateIdentifier and RelatedIdentifier) to
> indicate various information updates."
>
> I'll have to look further into whether the RelatedIdentifier property
> makes it possible to link multiple versions to a single "parent"
> article.
>
> Alf
>
> [1] http://schema.datacite.org/meta/kernel-2.2/metadata.xsd
>
> On 9 May 2013 20:39, Bruce Rosenblum <bruce@xxxxxxxxx> wrote:
>> Alf,
>>
>> I absolutely do believe that you can assign DOIs to preprints, and in fact I
>> encourage it if the preprints will be made accessible.
>>
>> However I've seen the case of the F1000 example you've cited below, and I
>> think F1000 will create lots of problems when services try to look up DOIs
>> to their articles that have not been cited by DOI. Yes, I know F1000 wants
>> everyone to cite their articles by DOI, but the reality is that lots of
>> authors still don't understand DOI and lots of editorial styles don't
>> properly account for it, and so whether F1000 likes it or not, they will
>> find at least some citations to their articles lacking a DOI. Once the DOI
>> is gone from the citation, and you have two or more DOIs with the same
>> authors, article title, journal name, and year, any system that accepts only
>> a single DOI match on a lookup (which I believe is most systems doing DOI
>> matching) will fail to retrieve a DOI. This may ultimately cause some F1000
>> citations to be left uncounted, which I do not believe is the goal of their
>> editors.
>>
>> If you want to do assign a unique DOI to each version (and remember, I'm
>> still not in favor of doing this), at least look at what eLife has done
>> where:
>>
>>         http://dx.doi.org/10.7554/eLife.00459
>>
>> points to an article, and then lots of DOIs have been registered as
>> components of that article, e.g. http://dx.doi.org/10.7554/eLife.00459.001.
>> Making each version of the article a component of a parent DOI is a model
>> that can work.
>>
>> Bruce
>>
>>
>> At 03:25 PM 5/9/2013, Alf Eaton wrote:
>>>
>>> That's an interesting point to debate, and I think it mostly depends
>>> on how much the content is likely to change between versions (in this
>>> particular case it's article preprints, which could change
>>> considerably between versions).
>>>
>>> For example, F1000 Research mint DOIs only for each version of an article:
>>> http://dx.doi.org/10.12688/f1000research.2-79.v1
>>> http://dx.doi.org/10.12688/f1000research.2-79.v2
>>> They still have a generic non-versioned URL for the article (as well
>>> as the versioned URLs), but not an article-level DOI.
>>>
>>> Dryad's guidelines <http://wiki.datadryad.org/DOI_Usage>, on the other
>>> hand, recommend to have both a generic, over-arching DOI for all
>>> versions of a dataset, as well as one DOI for each specific version of
>>> the dataset. This seems like the most appropriate option, as it allows
>>> someone to choose to cite either the whole "work" (possibly while
>>> specifying a particular point in time) or a specific version, as they
>>> prefer.
>>>
>>> There are also inevitably going to be different DOIs for the same
>>> "work", if a preprint is published on one service (and assigned a
>>> DOI), then published in its final form somewhere else and assigned a
>>> new DOI by the different publisher. You could argue that preprints
>>> shouldn't be assigned DOIs, but then you have to a) define when
>>> something is a "preprint" and b) tell people that they're not allowed
>>> to cite "unpublished" work using a DOI.
>>>
>>> Alf
>>>
>>> On 9 May 2013 18:11, Bruce Rosenblum <bruce@xxxxxxxxx> wrote:
>>> > Alf,
>>> >
>>> > This isn't an answer to your question, but a comment about DOI. You
>>> > should
>>> > assign a DOI to a work, not a manifestation. If you assign a DOI to each
>>> > version of an article, many applications will fail to link because
>>> > you'll
>>> > have multiple DOIs that have the same metadata. It's better to assign
>>> > one
>>> > DOI and then have the landing page show each version of the article.
>>> >
>>> > Bruce
>>> >
>>> >
>>> > At 12:59 PM 5/9/2013, Alf Eaton wrote:
>>> >>
>>> >> Does anyone have any experience with marking up links to previous
>>> >> versions of an article in JATS, and also marking up the version number
>>> >> of the current article?
>>> >>
>>> >> The previous versions of the article will all have their own URLs and
>>> >> DOIs, so I was thinking that the "related-article" element would make
>>> >> sense. There doesn't seem to be an existing @related-article-type
>>> >> attribute meaning "previous version", but HTTP link relations[1]
>>> >> include "predecessor-version" and "successor-version", which could be
>>> >> re-usable.
>>> >>
>>> >> Thanks,
>>> >> Alf
>>> >>
>>> >> [1] http://www.iana.org/assignments/link-relations/link-relations.xml
>>> >
>>> >
>>> > -------------------------------------------------------------------
>>> > This email message and any attachments are confidential. If you are not
>>> > the
>>> > intended recipient, please immediately reply to the sender or call
>>> > 617-932-1932 and delete the message from your email system. Thank you.
>>> > -------------------------------------------------------------------
>>> > Bruce D. Rosenblum
>>> > Inera Inc.
>>> > 19 Flett Road
>>> > Belmont, MA 02478
>>> > 617-932-1932 (office)
>>> > bruce@xxxxxxxxx
>>
>>
>> -------------------------------------------------------------------
>> This email message and any attachments are confidential. If you are not the
>> intended recipient, please immediately reply to the sender or call
>> 617-932-1932 and delete the message from your email system. Thank you.
>> -------------------------------------------------------------------
>> Bruce D. Rosenblum
>> Inera Inc.
>> 19 Flett Road
>> Belmont, MA 02478
>> 617-932-1932 (office)
>> bruce@xxxxxxxxx

Current Thread