Hello, I've just joined this list to chip in to this discussion about Axiell's freely available IMu, so apologies if this starts a new thread as I'm copying and pasting.
We're currently using IMu in a fairly limited way at the Museum of the History of Science (Oxford) and we don't as yet have any public APIs. However, there's a greater impetus to make data available for resource discovery. For what it's worth, I can offer some comments based on previous experience of using IMu. I guess much depends on what data needs to be exposed and what the intended uses (queries) are. IMu is a fairly small library of code that is quite functional; if you are familiar with EMu then using IMu has various merits: it is naturally designed to reflect the EMu architecture and being consistent you can, for example, create queries in IMu and check the output against the desktop client. However, it has limitations, particularly (as far as I know) the inability to search attachment fields, which was actually supported in the previous 'Web5' generation of API. I also wonder about the ongoing development and support as the official download (https://emu.kesoftware.com/support/downloads/imu) has been stuck at version 1.0.03 for a long time. I gather that where organisations use EMu data in larger scale projects most tend to have set up a batch process to export data as XML and ingest it in some other database etc. for reasons of performance, convenience etc. However, if security is a major concern, then it may be possible to partially replicate the main database to contain just public data and make it read only. As MHS has a relatively small number of objects and we try to be open I would expect to develop an API on top of the IMu library (that can support e.g. RDF). Regards, Paul Paul Trafford Web Officer Museum of the History of Science http://www.mhs.ox.ac.uk/ paul.traff...@mhs.ox.ac.uk ----- Forwarded Message ----- Date: Fri, 13 Feb 2015 07:19:20 -0800 (PST) From: "David Newbury" <david.newb...@gmail.com> To: "Museum Computer Network Listserv" <mcn-l@mcn.edu> Subject: Re: [MCN-L] Anybody using IMu for public API Message-ID: <1423840760081.0bfa36dc@Nodemailer> Content-Type: text/plain; charset="utf-8" At the Carnegie Museum of Art, we've been looking into bypassing IMu and building and using the XML export feature, and building our API off those exports. We don't have a pressing need for realtime data in our API, and it means that the developers working on the API (i.e., me!) don't need to be as intimately involved in the intricacies of EMu?it?s just an XML parsing problem. It also means that there are no security issues, as least as far as writing goes the API doesn't have any access to the real database, so it is impossible to get to non-exported data or overwrite and live data. We're not sure that's the best technique we go back and forth on using IMu or continuing down this path. We'd also be interested in any feedback or insights people might have. ? David Newbury (773) 547-2272 david.newb...@gmail.com On Thu, Feb 12, 2015 at 6:50 PM, Adrian Kingston <adri...@tepapa.govt.nz> wrote: > Hi all > We're (Te Papa) finally looking to use IMu a bit more from our EMu. We're > thinking about a public facing API and a few more specialist uses. Does > anyone have any experience they can share on successfully/unsuccessfully > using IMu for external feeds/API etc? > Cheers > Adrian Kingston > Digital Collections Senior Analyst > Museum of New Zealand Te Papa Tongarewa > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Visit the Te Papa website http://www.tepapa.govt.nz > The email message together with the accompanying attachments may be > CONFIDENTIAL. If you have received this message in error, please notify > http://www.tepapa.govt.nz/onlineforms/enquiryform.aspx immediately and > delete the original message. The views expressed in this message are > those of the individual sender, except where the sender specifically > states them to be views of Te Papa. Te Papa employs strict virus > checking measures and accepts no liability for any loss caused either > directly or indirectly by a virus arising from the use of this message > or any attached file. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ______________________________________________________________________________ > This email has been filtered by SMX. > For more information visit http://smxemail.com > ______________________________________________________________________________ ------------------------------ _______________________________________________ mcn-l mailing list mcn-l@mcn.edu http://mcn.edu/mailman/listinfo/mcn-l End of mcn-l Digest, Vol 114, Issue 10 ************************************** _______________________________________________ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network (http://www.mcn.edu) To post to this list, send messages to: mcn-l@mcn.edu To unsubscribe or change mcn-l delivery options visit: http://mcn.edu/mailman/listinfo/mcn-l The MCN-L archives can be found at: http://www.mail-archive.com/mcn-l@mcn.edu/
