GoogleCodeExporter
commented
9 years ago from Link Olson <Link.Olson@uaf.edu>
date Wed, Jul 9, 2008 at 1:45 PM
subject [Arctos] Re: project description size
Actually, we (Mammals) are using projects for both accessions and
loans, too, and I use them more for the latter in demonstrating use of
the collections. However, I sympathize with users who wish to keep
their project descriptions vague and have no problem with agreeing to
'sunset clauses' or temporary encumbrances. If people can see the
(unencumbered) project TITLE, that should suffice, but there may be
perfectly reasonable cases where that, too, can be encumbered until
either results are published or the sunset clause expires.
I agree that we should make it clear to the potential user that their
project description will either be immediately or eventually made
public on Arctos and let THEM word it accordingly. We request a LOT
of information from potential users, much of which does not need to be
made public. I'll save this for another topic string, but I, for one,
would like to make the tissue/destructive sampling request process
more streamlined such that requesters are prompted for all of the
info. we require. Currently, we have to engage in an unnecessarily
protracted e-mail exchange to sort out all the details.
Link
- Show quoted text -
On Jul 1, 2:48 pm, "Carla Cicero" <ccic...@berkeley.edu> wrote:
> Just like anything else, encumberances do not need to be used...but they can
> be if circumstances require it. So I don't really see that as being
> different than anything else. but that said...
>
> This exchange has me confused, so I agree that we need to be clearer on what
> we're trying to do with Projects. Projects are tied to transactions as a way
> of recording uses of specimens coming in (Accessions) and going out (Loans).
> That's how we've been using them. It seems like UAM has mostly been using
> them in the context of accessions.
>
> Just like abstracts, loan requests summarize the nature of the research
> being done with those specimens. We've been entering that info into
> Projects. I am reluctant to have two fields, one "public" and one "internal"
> for essentially the same thing. I think that will cause more problems than
> it will solve. And it's very subjective as to what one puts into a project
> description. One person may enter 1-2 sentences about the project, another
> may put in a detailed summary of the questions being asked, methods used,
> etc. How do you decide what should be "public" or not.
>
> I think the best solution is to have a system whereby the user enters their
> own project description electronically, with a statement on the form saying
> that this description will be publically available. I don't think it should
> be up to us to decide how much of a researcher's project description is ok
> for the public, versus what is "private."
>
> If we wanted, we could add a field called "curatorial notes" or something
> like that...tied to transactions I suppose? but that would not be for
> project descriptions but rather for other comments about the transaction.
>
> On Wed, Jun 25, 2008 at 8:46 AM, Gordon Jarrell <gordon.jarr...@gmail.com>
> wrote:
>
> > The screwy Internet connection we're pirating from our house in Albuquerque
> > messed with my last message wholesale. Also, lost the draft of what I'd
> > written. In an about-face...
>
> > I do not like the idea of encumbering project descriptions, at all. In
> > presenting Arctos to groups of Native Alaskan subsistence hunters, we have
> > made the case that Arctos gives them the opportunity (which they insist is
> > their right) to see how the specimens that they provide (through their
> > projects) are used. In the absence of this trust, we would not have
> > received their specimens without the requirement that their representitives
> > be given the right to prior approval of specimen usage. The capacity to
> > encumber a project violates this trust, and violates the basic openness of a
> > public trust. If there are aspects of a project that must be encumbered,
> > then a separate field/column is required. We need project descriptions to
> > be public because users deserve at least an explanation of what the project
> > title is supposed to mean.
>
> > NSF web-publishes abstracts of all funded proposals. Arctos should
> > demonstrate a similar accountability. NSF does not publish the full content
> > of proposals, even though these are now online. Similarly, Arctos needs to
> > protect the proprietary aspects of a project, though previously I would have
> > thought of these as handled at the level of Transactions.
>
> > G.
>
> > On Tue, Jun 24, 2008 at 3:17 PM, Dusty <dust...@gmail.com> wrote:
>
> >> I think we need more discussion about what should be recorded where. I've
> >> always viewed the Loan tables as internal information, and the Project
> >> tables as being (among other things) a public distillation of that
> >> potentially confidential information.
>
> >> Are Projects being used as requests for all loans? Is there value in
> >> recording requests that you do not fulfill? (I think there is, and I think
> >> that is clearly not a Project.)
>
> >> There was once a Loan_Request table in the model. Perhaps reviving it
> >> rather than mangling Projects is a better solution, especially if the
answer
> >> to any of the above is "yes." Doing so would provide an already-internal
> >> place to record sensitive/detailed information about potential loans.
>
> >> If nothing else works out, I think adding an internal information field to
> >> Projects is much less evil than restricting entire Project records.
>
> >> For whatever it's worth, I agree with Gordon's assessment of the
> >> implications of masking Projects. I think doing so - or maybe just having
> >> the potential to do so - violates a trust that UAM has worked hard to gain.
>
> >> --D
>
> >> On Tue, Jun 24, 2008 at 1:25 PM, Gordon Jarrell <gordon.jarr...@gmail.com>
- Show quoted text -
> >> wrote:
>
> >>> Wow! I'm happy they're being used so extensively.
>
> >>> The idea of encumbering project descriptions bothers me a lot. In
> >>> presenting Arctos to Alaska Native subsistence groups, I have described
> >>> Arctos as making specimen usage accountable to specimen providers. The
idea
> >>> that "their" specimens could be used in a project that was hidden to them
> >>> violates a trust that we have built using Arctos, and a trust that
obviates
> >>> their initial request that usage of contributed material receive their
prior
> >>> approval. I'm not interested in seeing logic written around special
cases.
> >>> At a fundamental level, this violates the openess of what we do.
>
> >>> A public abstract should be required of specimen users, and if another
> >>> field is required for privileged information, so be it.
>
> >>> At a more trivial level,
> >>> thhis:
> >>> http://g-arctos.appspot.com/arctosdoc/project.html#description
> >>> *says:
> >>> "Descriptions* are an abstract of one to about ten sentences. They
> >>> should demonstrate the importance of the work and justify the use of
museum
> >>> specimens. Vocabulary and grammar must be suitable for public display. New
> >>> projects requesting use of specimens should include such descriptions as
> >>> part of their requests. As in titles, font control and special characters
> >>> are implemented in hypertext markup language."
>
> >>> This is not adequate. (For one thing, projects can contribute specimens,
> >>> not necessarily just use them.) We need to clarify the intent of project
> >>> descriptions. NSF web-publishes abstracts of all funded proposals, but
> >>> access to the full-text of proposals is restricted to reviewers and only
as
> >>> privileged information. I've been thinking of project descriptions more
as
> >>> such abstracts.
>
> >>> G.
>
> >>> Given MVZ's broader usage of Projects, temporary encumbrances don't
> >>> bother me.
>
> >>> On Tue, Jun 24, 2008 at 10:54 AM, Carla Cicero <ccic...@berkeley.edu>
> >>> wrote:
>
> >>>> We are creating project descriptions for loan requests, which makes it
> >>>> easier for us to track usage. So, the description may include information
> >>>> about the questions being asked, methods, etc. It is useful for us to
track
> >>>> that so we can more easily link loans to publications (when specific
numbers
> >>>> aren't cited), compare similar requests from different researchers, etc.
So,
> >>>> we want to include the details, but the researcher who requests a loan
may
> >>>> not want those public and I can understand that. I think projects are
useful
> >>>> both to explain/justify what we do, and to help curators or collection
> >>>> managers with tracking transactions. So how do you decide what to
include or
> >>>> not? We could create a separate field that's available only to users with
> >>>> certain roles, but I don't like that. I think we should enter project
> >>>> descriptions in one place, but have a way of flagging them as public or
> >>>> private.
>
> >>>> On Tue, Jun 24, 2008 at 11:27 AM, Gordon Jarrell <
> >>>> gordon.jarr...@gmail.com> wrote:
>
> >>>>> Why would we not want project descriptions to be public? The point of
> >>>>> a project description is to explain/justify what we do and what we
support
> >>>>> to our supporters, which for nearly all of us includes the public. The
> >>>>> description does not have to include proprietary information, and there
does
> >>>>> not have to be a project associated with the transactions if it's
something
> >>>>> Osama shouldn't hear about.
>
> >>>>> On Tue, Jun 24, 2008 at 10:11 AM, Carla Cicero <ccic...@berkeley.edu>
> >>>>> wrote:
>
> >>>>>> Some researchers consider their research questions and details about
> >>>>>> that research (e.g., which gene is being sequenced) to be proprietary
until
> >>>>>> it is published. I am not speaking for myself, but rather for other MVZ
> >>>>>> researchers. There is concern that other researchers might use their
ideas.
> >>>>>> We could enter vague project descriptions, but those are not very
useful.
>
> >>>>>> On Tue, Jun 24, 2008 at 11:05 AM, Gordon Jarrell <
> >>>>>> gordon.jarr...@gmail.com> wrote:
>
> >>>>>>> Why would we not want project descriptions to be public? The point
> >>>>>>> of project descriptions is essentially to inform the public about how
a
> >>>>>>> publicly funded resource (a collection) is being used. The
descriptions do
> >>>>>>> not have to include any proprietary information.
>
> >>>>>>> On Tue, Jun 24, 2008 at 9:48 AM, Carla Cicero <ccic...@berkeley.edu>
> >>>>>>> wrote:
>
> >>>>>>>> I agree that 4000 should be plenty.
>
> >>>>>>>> On a related note, some of our researchers/curators have expressed
> >>>>>>>> concern recently over project descriptions being public. I talked
with Dusty
> >>>>>>>> briefly about this, and one possibility is to implement a flag that
would
> >>>>>>>> make the description public or private (default being public). There
are
> >>>>>>>> probably other ways of handling this as well. Basically, we need a
way to
> >>>>>>>> encumber project descriptions.
>
> >>>>>>>> I'm curious as to whether other Arctos users have the same concern.Original comment by carla...@gmail.com on 14 Jul 2008 at 11:55
Original issue reported on code.google.com by
carla...@gmail.comon 24 Jun 2008 at 5:47