 |
 |
Rebecca, Jason Sarah and all, Just to add some points from the NMR Data Services Unit view of the world:- What is being discussed here is one of the two available strategies for providing the solution to the generic question " I don't just want the information in my SMR, I want to find out what the MoD, National Trust, NMR etc etc knows about this place as well". The other solution is a portal accessing multiple online data sets (see HEIRPORT at the ADS web site for one example of this). But to get back to data transfer (ie the actual copying of records from one system to another), Sarah notes: >Importing this data into your HBSMR would be more complicated, as the flat file structure needs to be split back into the many relational tables. This is a very >complicated operation which would certainly require further work on our part and could only be done on a case-by-case basis unless a standard format for export and >import could be decided upon. I agree, having had some experience of specifying migration of data into the NMRs corporate database. Sarah rightly points out that this will be a major problem "unless a standard format for export and inoirt could be decided upon". I see this last point as central to the work of FISH. What is needed is a centrally maintained interchange format. Separate systems would then only have to maintain two migration routines:- 1) a mapping from their system to the interchange format 2) a mapping from the interchange format to their system This would be no mean feat, but it would be easier than trying to maintain migration routines between every system: 1) MySMR to Your SMR (multiplied by however many you want to exchange data with) 2) YourSMR to MySMR (ditto) 3) My SMR to the NMR 4) NMR to MySMR etc, etc... Needless to say this isn't new. Back in the late 1980s there was an agreed Standard Data Format for information exchange between the NAR (as was) and the ACAO (remember them?). This was a simple flat file approach - many of you I'm sure remember early 1990s tagged data projects run by the NAR. Enough reminiscing though. The flat file approach had the drawback that it was an oversimplified view of the complex relationships within SMR data. The current flavour of the month technology, XML, has been touted as the solution to interchange issues such as this (see <http://www.xml.org/xml/news_market.shtml> http://www.xml.org/xml/news_market.shtml among many thousands of others). The museums world is looking at a solution based on the SPECTRUM data standard (the museum equivalent to MIDAS) using XML to encode data exports in such a way that they retain enough information to reconstruct the relationships between data in an unambiguous and therefore machine processable way. This is moving towards the semi automated data exchange that I guess is the overall objective of this work, but progress is slow. Its worth noting in passing that this project anticipated additional uses for a central interchange format, beyond system to system data exchange, specifically it could provide: i) a suitable platform for moving data from an old system to your chosen new SMR system, and by extension a specification to assist in the selection of new software. ii) a format for long term archiving of project data that, for whatever reason, is no longer required on the 'live' information system. iii) a format for the collection of data by remote users (e.g. field staff inputting into a stand alone system before 'uploading' to the main system). As I said. I'm very keen for FISH to get to grips with an interchange format, and it makes sense to see MIDAS as the starting point for that. I'd welcome comments here or on the fish list ( [log in to unmask] <mailto:[log in to unmask]> ). Another initiative that folk may like to look at in this context in the Conceptual Reference Model, which is being developed by an international collaboration of museums, archives, libraries. See the CHIOS project site for further information - <http://cidoc.ics.forth.gr/chios.html> http://cidoc.ics.forth.gr/chios.html Edmund Lee English Heritage Data Services Unit