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
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'.
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
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
UKOLN (University of Bath)
[log in to unmask]