[open-science] Open repositories

Thu Jul 8 14:06:09 UTC 2010

I'm inclined to suggest that a topic map be put in place that
federates the heterogeneous resources mentioned here. Not only does it
capture the metadata about each resource (which includes such things
as download locations, licenses, etc), but it also allows people to
wire relations among those resources, enhancing the findability. Done
properly, a topic map can include something called issue maps which
are structured conversations held online about issues related to those
resources (as compared to email lists).

As a thought, topic maps are *maps*, not *territory*. Scalability
issues should not be the same or even similar to those associated with
one central repository. Of course, there are likely other issues, but
I suspect they are perhaps more tame.

Jack

On Thu, Jul 8, 2010 at 6:42 AM, Jessy Cowan-Sharp
<jessy.cowansharp at gmail.com> wrote:
> thanks peter.
> as a start, i wonder if something could be put together that was essentially
> a mashup of github (code), infochimps (data), and a file server for papers.
> all wrapped with a choice of OA/FOSS etc. licenses to choose from.
> it probably wouldn't scale indefinitely as a solution, but having a place
> for people to go would be a good start in terms of increasing awareness of
> this as an option, and demand for those kinds of services.
> thoughts?
> jessy
>
> On Tue, Jul 6, 2010 at 6:57 PM, Peter Murray-Rust <pm286 at cam.ac.uk> wrote:
>>
>>
>> On Tue, Jul 6, 2010 at 11:15 PM, Jessy Cowan-Sharp
>> <jessy.cowansharp at gmail.com> wrote:
>>>
>>> didn't want to hijack the other thread so i changed the subject line, but
>>> i'm curious (and perhaps this is a naive question):
>>
>> You didn't actually change the subject so I have done so
>>
>>>
>>> what open access repositories are there which people recommend, besides,
>>> say, arxiv.org? arxiv.org itself doesn't seem to have a strong (or at least
>>> not explicit) stance on licenses and such. and are there any OA archives
>>> where people can submit their code/data along with their paper (in such a
>>> way that it is formally associated with that paper?)
>>
>> It's probably useful to differentiate between code/data/documents. The
>> current usage is:
>>
>> open access - papers
>> open source - code
>> open data     - data
>>
>> OpenSource is usually stored in specialist software repositories, which
>> should have  a powerful versioning system (SVN or better Mercurial or Git).
>> Typical repos are Sourceforge and bitbucket. These repos *could* be used for
>> otehr material (such as data or documentation but this is probably not a
>> good idea technically, as there is no good text search facility, etc)
>>
>> OpenAccess material is usually stored in paper-oriented repos (DSPace,
>> Eprints, Fedora) and are commonly found in Universities and similar insts
>> and run by LIS staff. They are totally unsuited to software and data (go on,
>> someone, ask me why!)
>>
>> OpenData is relatively new. The problems of storing it are considerable
>> and largely unsolved. Problems include versioning, dynamic updating,
>> metadata, formats, lack of specialist knowledge (there are (tens of)
>> thousands of common formats (e.g. several hundred alone in chemistry). This
>> is my speciality and I don't know the answer. I suspect it will be
>> domain-specific (e.g. biosequences, etc, are well supported at present,
>> chemistry has possiblle solutions but there are rabid anticommons interests
>> in chemistry, particle physics is huge, climate is hyperpolitical, etc.) OKF
>> is as good a place to start as any (though we can't store huge datasets and
>> are more likely to address metadata).
>>
>>>
>>
>>
>> --
>> Peter Murray-Rust
>> Reader in Molecular Informatics
>> Unilever Centre, Dep. Of Chemistry
>> University of Cambridge
>> CB2 1EW, UK
>> +44-1223-763069
>
>
>
> --
> Jessy Cowan-Sharp
> http://jessykate.com
>
>
> _______________________________________________
> open-science mailing list
> open-science at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/open-science
>
>