|
A reply to the collections data integration/publication strand of this discussion. I agree with much of what Nick says below and others have said too, here's our approach to it.
When I was at the Museum of London, we realised after years of coaxing and coercing Mimsy to hold data to help organise our collections on websites, and of mashing that data with other contextual content held in front-end applications, that this was not a good way to proceed. We decided we wanted an architecture that would:
1) Let the collections management system do what it's best at and intended for, and only that. This varies between systems and organisations, but for us it meant not putting in "pseudo" records to help organise collections into themes that have nothing to do with hard-core collections data, not putting web-only captions into item records, not finding ingenious but inappropriate ways of representing relationships between authority records and so on.
2) put data into a form optimised for discovery, recombination and display rather than management and back-office processes. We could map the tangle of fields that are used differently in different parts of the collection so that they make sense from both a search and display point of view, pre-process data to make e.g. nice display names, and take a big load off the collections database.
3) let us merge data from multiple sources - possibly other collections, but also UGC, metadata enrichment services, wikipedia, vocabularies etc. Some of these might belong in the collections database, but those that don't can be safely combined with collections data outside of it
4) let us organise entities in the collections data (object records and authorities) into sets, organise those sets, and attach metadata, media etc to them
5) modify the collections records *within the context of those sets* so that audience-or context-specific names, descriptions etc can appear when appropriate
6) keep all of this enriched collections content (data plus context) separate from the presentation layer. Then we can reuse it in whatever front-end we wish
7) run in isolation from the source data
This gave us a middle layer that could be optimised to do what it needed to do - integrate, optimise, enhance - and let the back end data sources and front end interfaces do what they needed to do.
We worked with Knowledge Integration to develop this vision and they implemented a system that we used to drive our gallery terminals and (eventually, after I left) the website's collections search as well as Rhiannon's excellent Picture Bank. K-Int have turned the system into a product that the National Maritime Museum now also use to drive their website and some interesting gallery interactive. I know of another museum that has taken it too, with quite different plans in mind.
We at the IWM are currently implementing the system too, ready for our website relaunch this autumn (Drupal, incidentally. Don't get me started). We'll use it to drive our new website's collections content initially but will roll out to other interfaces in due course. So at present we have essentially just data from Adlib there but there's a small amount of e-commerce data from elsewhere too. In this phase we've not implemented the "augmentation" layer, to let us organise and contextualise records, which will come later. The longer term aim is to integrate more external data such as website analytics, tags, biographical records, authorities, and metadata augmentation and translations from Europeana. All of this will make for a more powerful index and some of which could ultimately be piped back into Adlib, if appropriate.
This is a different class of software to either collections management systems or content management systems - it has things in common with Cristiano's content-only CMS ideal and Nick's data integration and reuse perspective. Whilst it adds complexity in one way, it also makes things simpler and cleaner in others.
Cheers, Jeremy
Jeremy Ottevanger
Technical Web Manager
Imperial War Museum
Lambeth Road
London SE1 6HZ
-----Original Message-----
From: Museums Computer Group [mailto:[log in to unmask]]
Sent: 16 August 2011 14:28
To: [log in to unmask]; [log in to unmask]; Jeremy Ottevanger
Subject: Re: [MCG] What would an open source museum CMS look like?
Hi all,
Great thread, and sorry to come to it rather late in the day! Pretty much everything I would have said has been said already, particularly in Jonathan Whitson Cloud's comments, but I offer one or two further observations.
It has been interesting watching the conflation of Collections Management System and Content Management System in this thread. From our perspective, a key issue in the years ahead will be the question of systems integration, and how integrated systems can better support the overall process of delivering museum services in future.
Currently, most museums we talk to operate standalone systems for different functions. Hence in a medium-to-large museum, you might find:
- One or more departmental Collections Management Systems
- A web Content Management System
- A Digital Rights Management System
- A Digital Asset Management System
- User/access control systems
- Local Area Network containing files/documents
- School Group Bookings Systems
- Office/productivity systems (including Contacts systems)
- Customer Relationship Management Systems
Alongside all of these systems, you will also have the human infrastructure of tacit knowledge and expertise as well as the very significant but largely invisible output of individual/personal learning, research and response associated with the Collections.
Under the current model, each of these systems is effectively a silo, with the result that investment made in generating knowledge in one system is often effectively invisible to the others. This militates against both flow and serendipity, and it makes it difficult for the museum to leverage the strength of the totality of intellectual potential that is running through it.
I am, therefore, less bothered about whether a CMS (or any of these other systems) is open source or not, and much more interested in whether they are *open* in the sense that they can be made to interoperate in a proportionate and sustainable way with the other systems in the institution - and hence support rather than retard the process of capitalising on our knowledge assets.
It seems to me that the two critical developments here are (a) modularity and (b) Software as a Service. I believe that we need to be specifying modular systems, or systems which are capable of expressing content within a consistent framework (along the lines of the BBC Digital Public Space), so that we don't give ourselves the overhead of hard-wiring particular forms of semantic interoperability. This modularity is much more scalable (and therefore affordable) if we allow vendors to supply the software as an evolving service rather than a boxed product. I understand why people are resistant to SaaS for their Collections data, but this inertia is holding back the development of more scalable approaches to museum systems.
Underpinning all of this is the idea that museums have experienced a real paradigm shift in that the core functional model of a museum has expanded to incorporate publishing and broadcast as well as locative experience. An effective publishing workflow is one which decouples raw material (knowledge and assets) from delivery, permitting an infinitely extensible set of use cases. Museum knowledge and information management is still very siloed and lossy and it will only be when a piece of information published in one system can be effortlessly repurposed into a number of other systems (without prior knowledge of the internal structure and workings of the destination systems) that our knowledge of collections can fulfil its potential to support the broadest range of forms of engagement.
This model of flow can, of course, also be extended beyond the institution. The underlying promise of Linked Data, it seems to me, is that it will enhance the flow of contextual references both into and out of the museum systems. It might be that the most open Content Management System for a museum would involve using the Web as a CMS in much the same way as the BBC (http://derivadow.com/2009/01/13/the-web-as-a-cms/). It is interesting to speculate what lies at the end of that concept - in which the question of which repository your data sits in is much less important than how you configure the applications you use to interact with it.
Anyone can build a Collections Management System - just take SPECTRUM and build it (not to belittle the achievement of those that have!). Making the software and making it open source is not the problem. The problem is in creating solutions which will support the ever-evolving needs of museums and which will scale across the vast differences in technical competence across the museum community and then creating a viable organisation in the process. I think most of our SPECTRUM Partners would agree that they are less in the software business and more in the consultancy and professional development business.
From our point of view, the next big game in town will be in the middleware that maximises the flow of knowledge and value across and beyond the organisation and the extent to which the value of the sunk investment in separate systems can be brought out through integration and/or interoperability.
All best,
Nick
Nick Poole
Chief Executive
Collections Trust
[log in to unmask]
Tel: 0207 250 8340
OpenCulture 2012
The Greatest Collections Management Show on Earth!
London, 19th & 20th June 2012
http://www.collectionstrust.org.uk
http://www.collectionslink.org.uk
http://openculture.collectionstrustblogs.org.uk
Follow us on Twitter: @collectiontrust
Follow me on Twitter: @nickpoole1
Contact me on Skype: nickpoole3
Connect via LinkedIn: http://www.linkedin.com/profile/view?id=5289899&locale=en_US&trk=tab_pro
Company Registration No: 1300565
Registered Charity No: 27398
Registered address: Collections Trust, CAN Mezzanine, 49 – 51 East Road, Old Street, London N1 6AH
-----Original Message-----
From: Museums Computer Group [mailto:[log in to unmask]] On Behalf Of Mia
Sent: 16 August 2011 12:28
To: [log in to unmask]
Subject: Re: What would an open source museum CMS look like?
On 16 August 2011 10:49, Bonewell, Perry <[log in to unmask]> wrote:
> Which sounds exactly like the sort of thing that would interest me: a
> platform that solves all the core issues (whatever they may be) from the
> off but with the flexibility to be easily developed and extended.
Assuming that something like 80% of what museums need to do online -
give venue information and directions, list events, provide outreach
and educational resources, encourage financial support - is very
similar, and that how people think about publication and interactions
around their collections and interpretation is where the variation
comes in, I think that's a good model. Most visits to a museum
website are for the basic 'visit us' info, and if you can take care of
that easily, it frees up resources for tailoring the digital
experience for your institution.
Platforms like Drupal and WordPress that provide core functionality
and are extensible through plugins are pretty established in museums
these days. I haven't played much with Drupal but suspect it takes a
bit more effort to get it up and running than WordPress, so which
platform you choose might depend on your immediate needs and
resources.
While I'm here, I thought this recent blog post provides some good
case studies on museums re-thinking their 'main' web presence:
http://oonaghmurphy.com/2011/08/16/museums-dont-need-a-website-to-be-online/
Cheers, Mia
****************************************************************
website: http://museumscomputergroup.org.uk/
Twitter: http://www.twitter.com/ukmcg
Facebook: http://www.facebook.com/museumscomputergroup
[un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************
****************************************************************
website: http://museumscomputergroup.org.uk/
Twitter: http://www.twitter.com/ukmcg
Facebook: http://www.facebook.com/museumscomputergroup
[un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************
This message has been scanned by the IWM Webroot Service.
This email and any attachments are confidential. It may contain privileged information and is intended for the named recipient(s) only. It must not be distributed without consent. If you are not one of the named recipients, please notify the sender and do not disclose or retain this email or any part of it.
Unless expressly stated otherwise, opinions in this email are those of the individual sender and not those of the Imperial War Museum.
This email has been scanned by the Webroot security service. We believe but do not warrant that this email and any attachments are virus free: you must therefore take full responsibility for virus checking.
****************************************************************
website: http://museumscomputergroup.org.uk/
Twitter: http://www.twitter.com/ukmcg
Facebook: http://www.facebook.com/museumscomputergroup
[un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************
|
