thanks Mia

is it possible to get a critical mass around a standards based interchange? a different API for each CollMS is fine all the
time your audience is connecting to a single source.  What happens when you've got multiple CollMSs, or 
multiple data sources like archives and archaeology in the mix?  
With a federated approach combining relevancy scoring across search is challenging - ref Ade's presentation on JISC WW1 at MCG

So surely future-proofing middleware must sit in the, er, middle of all this?
Talking to Paul from Vernon/e-Hive/DigitalNZ: there's lots of SOLR based indexers with various, but similar, RSS style search responses as APIs on top (as per Europeana).
If the 'common' interchange in the UK were, for example, Collections Trust's  SPECTRUM XML interchange ....

--
James Grimster
www.orangeleaf.com


On 19 Dec 2012, at 23:43, Mia wrote:

> What a great thread!  I'd agree with what Nick Poole and James Grimster
> said above, and...
> 
> On 30 August 2012 11:51, Richard Light <[log in to unmask]> wrote:
> 
>> 
>> 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.
>> 
>> 
> I think I've spent too long away from writing code because making that
> actually sounds like it'd be fun (as well as useful).  The trick would be
> making it enough like core business - perhaps as part of a digital
> preservation or collecting strategy - to justify the resources.  Each
> institution has different needs, but there's already a number of WordPress
> plugins (for example) that deal with collections APIs or repositories, so
> you might get a critical mass of tools around Nick's first 'middleware'
> option.  The middleware option also seems slightly more future-proof and
> realistic than a grand unified system that does everything, but then I'm
> probably biased by the Unix philosophy of writing programs that do one
> thing and do it well, or the more recent 'do the simplest thing possible'.
> 
> Peigi - this thread started quite a while ago but if you missed the start
> the archives are available via the JISCMail site - Nick's post here sums up
> http://bit.ly/SVbjcm why you'd want to use a specialist Collections
> Management System (as you are), tools like WordPress are just a way of
> creating a user-friendly public-facing interface to them (to build on what
> Mike said).
> 
> Tehmina - Neatline is very cool but still very beta (though there's a new
> version coming out soon). As it's based on Omeka, documentation/library
> science experience really helps people get their heads around the
> underlying record model.  I've got an instance set up that I'd be happy to
> send logins for if you (or anyone else) wants to try it out beyond the
> sandboxes Omeka and Neatline provide.  I've also written something on my
> experiences teaching Neatline at
> http://openobjects.blogspot.co.uk/2012/11/reflections-on-teaching-neatline.html
> 
> 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/
****************************************************************