Currently, one of the important focal points of the evolution of the World Wide Web is the semantic web: a web in which the semantics of the available content and functionality is made explicit. Web Design Methods, originally aimed at offering the designer a well-structured, systematic approach to web design, now face new opportunities and challenges: on one hand, semantic web technology can be used internally in web design methods to make the semantics of the different design models explicit, on the other hand, a major challenge for existing design methods is to (semi-) automatically generate the semantic annotations, effectively enabling the semantic web. In this paper, we describe how WSDM, one of the first web design methods, was adapted to (internally) use semantic web technology. In addition to its existing strengths (i.e. solid design support for website structure and presentation) as a traditional web design method, we show how the internal use of semantic web technology can be exploited to support the generation of semantically annotated websites.
With over a decade of evolution, the World Wide Web has undergone some dramatic changes. While websites at first consisted of a handful of linked (static) pages, they are now complex applications, offering (rapidly changing) information and functionality to a highly diversified audience. To keep up with the growing needs and demands of visitors, web technology evolved at an equally dazzling rate. In this setting, it gets more and more difficult to design a website in an ad hoc way. The resulting websites lack consistency, both in structure and presentation, and transparency. Visitors fail to build a mental model of the website, causing them to feel ‘lost in hyperspace’.
Web site design methods were conceived to help the web designer in coping with the complexity of designing and creating websites. By offering abstractions for the different design concerns, and a systematic approach to web design, these design methods succeeded in helping the designer to create more usable websites.
With the conception of the semantic web, and related technologies (e.g. RDF, OWL, …), new challenges and opportunities for web design methods arose. The aim of the semantic web is to make the semantics of the available web content explicit, thereby facilitating machine understanding and processing (of the content). Building on their strength in providing design support for website (navigation) structure and presentation, a challenge for web design methods is to support the (semi-) automatic generation of semantic annotations. An opportunity however lies in the use of semantic web technologies internally in the web design method. More particularly, the use of ontologies, which capture semantics, allows to explicitly express the semantics of the different design models, as well as the semantics of the represented data.
Some web design methods use ontology languages to internally represent
information (see related work). As far as the authors are aware of, only limited support exists
for automatic generation of semantic annotations based on web design models. There
exist however manual and semi-automatic (based on natural language parsing)
annotation techniques (see related work). In this paper, we discuss how WSDM, one of
the first web site design methods, was adapted to suit the needs of the semantic web
on one hand, and to benefit from semantic web technology on the other hand. We
further extend our previous work on semantic annotations as described in [
The remainder of this paper is structured as follows. Section 2 gives an overview of the WSDM approach and informally discusses the WSDM Ontology capturing the different design models. Chapter 3 discusses how WSDM supports semantic annotations at a conceptual level (during design), and points out problems and solutions. Chapter 4 describes in more detail the actual generation process of both website and semantic annotations. Chapter 5 gives an overview of related work and finally section 6 states conclusions. 2
WSDM was developed in 1998 by De Troyer and Leune [
WSDM originally targeted ‘traditional’ websites. With the emergence of the semantic web, WSDM has been adjusted to support the generation of semantic websites: the web content is annotated with semantic information. To facilitate the specification of semantic information (during design), and the generation of semantic annotations (during implementation generation), an OWL ontology is used to formally define the different design models, and to perform data and functionality modeling. This OWL ontology formally specifying the different WSDM design models is called the WSDM Ontology1. In the remainder of this section, an overview of WSDM is given, and the OWL concepts that describe the relevant design models are informally described.
Figure 1 shows an overview of the different phases of WSDM, and the relevant design models constructed in each design phase.
In the first phase of WSDM, the mission statement for the website is formulated. The intention of this phase is to identify the subject of the website, the purpose and the target users. The mission statement is formulated in natural language. In the WSDM Ontology, the ‘mission statement’ is an OWL concept with a textual data property.
In the Audience Modeling phase, the targeted users, identified in the mission statement, are classified in so called audience classes. An audience class is a group of visitors that have the same information and functional requirements. Audience classes can be subclassed: an audience class that has the same and more requirements than another audience class is called an audience subclass. Also during audience modeling, for each audience class, their characteristics and usability requirements are expressed.
In the WSDM Ontology, OWL concepts for ‘requirement’ and ‘characteristic’ are described. Requirement is subclassed into ‘Usability-‘, ‘Information-’ and ‘Functional-’ requirements. Finally, the ‘Audience Class’ concept describes the WSDM audience classes. Each ‘Audience Class’ has as object properties ‘hasRequirement’ and ‘hasCharacteristic’, and can be subclassed. The model representing the audience 1 See http://wise.vub.ac.be/ontologies/WSDMOntology.owl class hierarchy as well as for each audience class their characteristics and their set of (informal specified) requirements is called the audience model.
The conceptual design phase is used to specify the content, functionality and structure of the website at a conceptual level. The conceptual design makes an abstraction from any implementation or target platform. The content and functionality are defined during the Task Modeling phase; the navigational structure is defined during the Navigational Design.
The purpose of the Task Modeling phase is to analyze in detail the different tasks
each audience class needs to be able to perform, and to formally describe the
data/functionality that is needed for those tasks. The tasks each audience class needs
to be able to perform are based on the requirements formulated for each audience
class (during audience modeling). WSDM uses a slightly modified version of CTT
[
The goal of the Navigational Design is to define the conceptual structure of the website and to model how the members of the different audience classes can navigate through the website and perform their tasks. For each audience class, a dedicated navigation structure, called navigation track, is defined. A navigation track can be considered as a sub site containing all and only the information and functionality needed by the members of the associated audience class. Such a navigation track is further composed of nodes (conceptual units of navigation) and links (connecting nodes).
In the WSDM Ontology, the Navigation Model is represented by the OWL
concepts ‘node’ and ‘link’. Nodes have one object property ‘hasChunk’ which identifies
the object chunks which are connected to the node. There are two subtypes of nodes:
‘RootNode’ and ‘ExternalNode’. Links have object properties ‘hasSource’ and
‘hasTarget’, identifying the two nodes that are linked. Furthermore, a link can have a
parameter (‘hasParameter’) identifying flow of information along links, and a
condition (‘hasCondition’) to restrain the appearance of the link. There are four subtypes
of ‘link’, one for each link type supported in WSDM: navigation aid, process logic,
semantic and structural link. For an in depth discussion of these link types, see [
During the implementation design phase, the conceptual design models are completed with information required for the actual implementation. The implementation design consists of three sub phases: the Site Structure Design, Presentation Design and Data Source Mapping.
During Site Structure Design, the conceptual structure of the website (defined during navigational design) is mapped onto pages, i.e. it is decided which nodes (with object chunks) and links defined in the navigational model will be grouped onto web pages. Different site structures can be defined, targeting different devices, contexts or platforms. The output of this phase is the site structure model.
In the WSDM ontology, ‘pages’ are OWL concepts which have one object property ‘hasNode’ to denote the nodes that are contained in that particular page.
The Presentation Design defines the look and feel of the website as well as the layout of the pages (i.e. positioning of page elements). First, the sub phase Style & Template Design, aims at designing page templates. Typically, a website may require different kinds of templates, e.g. a homepage template, a title-page template, leaf page templates, etc. Furthermore, the style of page elements (e.g. font, color, alignment, etc.) is also specified. Next, the sub phase Page Design aims at describing how the information/functionality (modeled by the object chunks and represented by means of nodes) assigned to a page should be presented. Also link labels are decided, and presentation styles are given to the (different) links. The layout of a page is based on one of the templates defined during the Style & Template Design. This is done for each page type. The output of this phase is the presentation model consisting of a set of templates and for each page defined in the site structure model, a page model.
The main concepts in the WSDM Ontology describing the presentation design are ‘TemplateConcepts’ (concepts related to modeling templates) and ‘PresentationConcepts’ (concepts related to modeling positioning of page objects). Style is currently not included in the WSDM Ontology; instead Cascading Stylesheets are used. Going into further detail on the WSDM presentation concepts is outside the scope of this paper, and left for a forthcoming publication.
Finally, the Data Source Mapping phase is discussed in the next section (see Data Source Mapping).
In this section, we describe how WSDM supports semantic annotations at the
conceptual level and explain the benefits of our approach. The approach extends our
previous work as described in [
As described in the overview of the WSDM method (see Section 2), Object Chunks are used to model the concepts and relations between these concepts necessary to fulfill a particular (elementary) requirement of the website. Object Chunks are represented using OWL. As each Object Chunk models only one specific requirement, they can be seen as tiny ontologies. All Object Chunks together cover the complete domain of the website.
The goal of our approach is to automatically generate a website which content is annotated with one or more domain ontologies. Details about the generation process are given in Section 4. In practice, three different cases may occur when designing a website. They are described below: 1. No appropriate domain ontology exists or is available. In this case, we incrementally build a new domain ontology as a result of the creation of the Object Chunks. This domain ontology covers the domain covered by the union of the Object Chunks, and therefore of the complete website. The Object Chunks can be seen as views on this new domain ontology. 2. One domain ontology exists that covers the complete domain of the website. The domain ontology is taken as basis for the conceptual design. The Object Chunks are defined as views on this domain ontology by selecting the appropriate concepts. 3. Multiple domain ontologies are needed to cover the domain of the website. To be able to define Object Chunks as views, we first have to align the different domain ontologies. This is done by defining a reference ontology and mappings between the domain ontologies and this reference ontology. The Object Chunks are then defined as views on this reference ontology.
Figure 3 shows an overview of the architecture covering all three cases. The
different domain ontologies used are aligned by defining mappings to a reference
ontology (called Domain Ontology Mappings). This reference ontology can also be used to
define additional concepts not present in the used domain ontologies. Note that in the
case of just one domain ontology, the sole purpose of the reference ontology is the
latter one. In the case where there is no domain ontology available, the reference
ontology plays the role of domain ontology that is incrementally constructed. The
second mapping, called Object Chunk Mappings, defines Object Chunks as views on
the reference ontology. This view mechanism is required because the
conceptualization as specified by a domain ontology may not always exactly suit the requirements
of the website. E.g. a domain ontology may specify that a person may have multiple
email addresses (general case), but the website may require that persons can only
enter exactly one email address (specific case). Both the Domain Ontology Mappings
and the Object Chunk Mappings are defined using MAFRA (MApping FRAmework
for Distributed Ontologies) [
We give a small example illustrating the different mappings. We use the (shorter) description logic syntax for the object chunks, reference ontology and domain ontologies. Also a shorthand notation is used for the mappings themselves instead of the XML syntax of MAFRA. A domain ontology 1 describing the university domain contains the following axioms: {Person m ∀name.String, Student m Person * ∀email.String} (a person and student have respectively as name and email address a string as value). A second domain ontology 2 describes social aspects of citizens and contains the following axioms: {Person m ∀hasName.String * ∀hasSSN.String} (a person has as name and social security number a string as value). To align the two domain ontologies, we construct a reference ontology containing the following statements: {Person m ∀name.String * ∀SSN.String, Student m Person * ∀email.String). The following Domain Ontology Mappings are defined to link the reference ontology and the domain ontologies (only showing the properties involved):
name SSN email
name email
hasName hasSSN
Assume that the website requires a further refinement of name into first name and surname. An Object Chunk would contain the following axiom: {Person m ∀firstName.String * ∀surname.String}. The following Object Chunk Mappings are defined:
firstName + surname
name
The advantages of defining mappings at the conceptual level compared to approaches defining mappings on an implementation level are manifold. We mention the most important ones below: 1. Implementation independent: annotations are done on a conceptual level, and can effortlessly be re-generated along with different implementations 2. Consistency of annotations: as the annotation process is performed on a conceptual level, the actual annotations (at instance level) are guaranteed to be consistent. 3. Both static and dynamic websites supported: the implementation generation process of WSDM (see Section 4) does not distinguish between static and dynamic websites; annotations are effortlessly generated for both types of websites
When defining the Object Chunk and the Domain Ontology Mappings we may need
to resolve possible conflicts between respectively the Object Chunks and the
reference ontology, and the domain ontologies and the reference ontology. The different
types of conflicts can be classified into the following categories:
• Structural heterogeneity problems. Different designers may have a different view
on the same domain. As ontologies are only an abstract view of a domain, this
means that a same domain can be structured differently by different designers. This
includes naming conflicts, datatype conflicts, granularity differences, ...
• Semantic heterogeneity problems. Two concepts with the same name can refer to
different real world objects in the domain (homonyms); and two concepts with
different names can refer to the same real world object (synonyms).
Due to space limitations, we cannot go into deeper detail on solving these conflicts.
Instead, we refer to [
When the implementation of the website is generated, the different web pages need to be filled out with actual data (as specified in the page design). The web designer may decide to use a data source (e.g. a relational database) to store this data. To be able to fill out these web pages correctly, a Data Source Mapping needs to be defined between the reference ontology and the data source. E.g. in the case of a relational database, the Data Source Mapping determines in which tables and columns instances are stored of which concepts of the reference ontology. Note that, as with Object Chunk Mappings and Domain Ontology Mappings, no one-to-one relation can be assumed. Consider as example a table ‘Person(ID, name, SSN, email, code)’ in a relational database storing name, SSN from persons and email address from students. The following mappings are defined (note the additional condition for email due to lack of built-in subtyping support in relational databases):
name SSN email
name SSN email WHERE code=’S’
To generate the actual implementation of a semantically annotated website, a transformation pipeline is used. This pipeline takes the object chunks, navigational model, site structure design, template design and page design as inputs. The transformations necessary to generate the implementation of the website consists of three steps (without the annotations). Figure 2 gives an overview. • Implementation Mapping (T1): the implementation platform is chosen (e.g.
XHTML2), and the integrated model derived by the previous transformations is partially transformed towards the chosen platform. References to data (i.e., references to object chunks) are not yet processed. • Data Source Mapping (T2): the references to statements in the object chunks are resolved and mapped to their data source. This results into executable queries using the appropriated querying formalism. This mapping can be performed fully automatically using the mapping from the reference ontology to the data source. • Query Execution (T3): finally, the queries are executed and the actual pages can be generated by inserting the actual data. When the query execution phase is performed offline, a static website is created but when it is performed at runtime, a dynamic site is the result.
To be able to also generate the semantic annotations, the transformation pipeline needs to be extended. For each query that is executed, we make the result of the query 2 See http://www.w3.org/TR/xhtml1/. explicit in terms of the associated Object Chunk. Next, an annotation is created between the data on the web page and the instantiated Object Chunk. Let us clarify this with an example. Imagine that a query asking for the surname of a person returns “Plessers” and “Casteleyn”. In the generated HTML code, we surround them with a span tag containing a unique ID: <span id=”7”>Plessers</span> <span id=”8”>Casteleyn</span>
Following the references to statements in object chunks that lead to the creation of the query executed (see T4), we instantiate the associated object chunk c: <Person rdf:ID=”001”>
<surname>Plessers</name> </Person> <Person rdf:ID=”002”>
<surname>Casteleyn</name> </Person>
Finally, we link the generated HTML code and object chunk instantiations together (semantic annotations) using XPointer expressions. Consider the following example where ‘page.html’ is the generated HTML page and ‘c’ refers to the name of the object chunk:
page.html#xpointer(id("7")) <=> c#xpointer(id("001")/surname)
When reviewing the literature concerning semantic annotations, we can distinguish
three different, basic approaches: manual, (semi-)automatic and web engineering
approaches. The difference between manual and automatic approaches consists of the
fact that the former ones require a (manual) mapping between content and semantics,
while the latter attempt to extract the semantics automatically (e.g. with NLP
techniques). Examples of automatic approaches include Melita [
Manual annotation approaches offer the user tool support to define annotations for
HTML documents. The first tool was the SHOE Knowledge Annotator [
Both manual and automatic approaches suffer some disadvantages that can be
solved by integrating the annotation process into a web engineering method. The
adequacy of automatically generated annotations is generally lower compared to
manual approaches, the disadvantage of manual approaches however is that the
annotations are defined on an implementation level (making them more vulnerable for
changes) and require a substantial effort from the designer after the website is already
implemented. Recently, research has therefore been focused on integrating semantic
web technology into web design methods. Examples of semantic web design methods
include SHDM [
As far as the authors are aware of, the only similar approach to the one described
in this paper, is WEESA [
In this paper, we described how the website design method WSDM has been adapted to suit the needs of the semantic web. The most important changes are the use of semantic web technology (i.e. OWL) to formally describe (the semantics of) the different WSDM design methods, and to model the available data and functionality of the website. We informally described the WSDM Ontology, and subsequently showed how the use of OWL to model information and functionality during the design process can be exploited to (semi-) automatically generate semantic annotations for the resulting website.
Our approach takes into account the different cases where 1) no existing domain ontology is available, 2) an existing domain ontology is used, and 3) multiple existing domain ontologies are used. In the latter case, we pointed out possible conflicts, and indicated how to solve them. In any of those cases, the modeling effort of the web designer is effectively re-used to generate semantic annotations. Furthermore, the following advantages over existing annotation methods can be pointed out: implementation independence, consistency of generated annotations and support for both static and dynamic websites.
To conclude this paper, we proposed an approach that bridges WSDM, a classical website design method and the semantic annotation process to generate annotated websites for the Semantic Web. The annotation process has become an intrinsic part of web design. 3 See http://www.w3.org/TR/rdf-pics