Good to see a successful application of LOEKAS (Lots of Eyeballs Keep
Acronyms Safe).....
Paul
On 12 Mar 2009, at 21:38, P Burnhill wrote:
> I take it you mean LOCKSS? In fact I looked for LOCKKS, and noticed
> quite a few uses of LOCKKS when LOCKSS as intended.
>
> But back to your point. The so-called source repositories seem to be
> acting more as a dynamic database than a 'cold repository', a cold
> store of things that are chilled so that what is available to take
> out is *very close* to what has been put in. And the general case
> for mutable objects is that they are taken out, cooked in some
> interesting way, with a few added ingredients and then chilled down
> and put in the cold store with enough metadata to see how that one
> differs from the other (original recipe) on the shelf below.
>
> This analogy to a cold store of objects for a repository is in stark
> contrast to the characterics of a midden, onto which objects are
> discarded with the expectation that decay will set in after a short
> to medium period of time - and if you leave it long enough, its just
> bits.
>
> Which brings us back to Paul's pointer to LOCKSS, which is geared to
> detect change in copies/surrogates/versions of an object. This
> prompts thoughts about provenance, and work down by Peter Buneman's
> group on algorithmic approach to changes in dataases over time.
>
>
>
> On Thu, 12 Mar 2009, 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
>> --------------------------------------------
>>
>>
>
> ********** ********* ******** ******* ****** ***** **** *** ** *
>
> Peter Burnhill
> Director, EDINA national data centre & Head, Data Library
>
> Causewayside House
> University of Edinburgh
> 160 Causewayside
> Edinburgh EH
> Scotland, UK
>
> tel: +44 (0) 131 650 3301 fax: 3308 mobile: +44 (0) 774 0763 119
> Email: [log in to unmask] URL http://edina.ac.uk
>
>
> --
> 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
--------------------------------------------
|