The Semantic Web is based on the idea that Web applications provide semantically annotated Web pages. This metadata is typically added in the semantic annotation process which is currently not part of the Web engineering process. Web engineering, however, proposes methodologies to design, implement and maintain Web applications but lack semantic annotation. In this paper we show how WEESA, a mapping from XML documents to ontologies, can be used in Apache Cocoon Web applications to semantically annotate Web pages. We introduce Cocoon transformer components that use the WEESA mapping definition to automatically generate RDF meta-data from XML documents. We further show how existing Cocoon Web applications can be extended to Semantic Web applications and discuss the experiences gained in an industry case study.
The increasing popularity of the WWW has lead to an exponential growth in the number of Web pages available, which makes it increasingly difficult for users to find required information. In searching the Web for information, one gets lost in the vast number of irrelevant search results and may miss relevant material. Current Web applications provide Web pages in HTML format representing the content in natural language only and the semantics of the content is therefore
In this section we briefly introduce Web engineering and
show how WEESA [
Web Engineering focuses on the systematic design,
development, and maintenance of Web applications [
In order to develop Semantic Web applications, the
traditional Web engineering techniques have to be extended by
the semantic annotation process. In this process, the Web
pages have to be semantically annotated with RDF
metadata. This enables machines to have access to the content
of the pages. Several tools such as the SHOE Knowledge
Annotator [
To annotate dynamic Web pages, that obtain their content from a background logic such as a database, the annotation process should be integrated in the engineering process of the Web application. During the engineering of a Web application, information items can be identified more easily than in the generated HTML Web pages. Once the information item is identified, it is mapped to a concept defined in the ontology. For example, the result of a database query is mapped to a property in the ontology, to indicate that a new RDF statement has to be generated with the query result as value for the property.
The aim of WEESA (WEb Engineering for Semantic web Applications) is on the one hand, to integrate the annotation process into the engineering process of the Web application. On the other hand, to reuse the existing design artifacts of XML based Web applications to develop Web applications that provide semantic meta-data in addition.
In WEESA the structure of the XML document is used to identify XML elements/attributes which are mapped to concepts in an ontology. This mapping definition can then be taken to automatically generate RDF meta-data from XML content documents. WEESA not only allows one-toone mappings but uses a more flexible approach to overcome the gap between the information available in the XML document and the information needed by the ontology. The content of several XML elements/attributes can be selected and further processed in Java methods to meet the semantics of the concept in the ontology.
XML Schema
valid XML document
WEESA mapping definition generate
via WEESA generate via XSLT
Ontology
uses concepts RDF description
associate HTML Web page
Semantic Web page
Design Level Instance Level At the design level of the Web application only the structure of the XML document is known and no XML instances are available. Therefore we use the structure information from the XML Schema to define the mapping to the ontologies. In this way, the same XML document that follows the XML Schema is used for the XSLT transformation to generate HTML and for WEESA to generate RDF meta-data. Therefore, the XML Schema can be seen as the contract the content editor, responsible for writing the XML documents, the layout designer, responsible for the graphical appearance, and the engineer defining the WEESA mapping have to agree on. Figure 1 shows the definition of the WEESA mapping at the design level of the Web application and how this mapping is used at instance level to automatically generate RDF meta-data and the HTML page from XML documents.
In this section we introduce the concept of Apache Cocoon
Web applications. Apache Cocoon [
As shown in Figure 1, we have to perform two steps on the schema valid XML document to generate the semantically annotated Web pages: (1) The XSLT transformation has to be performed to generate the HTML page. (2) The WEESA mapping has to be processed to generate the RDF meta-data description of the Web page.
Once we have generated the HTML page and its RDF
metadata description we have to put them into relation.
Unfortunately, no standardized approach exists for associating RDF
descriptions with HTML. In [
A recently proposed technique to embed RDF into
HTML is RDFa [
Linking to an external RDF description: The RDF
meta-data description is stored in an external
document and the HTML page references to its
metadata description. This reference can be done using
the HTML <link> element [
In the following two sections we introduce a WEESA enabled Cocoon transformer for both categories of association styles.
One way to associate HTML and RDF is to embed the
RDF/XML description in the <script> element within the
HTML <head>. The HTML <script> element can be used
to include non-HTML media in HTML Web pages [
When developing Semantic Web applications that add the RDF meta-data to the HTML page we have to introduce new steps to the pipeline discussed in Section 3. Since we need the schema valid XML document for the XSLT transformation and for the WEESA meta-data generation, we have two options. We can either integrate WEESA in a modified XSLT transformer that generates RDF and HTML or we can split up the pipeline and use a specialized transformer for the RDF meta-data generation.
One of the strength of Cocoon is, that every component is specialized on a specific task. This gives the developer the flexibility to configure the components in the pipeline according to his requirements. Therefore we decided, to split up the pipeline to generate HTML pages with embedded RDF/XML. To split up the pipeline we use the WriteDOMSession transformer. This transformer takes the input document and writes it first as DOM2 into the servlet session, and second as SAX events to its output. This is how the pipeline is split up and the XML document can be reused later in the pipeline. After the HTML page is generated by the XSLT transformer the WEESAReadDOMSession transformer takes the DOM-XML from the session and uses the WEESA mapping definition to generate the RDF meta-data representation in RDF/XML format. The WEESAReadDOMSession transformer further embeds the generated RDF/XML in the <script> element which is then added in a user defined element of the HTML page. This element is typically the <head> element. The serializer finally delivers the HTML+RDF page to the client. The additional steps are shown in Figure 3 as light gray pipeline components. The problems that comes with embedding the RDF meta-data in the <head> element are discussed at the end of the this section.
The Cocoon framework uses the sitemap.xmap configuration file to define the pipelines. Figure 4 shows a fragment of the sitemap file for the pipeline from Figure 3. Lines 3-6 instruct Cocoon to start a servlet session. In line 9 the generator is instructed to read the XML document AlanisMorissetteUnplugged.xml from the content/ directory. In lines 14-17 the WriteDOMSession transformer is defined to write the XML document to the session. The dom-name parameter gives the DOM-object the name rdf in 2DOM: Document Object Model the servlet session. The use of the dom-root-element parameter is explained below. Line 20 configures the XSLT transformer to use the XSLT stylesheet albumInfo.xslt. In lines 23-29 the WEESAReadDOMSession transformer is configured. The dom-name parameter tells which DOM-object should be taken from the session, the weesa-mapping-definition parameter names the mapping file, and the triggerelement and position parameters tell that the generated RDF/XML should be placed in the HTML <head> element. Finally, in line 32 the serializer is instructed to write the XML stream as HTML to the consumer.
In praxis, most Web pages consist of several parts, for example a header, the navigation part, and a part with the actual page content. A sample XML document following this structure is shown in Figure 5. Depending on the structure of the Web page, not all parts of the XML document have to be looked at when generating the RDF meta-data. For example, only the <content> part contains information that is needed for the meta-data generation. In this case, we have to define the WEESA mapping only for the subtree starting with the <content> element and we have to inform the WriteDOMSession transformer only to write the subtree following the <content> element as DOM to the session. This is done with the dom-root-element parameter in line 16 from Figure 4. <page > < header >
<! -- here goes the XML for the header --> </ header > < navigation >
<! -- here goes the XML for the navigation --> </ navigation > < content >
<! -- here goes the XML for the content -->
</ content >
</ page >
that the business logic, typically processed at the beginning
of the pipeline, has to be computed once only for both the
HTML and RDF generation. Embedding the RDF/XML
meta-data in the <head> tag of a HTML document,
however, breaks HTML 4.01 and XHTML validity [
Another way of associating RDF and HTML to one another
is to use the <link> element in the <head> of the HTML page
to reference the corresponding external RDF/XML
metadata description [
Cocoon Web applications that use the <link> element to associate RDF and HTML need two pipelines: one for the generation of the HTML page, and another for the WEESA meta-data generation. The pipeline for the HTML generation is similar to the one introduced in Section 3. Only the reference to the RDF description has to be added in the <head> of the HTML page. The reference looks as follows: <link rel="meta" type="application/rdf+xml"
href="AlanisMorissetteUnplugged.rdf"/> There are basically two ways of adding the <link> element to the HTML page. One is to modify the Web application to add the element in the business logic or in the XSLT stylesheet. The other possibility is to use the AddRDFLink transformer we developed. This transformer is added to the pipeline for the HTML page generation between the XSLT transformer and the serializer. The AddRDFLink transformer extracts the URL of the incoming request, replaces the ".html" suffix of the path with ".rdf", and adds the <link> with the ".rdf" URL in the <head> of the HTML page.
Since the AddRDFLink transformer searches for a ".html" suffix in the URL and replaces it with ".rdf" it can only be used in Web applications that obey the following naming convention. The path in URLs that trigger the pipeline for the HTML pages have the suffix ".html" such as: http://www.mytunes.com/album.html?id=1234 Including RDF/XML meta-data in the HTML page using the WEESAReadDOMSession transformer has the advantage The path in URLs that trigger the pipeline for the RDF meta-data generation have the suffix ".rdf" such as:
In the pipeline for the WEESA meta-data generation that uses the WEESA transformer the business logic is also processed at the beginning of the pipeline. The schema valid XML document is sent to the WEESA transformer that takes the mapping definition and processes the WEESA mapping. The RDF/XML output of the transformer is then taken by a serializer and sent to the client. The pipeline is shown in Figure 6 and Figure 7 shows a snipped from sitemap.xmap that is used to configure the WEESA transformer. Again, the dom-root-element parameter defines the start element of the XML subtree that should be considered for the WEESA transformation as described in the section above, and the weesa-mapping-definition parameter defines the mapping definition to be used. < map:transform type =" WEESA " > < map:parameter name ="dom - root - element " value =" content "/ > < map:parameter name =" weesa - mapping - definition " value =" mapping / artistMapping . xml "/ > </ map:transform > Using the <link> element to associate RDF and HTML has the advantage that the RDF description has to be generated on request only. This, however, has the drawback that the schema valid XML document has to be generated a second time. Fortunately this does not have to be a big disadvantage if the Cocoon caching mechanism can be used.
We have evaluated the WEESA transformers in the annual Vienna International Festival3 (VIF) industry case study. VIF is a database supported Web application that comprises a ticket shop, over 60 event descriptions, reviews, and an archive over the last 52 years. For the WEESA case study 3http://www.festwochen.at we use the event descriptions and the ticket shop and semantically annotate the corresponding Web pages. Below we list the Web pages that make up the case study and discuss the meta-data the pages provide: VIF Homepage: Entry point to the VIF Web application.
It provides general information about the festival and a navigation bar to the features of the Web application. The meta-data consists of the contact information of the festival.
Program overview pages: List of events of the festival.
There is one list of all events and several lists for the events of a specific event category (such as concert, performing arts, etc.) The meta-data consists of the events, location, and the category of the event.
Event description: Detailed information about the event.
It contains information such as the title, description, location, date, etc. of the event. The meta-data reflects the event details provided by the Web page. Ticket shop receipt: Receipt of the bought ticket. It is the final acknowledgement of the shopping process in the online shop containing all the details of the specific event. The meta-data reflects event details of the bought ticket.
When we chose the case study application we decided not to
design a new Web application from scratch but to adopt an
existing one. This decision has the advantage that we are
able to work out the differences between the design of
traditional Web applications and Semantic Web applications.
The VIF Web application was originally implemented using
MyXML [
During the life cycle of a Web application a new version
of the used ontology may be issued or a new ontology
become the standard ontology to describe information in the
domain of the Web application. Therefore, WEESA was
designed to enable the change of the used ontology without
reimplementing the whole Web application. To demonstrate
this flexibility we implemented the case study first with a
self-defined VIF ontology and changed later to the
iCalendar [
In addition, the change between the two association styles of HTML and RDF, also could be done by only modifying the pipeline configuration. The WEESA mapping definitions remains the same.
Change of ontologies: We implemented the VIF case study Semantic Web application for different ontologies. For the change from one ontology to the other, only the WEESA mapping definition used had to be changed. The rest of the implementation remained untouched and no additional programming effort was needed.
Java Mapping Library: In the two paragraphs above we argued, that no Java programming is involved to semantically annotate a Cocoon Web application using WEESA. This is true regarding the Web application. To not only support one-to-one mappings from XML to the ontology Java methods are used in the WEESA mapping definition. WEESA provides a library of Java methods for common tasks. In some cases, however, the developer has to implement a Java method for a user-specific task. This user specific method can be added to the library for later reuse. Free-Text and Mixed Content: Since WEESA uses the structure of the XML document to identify the concepts that are mapped to the ontologies, free-text and mixed content can not be annotated. Natural language understanding would be needed to do so. However, in our experience this is not a problematic limitation since the concepts that can be found in many ontologies available today can also be found in the structure of an XML document.
Database Keys for RDF Resource Identifier: The VIF case study further showed that database keys should be accessible in the XML documents to be able to generate unique resource identifiers for the RDF representation. The database keys help to ensure that the same identifier is used for the same resource throughout the whole Web application. Well Formatted data in the XML document: Since the RDF meta-data description of the Web pages is intended to be machine-processable the literals used should store information in a well defined format. For example to represent time and date information the XML Schema xsi:time respectively, xsi:date format should be used. This requirement should also be kept in mind when defining the XML Schema as contract for a Web page. The schema should force content editors to provide information split up into logical units that are stored in a well defined format. For example, to specify the begin and end time of an event, it is better to have a specific XML element for the begin and end time instead of an arbitrary string such as "from 11:00 to 12:00". Using arbitrary strings results in pattern matching, when defining the WEESA mapping.
To our knowledge not much work has been done to integrate
the Semantic annotation process into Web engineering. In
[
Many Web engineering methodologies have been proposed
that use Semantic Web technologies such as ontologies and
RDF to formalize engineering artifacts. The Extensible Web
Modeling Framework (XWMF) [
In the area of interpreting XML as RDF data several
approaches exist. In [
The success of the Semantic Web crucially depends on the existence of semantically annotated Web pages. Current Web engineering methodologies and frameworks, however, lack techniques to provide semantic meta-data. To annotate Web pages, information items have to be identified and mapped to the concepts that are defined in ontologies. Since it is easier to identify these information items in structured data-sources (e.g., databases, XML), which are available while engineering the Web application, than in the generated HTML pages, we argue that the semantic annotation process should be integrated into the engineering process of the Web application.
In this paper we introduced Apache Cocoon transformer components that can be used to generate semantic metadata out of existing Web engineering artifacts. These transformer use WEESA, a mapping from XML elements/attributes to concepts in ontologies, to automatically generate RDF from XML documents and can therefore be used to develop Semantic Web applications. In this paper we further presented the experiences gained while using WEESA for developing a Semantic Web application.