230 likes | 393 Views
EMu on the Web Past, Present and Future. Alex Fell KE Software. Past. KE TexHTML. 1993-4 (ish). About the time the first browsers were developed. One of the first web interfaces to a database. Cutting edge for it's time. Became very complex over the course of it's lifetime.
E N D
EMu on the WebPast, Present and Future Alex FellKE Software
KE TexHTML • 1993-4 (ish). About the time the first browsers were developed. • One of the first web interfaces to a database. • Cutting edge for it's time. • Became very complex over the course of it's lifetime.
Texxmlserver and PHP • Developed initially in 2001. • Aimed to simplify web development by using existing technologies (XML over HTTP and PHP). • “Standard Interface” customisable by the customer. • “Custom Interface” to allow more complex pages to be developed by KE Staff and external developers.
“Standard” PHP Interface • Presents a configurable, catalogue-centric view. • Very quick to set up, so a collection can be on the web very soon after going live with EMu. • Limited amount of customisation available. • Common (shared) presentation layer makes extensive changes hard because all users of the standard interface may be affected.
“Custom” PHP Interface • Page design and operation not at all defined. • Pages can be made to any brief, so no limit on design or functionality. • Because no design / layout work is done for you, pages take longer to produce and complex pages often require a developer. • Many of our older customers now use plenty of the custom interface as part of their sites.
KE Mapper • Gives a spacial representation to the collection. • Plots items on a map. • Most easily applied to Natural History collection as locality information (lat / long etc.) comprises part of the collection information.
Object Locator • Like the mapper, but displayes the current location of objects on a map of the museum. • Requires location records to be supplemented with spacial information, but uses existing location database.
KE Portal • Draws data from several separate databases. • Interface with many different databases (Texpress or otherwise) • GBIF, OAI, DiGiR, Darwin Core schemas supported. • In use at OZCAM, and of course, Manchester Museums Unwrapped.
PHP 5 • Opportunity to re-write “Standard” and “Custom” interfaces (and rename them)? • Break apart from the one-size-fits-all Standard Interface model? • Is ease of use balanced by extensibility in a shared code base? • What should happen to existing PHP 4 interface? • Backwards compatibility?
JDBC • Working driver in development, in use with KE Vitalware • Better interface with database • Easier to use than PHP? • More transferable than PHP?
Narratives, descriptive keywords, opinions & comments(still narratives?)
Issues • What gets contributed? • Does it require museum approval? • If so, how should this be presented to the museum? • If not, what's the worst that could happen? • Should it be stored in EMu?