lib-ir Archive
Date: Fri Apr 22 09:55:50 2005
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: lib-ir: supporting pages for SB
In the case of the Undergrad Award winners, they signed a
release saying that their papers would be submitted to
Scholars' Bank if they won. Taking it down or modifying
it was not part of the agreement. We could certainly modify
the description of it to note that it is being revised for
publication and provide a citation and/or link to a revised
version. But I think the paper stays - if they didn't want to
run the risk of having their work made public, they should
not have entered the competition. The rules and the
signed agreement were clear.
We had the discussion with Econ when we started putting
their working papers in. There are some titles in that
collection that appear in more than one version, but we
haven't taken anything down. It's an archive. I think it
was JQ who noted that there is value in seeing the
progression, the development of an idea. Also,
once an item is up, it could already have been found
and cited. We have said that we will take something
down (and leave the tombstone) if an author demands
it. But we will try to talk them out of it.
I think we need to have a formal policy statement
about this.
Carol
At 08:00 PM 4/20/2005, Elizabeth Breakstone wrote:
>Yes, this recalls a conversation i had with one of the undergraduate award
>winners. she didn't want to place a copy of her paper in the SB because,
>despite the fact that it won an honorable mention, she doesn't really like
>it. she plans to edit it and submit it to journal. so, can we have her
>submit the old copy and then replace it with the new version? or do we
>have the old copy with a note in the record that links to the new version
>or at least gives a citation for it? etc. how does this work? with any
>working paper?
>eliz
>
>At 10:37 AM 4/19/2005, you wrote:
>
>
>>- As pages are updated, I would either need to replace
>>files, keep older and newer versions of the same file,
>>or not update files at all
>>
>>
>>I think this is the key conceptual question, and that it relates to a basic
>>question about how permanent/archival we want Scholars' Bank to be. If we
>>see it as evolving into a storehouse for archival copies, then we probably
>>don't want to put frequently changed items into it (since dspace currently
>>doesn't have a built in version control system); in this model we would only
>>put items in if we wanted them to be part of "the historical record". On
>>the other hand, if we want to see Scholars' Bank evolving into an access
>>tool for copies that are not tightly controlled, then this is a good idea
>>for the "advantages" reasons Carol mentions.
>>
>>My own feeling is that we'd be better off leaning to the archival side and
>>keeping the use copies of help files etc. on the server but not within
>>scholars' bank. I wouldn't mind sticking a set of archival copies within
>>Scholars' Bank if we believe that the current snapshot of the documentation
>>qualifies as something that deserves to be archived. But I don't think we
>>should be in the habit of replacing files.
>>
>>This points in my mind to 2 weaknesses of the current technology:
>> 1/ Dspace doesn't have a built in version control system. There are good
>>systems out there such as CVS and RCS (and evolving new models like wikis),
>>so it's puzzling that nobody has taken the conceptual approach of seeing an
>>item as something that can accrete new information (both content and
>>metadata) over time with version and timestamping.
>> 2/ Dspace isn't optimal for display of use copies. In Carol's model she
>>creates PDF files and stores them, but what if the intellectual content of
>>the pages she wanted to store didn't encode well in PDF? For example, what
>>if the point of the help file was to provide the search form or some other
>>HTML-specific feature?