A.1 Basic Information
The main task of a Job offer portal (JOP) is to provide an environment for experimentation and evaluation of different methods for searching and presentation of information is accomplished and user interaction is required. JOP is an environment where the users can:
§ create and edit job offers using user friendly form,
§ browse the information space of job offers using integrated searching and presentation tools.
Other functionality includes the user management and personalization. The main focus during the development was on:
§ creation of a generic and reusable,
§ extensible solution,
§ support for user model building and adaptation.
The intention was not only to create a specific environment bounded to a concrete domain and tools. We wanted to be able to quickly rebuilt the portal and adjust it to new situations. We have realized that one important problem is the change of the data model. We use ontologies for conceptualization and description of the domain. So we needed to be able to quickly react to the changes of the ontology, what includes both, the change of the version and also the whole exchange of the ontology.
Since JOP is used for experimentation with different tools and configurations of these tools, we needed to be able to easily extend the portal with new tools. This is achieved by modularity. Each tool stands as a separated component which can be easily added or removed. Hence, portal stands as an integration and presentation platform.
The portal has four types of user:
§ Unregistered: can only browse the job offers.
§ Registered user – company: can add new and edit own job offers.
§ Registered user – applicant: can browse the job offers and a portal is adapting to him.
§ Administrator: access to any part and use any functionality of the portal.
JOP is based on the portal framework of Cocoon. Cocoon is a publication framework for web applications based on MVC and pipeline pattern, implemented in Java. This document does not contain enough information to understand each aspect of the development of JOP. Due this, the knowledge of the Cocoon portal framework is recommended (http://cocoon.apache.org/).
A.1.1 Basic Terms
Search Create Retrieve Update Delete – operations for realization of search, creation, editing and persistent store of data instances
Framework for web application development (http://cocoon.apache.org/)
A.1.2 Method Description
To satisfy the requirements of reusability and extensibility we have created a portal based on the architecture shown in Fig. 1.
Fig. 1 Overview of the portal architecture.
We store data in the Corporate Memory repository which stores the domain, user and event ontologies (Fig. 1, bottom). We use domain ontology to capture and formally specify domain specific data - concepts, structures, relations, behavior and constraints characteristic for a particular application domain. User ontology is derived from the domain ontology to define users, their respective characteristics as well as their preferences towards specific domain concepts. We employ event ontology to capture the semantics of user actions during system operation for their successive processing in the user modeling process.
For the support of the usual functionality included in portal solutions we exploit existing MVC framework. We use the Cocoon development framework built around the concepts of separation of concerns and component-based web development. Cocoon implements these concepts around the notion of “component pipelines”, each component on the pipeline specializing on a particular operation.
A significant contribution of our design is the method for automatic form building realized by the SCRUD component. It supports the automated SCRUD (Fig. 1, top left) as means of improving reusability for different application domains and change resistance. SCRUD in particular includes the automatic generation of form descriptions for Cocoon (Form Generator), the generation of the underlying JavaBeans (Bean Generator) and the associated mapping and persistence of JavaBeans (Ontology-Object Mapper) in the ontological repository.
The portal integrates different tools tailored or reconfigured to use in the particular domain, Job Offer in our case. These tools offer the functionality to realize tasks required in the domain.
We employ a personalized presentation layer architecture. This layer is assigned to tool integrated into JOP. These facilitate User Characteristic Acquisition - a two stage process consisting of sever-side and client-side User Action Logging and User Modeling.
The portal is used to aggregate output from individual adaptive Presentation tools which support user adaptation based on the acquired user characteristics and assist in the creation of comprehensive user action logs. In particular, we utilize Form Presentation tools that take advantage of SCRUD pattern support to provide users with personalized form filling functionality for specific domain concepts. We employ several advanced search tools based on faceted browsing (Factic), cluster navigation (Cluster Navigator) and tools that allow the user to specify different search criteria and ranking algorithms (Criteria Search).
One of the main functionality of JOP is to provide an interface for editing and persistent store of the data entities of the domain in the ontology performed by the SCRUD support component. The use of these components is depicted in Fig. 2. First, the form builder is utilized to create the appropriate forms based on the ontology. These forms are displayed to the user who can then fill the information about the corresponding entity which is modeled by the ontology. Using the binding framework offered by Cocoon, the filled information are stored into Java beans generated automatically using the bean generation component. Finally, the object-ontology mapper is employed to transform the Java beans to ontological representation and store it in the ontological repository. The inverse transformation, from ontological representation to Java bean, is used when one already stored entity has to be shown to the user in forms who can change some attributes and resubmit the form.
Fig. 2 Crud pattern support.
The automatic form generation from ontology builds the forms which are used to fill the attributes of an ontological instance. It is based on searching ontological patterns in the structure of the domain ontology (entity description). We identified ontological patterns as repeating structures (sets of concepts and their relations) in ontological representations and defined consecutive data and processing around these patterns. Our method is based on the assumption that similar patterns are shared between ontologies with the patterns themselves being defined using different types of ontological concepts - classes, relations between them, properties, instances and restrictions. For each identified pattern we define the corresponding form widget. Since the domain ontology does not contain enough information to be able to build a user friendly interface we store additional form specific information in the Forms specific ontology. It contains for example information about the order of the form widgets and pre-defined values of some properties .
The basic idea of the ontology to objects mapping is to create a set of classes in such a way that each ontological class has its equivalent in a class of selected object-oriented programming language (the use of interfaces can be necessary when the language does not support multiple inheritance). The creation of such classes can be performed automatically, i.e. the interfaces and classes can be generated. Classes aggregate other classes which correspond to object-type properties of ontological classes. Data-type properties of an ontological class have their corresponding attributes in a programmed class. An instance of the ontological class is then mapped to an instance of the corresponding programmed class (the object of that class). An object-ontology mapper is then similar to an object-relational mapper. It performs the transformation of the instances of the ontological classes into objects and vice versa, i.e. fills up the values of the corresponding properties.
Similarly to object relational mapping, also object ontology mapping deals with a problem of decision, when to stop the loading process when ontology to object transformation is performed. The problem is that the process can result in loading of a huge part of the ontology, because the instance RDF graph being transformed can be indirectly connected to the whole RDF graph of the ontology. We solved this problem using meta-data that describe which object properties need to be transformed into objects and which not. This allows explicit specification of the boundaries of the RDF graph. To more information about the the object ontology mapping, see .
A.1.3 Scenarios of Use
JOP can be used in the following scenarios:
§ Active job offer producer wants to create or edit some offer.
§ User wants to search a job offer utilizing different searching and presentation methods.
 M. Barla, P. Bartalos, P. Sivák, K. Szobi, M. Tvarožek, and R. Filkorn. Ontology as an Information Base for Domain Oriented Portal Solutions. In 15th Int. Conf. on Information Systems Development, ISD’06, 2006.
 M. Barla, P. Bartalos, M. Bieliková, R. Filkorn, and M. Tvarožek. Adaptive portal framework for Semantic Web applications. In Second International Workshop on Adaptation and Evolution in Web Systems Engineering, 2007.
 P. Bartalos and M. Bieliková. An approach to object-ontology mapping. In 2nd IFIP Central and East European Conference on Software Engineering Techniques CEE-SET 2007, 2007.
 The Apache Cocoon Project. (http://cocoon.apache.org/)
A.2 Integration Manual
JOP is developed using the Cocoon portal framework. It is a stand-alone application into which other components are integrated.
§ Apache Tomcat 5.5
§ Cocoon 2.1.9
§ Sesame 1.2.5
Deploying JOP has the following prerequisites:
§ Apache Cocoon must be installed on the Apache Tomcat application server (it is recommended to don’t have a space character in the path),
§ a Sesame ontological repository must be available.
In the next we will assume that Tomcat is running in the /tomcat5.5/ directory and the Cocoon is installed into /tomcat5.5/webapps/cocoon/ directory. The installation of the core portal has the following steps:
1. The portal directory must be copied into /tomcat/webapps/cocoon/.
2. Java archive files from the jars directory must be copied into /tomcat/webapps/WEB-INF/lib/ directory.
3. Set the Sesame repository configuration file /tomcat/webapps/cocoon/portal/configuration/sesame.properties.
4. Tomcat must be restarted.
After these steps, portal should be accessible on http://localhost:8080/cocoon/portal (if the Tomcat runs on port 8080). To deploy tools in the portal, see installation manual of these tools.
The sesame.properties file contains the following values:
§ repositoryURL − the URL where the repository is running
§ repositoryID − ID of the repository
§ username − the name of the user which is used to access the repository
§ password − the password of the user which is used to access the repository
The metadata file for the object ontology mapper is an xml file which includes rules for the mapping. Each ontological property is related with one rule described in one entry of the xml file. An example entry for the jo:hasContactInformation property:
The PropertyURI, Multiple, Type tags are set during the bean generation process to the right value. They do not have to be changed. The ProcessProperty tag defines if the property has to be processed during the mapping, i.e. defines the boundary of the instance’s RDF graph to be processed. This tag has to be set before the mapper is used (by default the values are set to false). When set to true, the subproperties of the currently mapped property will be processed too. In the case of the jo:hasContactInformation property of the jo:Organization ontological class, the true value will cause that also the properties of the jo:ContactInformation ontological class (range of the jo:hasContactInformation property) will be processed too when organization will be mapped. More precisely, the contact information object aggregated in the organization object will have set the values of the jo:web, jo:fax and the other properties of the class. If the ProcessProperty tag for the jo:hasContactInformation property is set to false, these properties will be null and the contact information object will have set only the ID (which contains the URI of the jo:ContactInformation ontological class instance).
A.2.4 User Guide
The JOP can be used in these ways:
§ To create a new job offer instance;
§ To edit an existing job offer instance;
Following notes should be useful when using JOP:
§ The back button of the browser may not function as expected (this is due the Cocoon framework event processing mechanism);
§ The client machine must have installed Java runtime environment;
§ The browser used to work with portal must have allowed java script;
A new job offer instance is creating using the form in the portal (see Fig. 3). The user fills the attributes and then submits the form. JOP stores then the new job offer instance in the ontological repository.
Fig. 3 Form for editing a job offer instance.
If a user wants to edit an existing job offer instance, he can find it using Factic tool and choose the edit button. Then he can change the required attributes and submit the form. The changes will be automatically stored in the ontological repository.
The Java bean generator can be found in the sk.fiit.beanGenerator package. The class which performs the generation is the BeanGenerator class. It has to constructors distinct in only the sesame repository configuration. In the first case the constructor has one parameter:
§ configurationDirectory: directory where the following attributes are defined:
o destinationPath: the path to the directory into which the Java beans will be generated
o sesameConfigurationFile: file which contains the sesame repository configuration like defined in A.2.3.
o mappingRulesFile: file where the mapping rules will be generated.
In the second case, the constructor has six parameters. Here the sesame configuration is included in the parameters. Their meaning is obvious from names.
The generation process is realized by calling the generateBean function without parameters:
The object-ontology mapper can be found in the sk.fiit.ontologyRetrieveUpdate.CRUDRealizer package. To map between objects and ontological instances a CRUDRealizer object must be created. Two constructors are available.
First, with one parameter which is the path to the configuration files where the repository configuration file and the mapping rule file is available (the name of the mapping rule file must be MappingRules.xml).
Second constructor has five parameters. The first four are the repository configuration attributes. The last attribute mappingRuleXmlFileName is the name (including path) of the file with mapping rules.
Using the CRUDRealizer object, one can load instances stored in the Sesame ontological repository to objects and store the object with filled attribute to the repository. The load operation is performed using the retrieve method with. Its attribute is the ID of the instance to be loaded. The store of the object is realized using update method. In this case, the attribute is the Java bean to be stored. A code example:
A.3 Developer Manual
A.3.1 Tool Structure
JOP consists from:
§ Directory portal containing the portal files for Cocoon;
§ Several Java archive files containing
o Cocoon portal extensions (sk.fiit.nazou.jop.*);
o Java bean generator, object-ontology mapper and form generator (sk.fiit.*);
The portal directory contains all the necessary files containing the description of the portal structure, view, forms, and integrated tools. These are then used by Cocoon framework to run the application. In the following, we will concentrate on the main and most important issues which are defined in the portal directory. For deeper understanding the Cocoon documentation must be used (http://cocoon.apache.org/2.1/). We will focus on elements which are needed to be known when the portal is extended and new tools are integrated into it. In the next, we will introduce some common principles which should be kept when new tool is integrated. The specifics of the integration should be described in the integrated tool’s documentation.
When new tool has to be added into the portal it is recommended to:
§ define a new coplet for it,
§ create a separated directory in the /portal/coplets directory, where the tool’s elements will be contained,
§ create a sitemap in the tool’s directory and a element which will match the URI of the tool.
The coplets the portal consists of are defined in:
§ /portal/profiles/copletdata/portal.xml: When new coplet is defined an coplet-data element must be added to the xml file. An example:
The most important attribute here is the temporary:application-uri. It defines what will be shown in the coplet. The value of this attribute is an URI which will be matched in the sitemaps. Hence it can be necessary to create it when not an existing is used. In the example above, the sitemaps in the cocoon, portal, coplets directories are used one after another to match the URL. These three are configured to only redirect this request, which will be finally matched in the sitemap in the AjaxJobOffer directory in the following matcher element:
The coplets are placed into several tabs. Their placement is defined in the:
§ /portal/profiles/copletinstancedata/portal.xml and
§ /portal/profiles/copletinstancedata/portal-user-anonymous.xml files.
The portal.xml file defines the tabs the user will see when he is logged in the portal. The portal-user-anonymous.xml file defines the part of the portal which is accessible also for non registered users. Both include entries which determine the coplets available in the portal. An example:
Sometime it can be helpful to control the flow of the application. This can be done using the Cocoon flowscript. Methods in Java script can be placed here which can be called from the sitemap (for example the anyFormDisplay method is called when a request which matches the "*.form" in the sitemap above). A user can use here own Java classes. Note that the Java archive file of these classes must be placed in the /cocoon/WEB-INF/lib directory.
A.3.2 Method Implementation
The implementation of the SCRUD support component our portal consists of the form generation mechanism and object ontology mapper with Java bean generation. Both these components are written in Java programming language version 5.
The Java bean generator can be found in the sk.fiit.beanGenerator package.
A.3.3 Enhancements and Optimizing
The portal actually works with ontological data stored in the Sesame repository. It can be extended to support also other repositories. To do this, two classes needs to be created.
First, a class which stands as an interface to the new repository must be created. It must extend the OntologyInterface interface and implement the uploadGraph, getInstanceGraph, deleteInstanceGraph methods.
Second, a class which implements the OntologyExaminer interface must be created. It must extend the createOntologyClass, getSubClasses, getSuperClasses, getProperties, getDirectType, and getAllClasses methods.
A.4 Manual for Adaptation to Other Domains
The JOP was created for experimentation and evaluation of different methods for searching and presenting information. There is a strong focus on reusability in other domains. The change of the domain must be seen from two aspects.
First, we can talk about how the change touches the core of the portal which includes the basic functionality offered by the Cocoon and the SCRUD support. The Cocoon part is independent of the domain used. The SCRUD support component is fairly good adjustable to other domains. It can be performed in (semi) automatic way. The only thing what is needed to be created manually is the FSI ontology for the corresponding domain and entities in it. After it, the whole form generation is performed automatically. The Java bean generator works with any OWL ontology (notice that there are some limitations in elements of OWL that are covered but they do not depend on the domain). The same situation is with the object-ontology mapper.
The second aspect of the domain change is related with the tools included in the portal. Their adaptation to the new domain is independent of the portal. The tools can be removed, reconfigured to the new domain and also new ones can be added.
A.4.1 Configuring to Other Domain
The change of the domain may require the change of the ontological repository. This is related with the change of the repository configuration file discussed in section Configuration. To configure tools included in the portal see documentation of the corresponding tool.
There are no dependencies.