If the repository moves upstream into the workflow, and actually does
something useful for the researcher, it will have to support team
working.
BTW I'm seeing echoes of another resemblance, a lot less
structured... with a wiki. Likewise does version control (in a way),
and supports team working.
I'm not trying to say any of these things are the same. I'm asking if
there are features from these *slightly similar* things that we
might find useful in *our* repositories!
--
Chris Rusbridge
Director, Digital Curation Centre
Email: [log in to unmask] Phone 0131 6513823
University of Edinburgh
Appleton Tower, Crichton St, Edinburgh EH8 9LE
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
On 12 Mar 2009, at 21:11, Paul Walk wrote:
> Les has drawn the distinction between the essentially 'live' nature
> of content in source-code repositories and the generally rather
> static aspect of content in our average IR. Of course there are
> plenty of examples of source-code repositories which are no longer
> being used to support 'live' code (swathes of sourceforge.net
> resemble a graveyard of abandoned software projects), but this
> distinction is nonetheless true and important.
>
> I would like to point up another distinction: the source code
> repository is, pretty much by definition, designed to support a
> *team* (or at least a pair) working on the same project. Version
> control is fundamental, but equally important are a set of tools
> and practices supported by the repository to aid collaborative
> development. A typical interaction with the average IR is, I
> venture, a more solitary affair.
>
> Having said this, it has occurred to me that there may well be an
> overlap, in terms of architecture at least, between LOCKKS and a
> relatively new source-code version control system called 'Git'.
>
> Paul
>
>
>
> On 12 Mar 2009, at 18:50, Peter Burnhill wrote:
>
>> Without wanting to disappear up an ontology of ....
>>
>> On 12 Mar 2009, at 16:43, Leslie Carr wrote:
>>
>>> On 12 Mar 2009, at 16:36, Peter Burnhill wrote:
>>>
>>>> I think repositories are a place to store things.
>>> Store? Get? Keep? They're all services :-)
>>
>> well, they are verbs/actions, and as noted below, I am wary of
>> using repository as a word for every set of managed data - as a
>> variant of database, say.
>>
>> I need a bit of assistance to separate Store & Keep, but would
>> expect that Put (deposit/ingest) & Get have to be among the
>> minimum set of verbs. In a source repository, which has that set,
>> there is greater need to attend to amend/edit and provenance/trail
>> than is usual among the repositories of objects usually included
>> in discussion. Being a 'data person', I am aware of some of the
>> natural history of data generation (manufacture/collection) and
>> the management of databases and datasets but not yet convinced
>> that there is as much carry-over as supposed.
>>
>>>
>>>> I've never signed up to the idea that they are a set of
>>>> services, except that a repository might be thought to be
>>>> capable of supporting three essential services: ingest
>>>> (deposit), keep-safe and access (use). Of course, for a digital/
>>>> network repository each of those may have multiple
>>>> interpretation: typically m2m as well as hci for the ingest and
>>>> access, say. At least that is how we conceived the minimally
>>>> sufficient functionality for Jorum. Keep-safe also needs some
>>>> interpretation.
>>>
>>> Perhaps the key part of a source repository is that it is made to
>>> look after (store, get, keep) a large number of highly
>>> synchronised, formally interpretable modules. The services (oops)
>>> that it offers are related to the business of using (and reusing)
>>> software code. Of course, code is manufactured and used by users,
>>> so the whole social network thingy might look very familiar.
>>>
>>> As for code preservation (language migration, version
>>> retrofitting etc) well, that is an issue, but no-one is
>>> suggesting that a specialised group of librarians will do it
>>> instead of the code producers themselves.
>>
>> data librarians and data curators do deploy information management
>> skills, rather than leave it to the data producers
>> (nstrumentalists?) or even the researchers, but I digress
>>
>> Peter
>>
>>
>>
>>
>>> --
>>> Les
>>
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>
> --------------------------------------------
> Paul Walk
> Technical Manager
> UKOLN (University of Bath)
> http://www.ukoln.ac.uk/
> [log in to unmask]
> +44(0)1225383933
> --------------------------------------------
>
|