Re: [jats-list] Versions of an article

[Alf Eaton <eaton.alf@xxxxxxxxx>]

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