by Nicola Aloia, Cesare Concordia, Anne van Gerwen, Carlo Meghini and N. Zeni
In its 2011-2015 Strategic Plan, Europeana announced User Engagement, ie new ways for end users to participate in cultural heritage, to be one of the primary tracks by which the organization will deliver value. Europeana intends to enhance the user experience and offer services that allow users to interact and participate.
Tools for the creation, management and access to user-generated content are currently very popular, as witnessed by the success of sites such as YouTube and Facebook, amongst others. The Europeana network comprises communities of archivists, curators and librarians who show a growing interest in exploring new methods of access and dialogue. User-Generated-Content (UGC) is one aspect of this renewed way of participating. Information about cultural heritage exists outside the heritage institutions; artifacts, written sources and memories of individuals complement collections held within the institutions. UGC services are designed to provide users with a means to support and interpret content. They will be involved in storytelling, curating of virtual exhibitions, reviews and even the creation of new collections. Greater participation will increase users’ interest and loyalty. Europeana is therefore devoting increasing resources to initiatives that bring out the value of the contribution those users can make.
Figure 1: UGC service architecture.
In response to these needs, the ASSETS Consortium has included the support of user-generated content amongst the services it will develop for Europeana. ASSETS is a two-year Best Practice Network that aims at improving the accessibility and usability of Europeana. The ASSETS Consortium comprises 24 partners, including institutions from ten different European countries and Japan, active in the field of cultural heritage and digital libraries.
Rather than focusing on a specific set of UGC applications, ASSETS is developing a general purpose, back end component that aims at supporting any UGC service that Europeana offers its users. To this end, the ASSETS back end component implements an Application Programming Interface (API) for creating, storing and manipulating UGC Units of Work, and for submitting these Units of Work to Europeana, in the form of Europeana Submission Information Packages (SIPs). End users will interact with their Units of Work through client interfaces, which hide from them the unnecessary technical details and complexities of the back end, providing the level of representation that is most suitable for the specific UGC task at hand. It is expected that every UGC task will be supported by a different end user interface. This will have no impact on Europeana, since each front end will talk to Europeana through the same API.
The API will relieve future UGC applications from implementing any server side functionality; they will have to code only the client side, connecting the user world to the API. At the same time, the API will take away from Europeana the technical interoperability problems that would arise from integrating into its database objects coming from future UGC applications. The service will rely on the Europeana Data Model (being developed by the Europeana version 1.0 project) in order to tackle the more serious semantic interoperability problems.
The definition of the conceptual model underlying the UGC API is the most difficult challenge that the ASSETS UGC team is facing. The model has to strike an optimal balance between simplicity, ie easy-to-learn and easy-to-code by future UGC service developers, and generality, ie to satisfy the needs of any future UGC service. This conceptual model was defined during the first year of the ASSETS project on the basis of an analysis of different types of requirement. The model was subsequently used to define the UGC API, the first version of which should be ready by June 2011. A few initial UGC tasks will be implemented on top of the API through specific front ends. These tasks will allow Europeana users to contribute to the contents of the digital library in several ways, eg uploading new objects along with simple descriptions, annotating existing objects, or enriching existing descriptions.
The UGC service will be evaluated by the task developers and by the end users within the project’s lifetime. The former will evaluate the adequacy of the API, while the latter will evaluate the adequacy of the front ends. The outcome of the evaluation will lead to a refinement of both the back end component API and implementation, and the front end UGC applications.
Each user WS is endowed with an Inbox. Messages in the Inbox are of two kinds: query results and notifications that communicate the result of submissions. Positive notifications will report the successful ingestion of a SIP, negative notifications report the reasons why a given SIP could not be ingested. Rejected SIPs can be retrieved and re-transformed into a UoW so that users can perform necessary reparations.
It is important to note that these concepts define a general-purpose schema, whose machinery need not be used by every UGC application. For instance, a simple UGC task that takes place in a single session, such as an image upload, may be implemented by directly building the corresponding SIP, by-passing the UoW stage. On the other hand, another UGC application may decide to publish a finished UoW to a community of users in order to perform a socially oriented form of mediation before submitting the UoW to Europeana. These decisions will be taken by the client side of the applications, relying on appropriate shortcuts offered by the UGC API.
Links:
http://www.europeana.eu
http://www.assets4europeana.eu
http://version1.europeana.eu/web/europeana-project/
http://europeanalabs.eu/wiki/
Please contact:
Carlo Meghini
ISTI-CNR, Italy
E-mail:
