Jeremy I acknowledge your concerns but some parts of NERC do want to have this reference available and as such we should find a compromise along the lines of which Bryan and Roy have suggested.
Regards James On 1 October 2010 16:21, Giles, Jeremy R A <[email protected]> wrote: > James, > > > > The other problem with project numbers is lack of persistence. The current > RMS project number is the primary key to a wealth of information that is > only persistent for the life of RMS. But RMS will go the same way as the > other 4 or 5 project management system I have used in my career. I already > hear a case is being made for migrating from RMS to the SSC Project Module. > > > > In such an environment does the project number and anything more than a > random number. > > > > Jeremy > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *James Doughty > *Sent:* 28 September 2010 08:39 > > *To:* NERC DataGrid Technical List > *Subject:* Re: [ndg-technical] SIS Information Architecture - Business > Processes and People > > > > Jeremy > > > > Project reference number should be an option, I don't think it is > currently. Clearly it can't be mandatory. > > > > Regards > > > > James > > On 28 September 2010 08:04, Giles, Jeremy R A <[email protected]> wrote: > > James, > > > > Your description is right. It is the reliance on a “project reference > number” that is puzzling me. > > > > > > > > > > Jeremy > > > > > > Jeremy R A Giles > > Head of the National Geoscience Data > Centre<http://www.bgs.ac.uk/services/ngdc/home.html> > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *James Doughty > *Sent:* 27 September 2010 19:31 > > > *To:* NERC DataGrid Technical List > > *Subject:* Re: [ndg-technical] SIS Information Architecture - Business > Processes and People > > > > Jeremy > > > > If I've understood you correctly, the situation you describe would probably > be handled as follows. > > > > The 20 - 30 databases which you refer to would probably have one or more > discovery metadata records already in existence given their longevity so no > need to create another one? There may be one or more data services (view, > download etc) already in existence which the newly collected (assimilated) > data feed into? In this situation I don't actually see anything happening at > the Single Face of NERC level at all. > > > > The SOBI example also fits as above - I've checked that the discovery > record already exists in the Data Discovery Service and it does. > > > > Does this make sense? > > > > Regards > > > > James > > On 27 September 2010 16:01, Giles, Jeremy R A <[email protected]> wrote: > > James and Carl, > > > > My main comment is about point one which make assumption about the way > BGS/NGDC works. > > > > > > 1. Projects producing data should have a project reference number that is > recorded in their Discovery metadata. The NERC Discovery Profile based on > GEMINI2 should be updated to include this reference number. > > > > The model will work well for the ESAA (Earth Science Academic Archive) > element of the NGDC. A PhD student produces a Thesis and a data package > which is a stand alone entity. > > However, most (98%) of BGS/NGDC revolves around collections (both digital > and analogue). Consider a field geologist collecting digital data using > SIGMA Mobile. This data comes back from the field at the project end and is > loaded into the 20-30 separate databases. The project data contributes to a > series of larger collections. For example a geologist using SIGMA Mobile may > describe a landslip. The observations made are added to the existing > landslip database. > > The situation is more complex when we are dealing with commercial data. The > NGDC may tomorrow acquire a 1970s Site Investigation Report. It contains the > descriptions of five boreholes and the tests carried out in-borehole and on > the samples. Initially we will simply add the borehole locations to the > Single Onshore Borehole Index (SOBI) and the report details go into a Site > Investigation Report Database. Over the next decades further data will be > abstracted from the report to populate other existing digital collection for > project specific purposes. > > So what am I saying? > > A project may produce data that is added to many existing digital and > analogue collections. We don’t consistently record projects, our systems are > mainly interested in the individual who did the data abstraction and > populated the database. > > There is a complex many-to-many relationship between projects and the > collections (both digital and analogue). > > Projects are regarded as transient and not recorded systematically. > > > > Jeremy > > > -- > This message (and any attachments) is for the recipient only. NERC > is subject to the Freedom of Information Act 2000 and the contents > of this email and any reply you make may be disclosed by NERC unless > it is exempt from release under the Act. Any material supplied to > NERC may be stored in an electronic records management system. > > > _______________________________________________ > NDG-technical mailing list > [email protected] > http://lists.ncas.ac.uk/mailman/listinfo/ndg-technical > > > > > -- > > James Doughty > Director > Diass Limited > 07985 443973 > > [email protected] > > > > > _______________________________________________ > NDG-technical mailing list > [email protected] > http://lists.ncas.ac.uk/mailman/listinfo/ndg-technical > > > > > -- > > James Doughty > Director > Diass Limited > 07985 443973 > > [email protected] > > > > _______________________________________________ > NDG-technical mailing list > [email protected] > http://lists.ncas.ac.uk/mailman/listinfo/ndg-technical > -- James Doughty Director Diass Limited 07985 443973 [email protected]
_______________________________________________ NDG-technical mailing list [email protected] http://lists.ncas.ac.uk/mailman/listinfo/ndg-technical
