 |
 |
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 --------------------------------------------