About iSpheresCore

Brief Summary

The concept of iSpheres emerged from the Medical Faculty and SSIU?s image repositories (OLIVER, ImageBank, ArchImage)

The aim of the ISpheres middleware is to make it easy for users to create and maintain existing repositories in distributed environments.

Fig 1. Courtesy Andrew Wilson ACL

Implementing ISpheres into existing repositories, upgrades their sustainability capabilities by enforcing fundamental sustainability guidelines. You continue to work as usual, but open up a world of new opportunities and functionality.

ISphereCore is designed to support common digital object collections (images, sounds, text and movies). Here the aim is to provide powerful repository technologies to small groups with little or no expertise in the area. These solutions will contain everything they need to set up decent, sustainable repositories.

As a middleware application, ISpheres not only ensures that fundamental sustainability guidelines are followed, but provides a common platform for communicating with each other. One ISphere can not only fetch data from its own database, but can search other ISpheres for data as well. In practice, you can have one ISphere searching one or more collections for data. This opens up opportunities of collaborative research.

AuthorityISphere is a repository of ISpheres and Collections, anyone who is running an ISphere may register with the Authority server, and thus will make it easier for others to find you and your data.

When a user is searching data in the ISphere Universe, there are two primary ways to go about it.

• If they know the location of the ISphere and Collection they wish to search, a very detailed query can be targeted at the desired collection. This provides users with powerful search features - right to the level of being able to perform freetext, spatial and temporal searches on specific fields.
• If a user is not really sure where to start - they can perform 'google' like searches for ISpheres, collections or even digital objects.

Features

• Configurable metadata
• Distributed Architecture
• Data source Connectors, to allow plugging in to existing repositories
• Object file types and transformations are plugins
• SOAP interface for building specialised front-end interfaces, linking into existing tools (WebCT, etc) or protocol translators

Technology

• Java
• SOAP
• XML
• XSL
• PHP
• HTML

Further information

For more details contact:

• Daniel Burn - Faculty of Medicine, University of Sydney
• Ian Johnson - The Archaeological Computing Laboratory, University of Sydney.

Java documentation my be found at here: http://www.ispheres.org/apidocs/index.html