Hi all,
Responding to Richard here, I would tend to agree about the need to
think holistically about how museums will handle information flow in
future. I know that several larger UK museums are starting to think of
their 'information landscape' and how they get value to flow across
collections, documentation, digitisation, education, web and paper
publishing, retail and licensing, conservation and other functions in as
seamless and integrated a way as possible.
There do seem to be three approaches to this emerging from the current
generation of development projects:
1. Buy/create middleware which interrogates the different existing or
legacy systems, extracts data from them and repurposes/republishes it in
structured ways. The Knowledge Integration Collections Information
Middleware (CIM) product is a great example which is enabling Museum of
London, IWM and others to think creatively about opening out their
Collections data.
2. Implement core systems that are modular and extensible to handle
different inputs and outputs - hence a number of the Collections
Management Systems are really now modular
collections/knowledge/information/rights/user access/digital asset
management systems which can be configured to the particular needs of
the institution.
3. Maintain separate systems, but make use of their in-built
interoperability (usually in the form of a structured API) to coax them
into talking to each other.
(I'm not going to mention option 4 - don't do anything and sit tight
until the next lottery project...)
I think a lot comes down to budget. Option 3 is probably the least
technically elegant but most affordable solution. Option 2 depends on
there being a sufficient budget to procure an organisation-wide
deployment of a modular system (with the associated support and change
management overhead). It does, however, represent quite an efficient
development path if you are already using one of the systems that is
built this way. Option 1 is a fairly low-cost way of achieving a
significant improvement, but still recognising that your newly-open data
is sitting on top of a nest of legacy systems, ontologies etc.
To put it simply, over the next 10 years, museums are going to have to
accept a lot more new data into their systems, and are going to be asked
to make it available, robustly and reliably through a lot more output
channels. It seems likely that most people will follow a path from
partial integration to middleware to full systems integration and/or
refactoring. I would really love to hear from people who have either
found an alternative route, or are embarked on one of the approaches
I've described above.
All best,
Nick
-----Original Message-----
From: Museums Computer Group [mailto:[log in to unmask]] On Behalf Of
Richard Light
Sent: 30 August 2012 11:51
To: [log in to unmask]
Subject: Re: Low cost collections management solutions
On 30/08/2012 09:54, James Grimster wrote:
> Hi Martin
>
> >From my experience, I'll second Nick's point about a Content
Management System vs Collections Management System.
> I've had to pick apart such hybrid systems, it is not pretty.
>
> The most successful projects have been using Collections Management
Systems with an open API, onto which a WordPress / Drupal / Joomla et al
plugin / module can be created. If an output response can include
simple generic RSS or Atom (e.g. OpenSearch style), it's also easily
embeddable, testable, reusable and transformable to other formats.
> eHive has an API like this.
I agree that plugins would provide a neat way of piping cultural
heritage data from a collections management system into a web
development framework. The problem is that if you have X of the former
and Y of the latter, you potentially need to write XY plugins. (I had
never heard of the SEEEMS framework which Paul mentioned, so there's
another X to write straight away. :-) )
While the web frameworks out there will probably always have radically
different ideas of what a "plugin" consists of (as I have found
recently, looking at Drupal and Wordpress), there might be some mileage
in trying to harmonise the source data. For example, we could deliver it
using Linked Data techniques rather than through custom APIs. Or we
could develop an abstract interface spec that has community support.
We probably need to give more thought to engineering the pipework
through which our information flows. It probably won't be too long
before a typical cultural heritage institution is storing its core
information in three or more places (collections management system,
image management system, blog/UGC/social media repository), and needing
to meld and deliver that information to a variety of platforms and
audiences. Writing each interface by hand simply won't scale.
Richard
> all best
>
> --
> James
>
>
>
> On 29 Aug 2012, at 21:46, Nick Poole wrote:
>
>> Interesting question. It's certainly a technical possibility to
>> construct something like a Collections Management System using native
>> Wordpress functionality, but I'd really question whether this is a
>> good option for your museum
> ****************************************************************
> 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/
> ****************************************************************
>
--
*Richard Light*
****************************************************************
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/
****************************************************************
|
