
		 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
		 %     CASE 1: FACET BROWSER	%
		 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\newcommand{\component}[1]{\emph{#1}}
\newcommand{\componentlater}[1]{{#1}}
\section{Case study --- Faceted browser on Semantic Web 
database integrating multiple collections}~\label{sec:facetb}

In this case study we describe a pilot for the
STITCH-project\fnurl{http://www.cs.vu.nl/STITCH} whose main aim is
studying and finding solutions for the problem of integrating controlled
vocabularies  in the
Cultural Heritage domain, such as thesauri and classification systems.
The pilot consists of the integration of two collections -- the Medieval 
Illuminations of the Dutch National Library (Koninklijke 
Bibliotheek) and the Masterpieces 
collection from the Rijksmuseum -- and development of 
a user interface for  browsing the merged collections. One 
requirement within the pilot is to use ``standard 
Semantic Web techniques'' during all stages, so as to be able to evaluate 
their added value. An explicit research goal was to evaluate existing
``ontology mapping'' tools.

The problem could be split into three main tasks:
\begin{itemize} 
\item
Gathering data, i.e.\ records of the collections and controlled 
vocabularies they use, and transforming it into RDF.
\item
Establishing semantic links between the vocabularies using off-the-shelf 
ontology mapping tools. 
\item
Building a prototype User Interface (UI) to access (search and browse) the 
integrated collections and experiment with different ways to access them 
using a Web server.
\end{itemize}
SWI-Prolog has been used in all three tasks; to illustrate the use of 
the SWI-Prolog Web libraries in our pilot, we focus on 
their application in the prototype UI in the next section  because it
is the largest subsystem of the pilot using these libraries.

\subsection{Multi-Faceted Browser}

Multi-Faceted Browsing is a search and browse paradigm where a collection
is accessed by refining multiple (preferably) structured aspects 
-- called facets -- 
of its elements. For the user interface and user interaction we 
have been influenced by the approach of Flamenco~\cite{hearst02finding}. The 
Multi-Faceted Browser is implemented in SWI-Prolog. All data is stored 
in an RDF database, which can be either an external SeRQL repository or an 
in-memory SWI-Prolog RDF database. The system consists of three components, 
\component{RDF-interaction},
which deals with RDF-database storage and access, 
\component{HTML-code generation}, for the creation of Web pages 
and the \component{Web server} component, 
implementing the HTTP server. They are discussed in the 
following sections.

\subsubsection{RDF-interaction}
\label{sec:rdfinteraction}
We first describe the content of the RDF database before explaining how to 
access it. The RDF database contains:
\begin{itemize}
\item
750 records from the 
Rijksmuseum, and 1000 from the Koninklijke Bibliotheek.
\item
RDF representation of the hierarchically structured facets, 
we use SKOS\footnote{\url{http://www.w3.org/2004/02/skos/}}, an 
ontology dedicated to the represention of controlled vocabularies.
\item
Mappings between SKOS Concept Schemes used in the different collections. 
\item
Portal-specific information as ``\jargon{Site Configuration Objects}'', 
identified by 
URIs with properties defining what collections are part of 
the setup, what facets are shown, and also values for the constant text in the
Web page presentation and other User Interface configuration properties. 
Multiple such Site Configuration Objects may be defined in a repository.
\end{itemize}

The in-memory RDF store contains, depending on the number of mappings
and structured vocabularies that are stored in the database, about
300,000 RDF triples. The Sesame store contains more triples -- 520,000
-- as its RDFS-entailment implementation implies generation of derived
triples (see \secref{serql}).
  
\paragraph{RDF database access}

Querying the RDF store for more complex results based on URL query
arguments consisted of three steps: 1) building SeRQL queries from URL
query arguments, 2) passing them on to the SeRQL-engine, gathering the
result rows and 3) finally post-processing the output, e.g. counting
elements and sorting them. \Figref{srqlex} shows an example of a
generated SeRQL query. Finding matching records involves finding records
annotated by the facet value or by a value that is a hierarchical
descendant of facet value. We implemented this by interpreting records
as instances of SKOS concepts and using the transitive and reflexive
properties of the rdfs:subClassOf property. This explains for example
\verb-{Rec} rdf:type {<http://www.telin.nl/rdf/topia#Paintings>}- in
\figref{srqlex}.

\begin{figure*}
\begin{verbatim}
SELECT  Rec, RecTitle, RecThumb, CollSpec
FROM {SiteId} rdfs:label {"ARIATOPS-NONE"};
            mfs:collection-spec {CollSpec} mfs:record-type {RT};
            mfs:shorttitle-prop {TitleProp};
            mfs:thumbnail-prop {ThumbProp},
{Rec} rdf:type {RT}; TitleProp {RecTitle};
      ThumbProp {RecThumb},
{Rec} rdf:type {<http://www.telin.nl/rdf/topia#AnimalPieces>},
{Rec} rdf:type {<http://www.telin.nl/rdf/topia#Paintings>} 
USING NAMESPACE skos = <http://www.w3.org/2004/02/skos/core#>,
mfs = <http://www.cs.vu.nl/STITCH/pp/mf-schema#><br>
\end{verbatim}
   \caption{An example of a SeRQL query, which returns details of records
matching two facet values (AnimalPieces and Paintings)}
    \label{fig:srqlex}
\figrule
\end{figure*}

The SeRQL-query interface contains timing and debugging facilities
for single queries; for flexibility it provides access to an external SeRQL 
server\footnote{We used the \file{sesame_client.pl} library that provides an 
interface to external SeRQL servers, packaged with
the SWI-Prolog SeRQL library} for which we used
Sesame\footnote{\url{http://www.openrdf.org}}, but also to the 
in-memory store of the SWI-Prolog SeRQL implementation described in \secref{serql}.



%We plan to develop a generic procedure
%for the post-processing, using SQL-like constructs such as ``count(..)'' and 
%``group by''.

\subsubsection{HTML-code generation}

We used the SWI-Prolog \file{html_write.pl} library described in 
\secref{htmlwrite} for our HTML-code generation. There are three distinct kinds of Web 
pages the multi-faceted browser generates, 
the portal access page, the refinement page and the single collection-item  
page. The DCG approach to generating HTML code made it easy to share HTML-code 
generating procedures such as common headers and HTML code for refinement of 
choices. The \componentlater{HTML-code generation} component contains some 140 DCG 
rules (1200 lines
of Prolog code of which 800 lines are DCG rules), part of which are simple 
list-traversing rules such as the example of \Figref{htmlex}.

\begin{figure*}
\begin{verbatim}
objectstr([],_O, _Cols,_Args) --> [].
objectstr([RowObjects|ObjectsList], Offset, Cols, Args) -->
        { Percentage is 100/Cols },
        html(tr(valign(top),\objectstd(RowObjects, Offset, Percentage, Args))),
        { Offset1 is Offset + Cols },
        objectstr(ObjectsList, Offset1, Cols, Args).

objectstd([], _, _, _) --> [].
objectstd([Url|RowObjects], Index, Percentage, Args) -->
       {   ..
           construct_href_index(..., HRef),
           missing_picture_txt(Url, MP)
       },
       html(td(width(Percentage),a([href(HRef)],img([src(Url),alt(MP)])))),
       { Index1 is Index + 1 },
       objectstd(RowObjects, Index1, Percentage, Args).
\end{verbatim}
   \caption{Part of the html code generation for displaying all the images of a 
query result in an HTML table}
    \label{fig:htmlex}
\figrule
\end{figure*}


\subsubsection{Web Server}

The Web server is implemented using the HTTP server library described 
in \secref{httpd}. The \componentlater{Web server} component itself is very 
small. 
It follows 
the skeleton code described in \Figref{httpreply}.
In our case the \index{reply/1}\predref{reply}{1} predicate 
extracts the URL root and 
parameters from the URL.
The \jargon{Site Configuration Object}, which is introduced in 
\secref{rdfinteraction}, is returned by the \componentlater{RDF-interaction} component 
based on the URL root. It is passed on to 
the \componentlater{HTML-code generation} component which generates Web content
 as 
shown in \index{reply_page/1}\predref{reply_page}{1} in \Figref{affiliation}. 



\subsection{Evaluation}

This case study shows that SWI-Prolog is effective for building applications in
the context of the Semantic Web. 
In a single month a fully functional prototype 
portal has been created providing structured access to multiple collections. 
The independence of any external libraries and the full support of
all libraries on different platforms made it easy to develop and install in 
different operating systems. All case study software has been tested to 
install and run transparently both on Linux and on Microsoft Windows.

At the start of the pilot project we briefly evaluated existing environments
for creating multi-faceted browsing portals:
We considered the software available from the Flamenco 
Project~\cite{hearst02finding}
and the OntoViews Semantic Portal Creation Tool~\cite{ontoviews}.
The Flamenco software would require developing a
translation from RDF to the Flamenco data representation. OntoViews 
heavily uses Semantic Web techniques, but the software was unnecessarily 
complex for our pilot, requiring a number of external libraries. This together 
with our need for flexible experiments with various setups made 
us decide to build our own prototype. 

The prototype allowed us to easily experiment with and develop various 
interesting ways of providing users access to integrated heterogeneous 
collections. The pilot project portal is accessible on line for your 
evaluation 
at \url{http://stitch.cs.vu.nl/demo.html}. An article describing the results 
of the pilot project is currently under review~\cite{stitchpilot1}.
   

% Illustration of `smart portal'?
% Illustrate use of html_write.pl
