The concepts beneath the MICHAEL platform publishing module
Before attempting to customize the publishing module to suit your own needs, it is important to understand how this module works, what objects are available, what are the basic functionalities, etc.
1) Overview
The publishing module can be seen as a toolbox . There are functionalities and an Application Programming Interface (API) to execute them. Once executed, a functionality returns data, information, or may be an error message. This data or information can then be displayed for the final user.
The aim of this document is not to give a reference definition of this API and the way to use that, but to give some basic information helping to understand this API.
The publishing module works with a MICHAEL platform database, containing records of different types: digital collections, physical collections, institutions, projects or programmes and services or products. The methods used to create these records is not important here. At a given moment, records are published , which means they are made available to the publishing module and thus to the final users. This publishing operation is activated from the MICHAEL production module, so once again it is not important here, only its result are considered.
Publishing a record basically means this record – and possibly information from related records – will be indexed with the publishing module's underlying search engine, SDX. Once indexed, they can be browsed, searched and displayed.
2) Description of concepts and functionalities
2.1) Searching
2.1.1) Search units, search fields, search model
The search engine is a classical documentary search engine. It means that search is always performed against a set of objects we will call search units . These search units are closed to records in the MICHAEL database, but they are not exactly records.
A search unit is composed of search fields, such as a title field, a full-text field, a description field, etc. Search fields are closed to fields in the MICHAEL data model, but they are not exactly the same. The full-text fields is a very good example of such differences.
There are five types of search units in the publishing module, one per type of records. These search units don't have exactly the same fields, but some may be common, such as full-text or title.
Searches can be performed against a specific type of search units or different types of search units at once. They can even be performed against more specific subsets of search units.
The search model is a classical boolean-based model: words or expressions are searched in fields,
they can be related into a more complex query with boolean operators. The results are always a flat and ordered list of search units, nothing else.
2.1.2) Simple searches
A simple search contains only a single expression, although the query language behind is very sophisticated. A simple search is like the one that can be done on Google's homepage, with a simple text box to enter the query terms, typically one or a few words.
The simple search functionality in MICHAEL helps displaying a simple search text box, selecting the search units (for example the digital collection records) and executing the query. The results are discussed later in this document.
2.1.3) Advanced search forms
An advanced search form let the user combine various criteria with boolean operators. For example, if a user wants to search digital collections about philosophy and South-America, it could be accomplish with an advanced search form containing two criteria, one for searches in the subject field, and another for searching in the spatial coverage field.
The toolbox provides a way to create advanced search forms, execute the relevant searches once the form is filled in and submitted, and for displaying results. The results are discussed later in this document.
An advanced search form is defined in a simple XML configuration file. This file contains basically the list of controls or widgets used to display the form, and the fields they are acting on. Different types of widgets can be used : simple text box, drop-down list, multiple selection list of various types, checkbox, radio button, etc. Some of these widgets can be automatically filled with values extracted from fields, such as lists or checkboxes.
In the previous example, we could imagine that the search form would be composed of two widgets, two lists already filled in with contents from the subject and spatial coverage fields. It would then be easy for the user to select the appropriate terms for its query.
2.1.4) Search results
Search results are returned when a query is executed. They are structured in XML but this XML can be converted in HTML for display in a standard browser.
In this XML, one can find general information such as the number of units found, the query executed, the number of results per page, the currently displayed page, etc. Also, for each unit found, one can find the summary information for this unit, which are some fields and also system data such as an identifier and where the original data can be found. The summary information can be the unit's title and other information needed to build a brief record with minimal information. Search results can be displayed page by page, and the number of results per page can be specified.
2.2) Browsing
Browsing can be considered as predefined and directed searches. For instance, if we browse content by subject, once a subject is selected and relevant records are displayed, it can be considered as a search for the subject selected in the subject field.
The basic pattern for browsing is the following one : the user selects a browsing axis, such as “browse digital collections by subject”. Then, a list of values is presented to the user, such as the list of subjects extracted from the indexed records. Then, the user selects a term in the list and sees the relevant records.
The publishing module API provides an easy way to propose browsing for users. In an XML configuration file, the implementer can define the fields that can be used for browsing, for each type of records. He can also configure the way fields terms are presented for each field, such as the number of terms per page and the number of columns to use for displaying terms in the page. From this simple configuration information, browsing functionalities can be implemented in the user interface.
Browsing can also be more complex, such as browsing using a map, browsing hierarchical lists or a thesaurus, etc. The API currently don't provide such browsing features easily, but they could be added depending on the needs.
2.3) Displaying
Once user find relevant information by searching or browsing the database, they want to read the records they found. The displaying features provide this experience.
Displaying a record means converting the underlying XML to HTML for the browser. The platform provides a basic display of records, but the implementer can modify it using CSS stylesheets for simple changes or XSLT transformations for more complex changes.
Displaying a records can also be contextualize, for instance to provide links for the next or previous records in from the search results or to go back to these search results. Information from other records can also be included.
2.4) Slide show
A slide show is a simple way to give users a more pleasant experience with the contents of a MICHAEL database. The idea of the slide show is to present a prepared list of digital collection records with a simplified display, but also with back and next buttons in order to see all the records.
It is similar to search results, but here the results are not the consequence of a query expressed by the user, but a consequence of an editorial work by the editors of the database. This editorial work consist of selecting records, putting them in a specific order, and optionally adding some specific comments. Records can be selected individually of be the result of a predefined query.
The implementer can modify the display of the slide show but not the functionalities.
2.5) General graphical interface
The users interacting with a site built with the MICHAEL platform publishing module see a Web site with a general graphical interface, with consistent headers and footers, menus, etc. This graphical interface comes from HTML templates the implementer can modify. These templates may contain some specific tags in order to exploit the API. For instance, there can be a tag for the display of a simple search form, another for the display of search results, etc.
Although the publishing module is delivered with a complete graphical interface, it is expected implementers will modify it to use the institutions conventions or design.
2.6) Static and semi-static information
Searching, browsing, displaying, slide shows are all functionalities based on the content of the database. It is also possible to have static information, which don't depend on the content, such as a homepage, help pages, general information, etc.
These static pages are simply defined in HTML and automatically inserted where needed, into the standard headers and footers of the site. Thus the implementer don't have to worry about the general design when he creates the static information, only the content is important.
Some static pages can also contain tags that will fire some functionalities, such as displaying a search form. They are called semi-static but work the same way.
3) Examples
The examples provided come from the description of user interface needs from UK and France, in the context of the MICHAEL project. The idea of this section is to relate the needs contained in these documents to functionalities of the toolbox, see what it missing, if everything is useful, etc.
3.1) UK examples
The reference document is the PowerPoint presented by Kate during May 4th meeting in Roma.
3.1.1) Homepage
The following figure shows some ideas for a homepage:
 |
This example homepage can be considered static, even if the search box could use the toolbox, but it would probably be better to do it statically for a better graphical integration.
3.1.2) Browsing – What ?
The following figures shows how browsing by subject could be presented to the user:
 |
From a purely content point of view, this figures present a list of terms from a subject field. It is thus a browsing functionality as proposed in the toolbox. From a graphical point of view, for each term there is a linked image. This presentation could be achieved by extending the toolbox display features for search terms. It can be generalized – if desired – by building it from a configuration file, although some thoughts must be given to the fact that the list of terms can change when records are added or modified.
It would also be interesting to evaluate this presentation from an accessibility point of view.
3.1.3) Browsing – Maps
The next figure shows the use of maps:
 |
Browsing records using maps will be possible, but we still need to decide how it will be implemented in each instance. For example, browsing UK regions is relevant for the UK instance, but probably not for the French instance.
3.1.4) Browsing – When?
The next figures shows two ways to browse by period:
 |
The second one is the same as the browsing by subject presented above. The first one, in the top left, uses timelines for comparing periods between countries. This is interesting for the trans-European services, but probably not for a national instance. This kind of presentation can be used, but some discussions on details must be made, such as how to configure it, how to take into account the actual terms or dates used in a database or a country, etc.
3.1.5) Tools for the developers
The document proposes three tools for developers of other sites or for a MICHAEL platform implementer. The next figures shows these three propositions:
 |
Embedding MICHAEL functionalities within an external webpage is possible if the MICHAEL publishing platform provides an open and documented API, which is expected. For instance, searching, browsing and displaying functionalities will be accessible from simple URLs returning XML data. An external sites can use this mechanism to include functionalities within another site.
Building a MICHAEL interface for a specific region is like implementing a new instance. Everything discussed here can be applied for any instance.
Including MICHAEL newsfeeds into other pages is possible if these newsfeeds are standard ones. See below for newsfeeds but including them elsewhere doesn't really depend on the MICHAEL itself.
3.1.6) Search box generator
The next two figures illustrate a functionality for developers of other Web sites.
 |
 |
The second figure is just a more detailed version of the first one. The idea is to give external developers the exact code needed to include a search box in their Website. This is not a problem, although the most difficult part for an external developer is not to build a search box, but to do something useful with the results obtained, unless the aim is only to open a standard MICHAEL search results window.
3.1.7) General information
The next figures show needs for providing general information to users:
 |
The static pages functionality from the toolbox can be used for such informations. It is then a matter of writing them, making links or menus, etc.
3.1.8) Newsfeeds
Providing news in a standard way is illustrated in the next figure:
 |
There are three aspects here.
What news? General information on the project, the site, etc. Having news had been suggested last summer but rejected by all partners (too difficult to maintain). Do we want it now? News about newly added collections seems natural and easy, but care must be taken for such things as a massive import of records (from an external source for instance), what do we do for modified records, etc.
What format? RSS is probably the most common one among the standards, but there are other options such as Atom.
How to use it into other sites? External developers should take care of that, there are many tools available for including standard newsfeeds into a Web site.
3.1.9) Latest additions
Similar to the previous discussion on newsfeeds, the next figures shows the latest additions to a MICHAEL database:
 |
These can be search results sorted by creation date in reverse order, with ma maximum number of results displayed. French have similar needs (see below).
3.2) FR examples
The base document is a PowerPoint presentation sent by Martine Tayeb on June 3rd . Is has been created following many discussions within the French group.
3.2.1) General graphical user interface
The PPT file doesn't contain the definitive graphical user interface, but it gives an idea of the general layout. The following figure (homepage) is useful for explaining this layout.
 |
We see that the header will have logo, title and links. These are static information. It will also contain a list of languages, a menu and a simple search forms. All these can be displayed using the toolbox API. The footer contains logos and will be static.
3.2.2) Homepage
The preceding picture gives an idea of the content of the homepage. In the left part, we have some dynamic informations : the number of records of type digital collection and institution. The API can provided these numbers. Browsing opportunities are static information (Sujet, Type de document, etc.).
The map in the bottom left corner is a dynamic browsing feature. It is built from the list of regions found in the spatial coverage field, and displayed both as links on a map and in a drop-down list.
The central part of the page is purely static information. It contains general information about the site.
In the right part, there is first static information, then a partial view of a new record. There could be an API call in the toolbox for this information, but some more information is needed: is it the really latest record added? In the bottom right information, static information is given, although it links to one specific slide show.
3.2.3) Latest additions
The following figure contains the 15 latest additions to the database:
 |
It can be seen as a predefined query: all the records, sorted by creation date (or modification date ?), the latest first, and return only the 15 first records found. The results are presented in a standard way (see below).
3.2.4) Search results
The previous figures shows how search results are presented. For each record found, there is a brief view or summary of the record displayed. This summary contains the title of the collection, the name of related institutions, a thumbnail, and some icons indicating the content type of the collection.
The information that can be displayed in a summary for each type of record still needs to be defined, but all the information found in this example could be part of it.
3.2.5) “Dossiers”
Dossiers are like a special editorial collection of records, introduced, explained, etc. The next figure shows the main page of such a dossier:
 |
3.2.6) Browsing – subjects
The next figure shows how the subjects can be presented for browsing:
 |
The results of clicking on a term are displayed in the next figure:
 |
These are mainly search results as discussed above. But we can see that there is context information at the top (Sujet > Beaux-Arts) and also a link to refine the query. The intention here is to go to an advanced search form (see below) and to prefill the form with the currently browsed value (Beaux-Arts). This can be done.
3.2.7) Displaying a record
The next figure shows the display of a digital collection record:
 |
Illustrations are on the right, links on the left, etc. There is nothing particular with this display, it shows among other things that information can be included from linked records, such as the “Informations techniques” part, coming from a project record.
The next figures shows the display of an institution record:
 |
This display is centred on the digital collections and services linked to the record. Information about the institution itself is on the right. Once again, this can be done with embedding content from linked records.
3.2.8) Advanced search forms
The next figure show an advanced search form example:
 |
This is a simple example of what can be done with the advanced search form toolbox. All the search criteria are displayed with a simple drop-down list, and they are combined with a boolean AND. The exception is the first criteria, a text box to search into the full-text field.
3.2.9) Reports and exports
The next figures shows a form to let users export data about an institution to PDF or RTF:
 |
Export of records to PDF will be possible, RTF probably. The idea here is to group records together on a specific query, “everything about an institution”.
The next figure gives some ideas of reports:
 |