LIBLICENSE-L Archives

LibLicense-L Discussion Forum

LIBLICENSE-L@LISTSERV.CRL.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
LIBLICENSE <[log in to unmask]>
Reply To:
LibLicense-L Discussion Forum <[log in to unmask]>
Date:
Sun, 2 Apr 2017 14:03:21 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (111 lines)
From: "Plutchak, T Scott" <[log in to unmask]>
Date: Fri, 31 Mar 2017 15:17:13 +0000

I’ll make a quick comment here since I was on the working group that
developed the NISO recommended practice on Journal Article Versions.
The group recognized that as the publishing landscape evolved, there
would likely be a greater proliferation of versions than we could
clearly foresee, so we settled on a fairly high level set of terms.  I
think what Guédon is suggesting is much more granular – there could be
a multiplicity of “enhanced versions” and we need a system for
tracking those and clearly delineating their relationships.  The NISO
recommended practice is a good start, but it doesn’t provide a system
for doing that.

Scott


T Scott Plutchak | Director of Digital Data Curation Strategies
UAB | The University of Alabama at Birmingham
AB 420M
O: 205-996-4716 | M: 205-283-5538
http://orcid.org/0000-0003-4712-5233

uab.edu



On 3/29/17, 1:33 PM, "LibLicense-L Discussion Forum on behalf of
LIBLICENSE" <[log in to unmask] on behalf of
[log in to unmask]> wrote:

    From: Sandy Thatcher <[log in to unmask]>
    Date: Wed, 29 Mar 2017 10:30:00 -0500

    Has this not already been accomplished by the NISO  standards?

    http://www.niso.org/publications/rp/RP-8-2008.pdf

    See, e.g., its definitions of "corrected version of record" and
    "enhanced version of record."

    Sandy Thatcher



    > From: "Jean-Claude Guédon" <[log in to unmask]>
    > Date: Tue, 28 Mar 2017 10:30:06 -0400
    >
    > Ann Okerson's question is important and actually reaches well beyond
    > its ostensible target. The development of digital publishing leads to
    > a deep transformation in the nature of documents.
    >
    > Software writing was the first area where this issue arose.
    > Interestingly, and probably because the field of software writing was
    > unencumbered by previous, legacy habits, programmers developed
    > techniques that could track versions in a flexible and agile manner.
    > We are now all used to grappling with version 7.3 (or whatever) of
    > software X, and think nothing of it. "Requests for comments" (RFC), as
    > developed and used by the IETF in the context of the technical
    > developments of the Internet, followed a similar philosophy, while
    > applying it to straight texts, not software.
    >
    > Print forced us, a long time ago, to fix and harden what was being
    > published. It also foregrounded a vision of documents that depended on
    > techniques now embedded in critical editions: each critical edition
    > stands for eternity until a new critical edition challenges it, and
    > the result is a staccato mode of evolution that worked well with
    > print, but appears increasingly out of step with the potentials of
    > digital documents (especially with the inclusion of data sets and
    > software). Scientific and scholarly articles as they evolved through
    > print (and survive as PDF files, which is about as close to print as a
    > digital file can be - true digital incunabula, to use G. Crane's
    > clever image) also force the staccato mode of conversation and debate
    > that still dominates in scientific and scholarly circles. This leads
    > to a very inefficient way to feed the "Great Conversation" of science.
    >
    > With digital documents, what we need is an orderly system of versions
    > similar to what is used in software. In so doing, we no longer have to
    > grapple with any version "of record"; instead, we have to deal with a
    > time-driven succession of documents that can be easily identified if
    > the version system is well designed. Normally, the penultimate version
    > should be the most reliable, and the latest should be the cutting edge
    > solution that is on the chopping block for the next round of
    > Popperian-style refutations. Sometimes, the latest version adds little
    > to the previous one, but corrects minor problems; sometimes, it is a
    > real advance; sometimes it is a huge step forward. The numbering
    > system can reflect all of this, while keeping the history of a certain
    > thread of thought. Contributions to any document, however small or
    > large, so long as it is accepted, can be attributed to various
    > individuals. Free software shows how such an approach can be extended
    > to a broadly distributed system of contributors (which science and
    > scholarship, in general terms, are).
    >
    > If academic libraries, with their repositories, begin collaboratively
    > (and in a distributed  manner) to develop a peer-review system -
    > somewhat like the F1000 approach to reviewing - then, the issue of
    > filtering unwanted materials and noise also begins to find a solution.
    >
    > Metadata can incorporate versions. Therefore, retrievability ,
    > discoverability, as well as visibility issues can be addressed as
    > well. In fact, unpaywall, which is a wonderful tool by the way, could
    > be tweaked to take charge of the version issue, if a good version
    > system can be developed. OpenAIRE could be a good place to develop
    > such a system.
    >
    > Put all of this within the context of platforms, and not of journals,
    > and the digital communication system of science begins to take a
    > meaningful shape.
    >
    > Jean-Claude Guidon

ATOM RSS1 RSS2