A
JOP – Job Offer Portal
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
SCRUD
Search Create Retrieve Update Delete – operations for
realization of search, creation, editing and persistent store of
data instances
Cocoon
Framework
for
web
(http://cocoon.apache.org/)
Coplet
Cocoon portlet
application
development
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.
Presentation
Presentation Tool A
Form Presentation
SCRUD Support
Presentation Tool B
...
Domain Model Tools
User Modeling Tools
User Model Acquision
Form Generator
Domain Entity Acquision
User Model Analysis
Bean Generator
Search Tool
Ontology-Object Mapper
User Action Logging
...
...
MVC Based Framework
Common Configuration
User Management
Security
Portlet Management
Corporate Memory
Domain Ontologies
Domain Knowledge Bases
User Ontology
User Profiles
Event Ontology
User Action Logs
Fig. 1 Overview of the portal architecture.
Corporate memory
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.
MVC based framework
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.
SCRUD support
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.
Domain model tools
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.
User modeling tools
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.
Presentation tools
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).
Form generation and object ontology mapping for SCRUD support
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.
Ontology
class definitions
jo:offers*
jo:isBasedAt
c:ProfessionClassification
Form
generation
r:Region
jo:hasBenefit*
jo:hasSalary
jo:JobOffer
Bean generation
jo:offersPosition
jo:hasPrerequisite*
jo:Salary
jo:Benefit
jo:Benefit
jo:hasBenefit*
T-BOX
jo:hasSalary
restrictions
jo:mediates*
r:Region
r:Region
jo:isOfferedBy
jo:Organization
r:Region
jo:Organization
jo:isBasedAt
jo:hasDutyLocation*
jo:isBasedAt
jo:isBasedAt
JobOffer
Salary
r:Region
r:Region
jo:isBasedAt
r:Region
-ID : string
-type : string
-isOfferedBy : Organization
-hasSalary : Salary
-name : string
+getID()
+setID()
+getIsOfferedBy()
+setIsOfferedBy()
+getHasSalary()
+setHasSalary()
Organization
-ID : string
-type : string
-minAmount : float
+geID()
+setID()
+getMinAmount()
+setMinAmount()
* 1
-ID : string
-type : string
-hasContactInfo : ContactInfo
+getID()
+setID()
+getHasContactInformation()
+setHasContactInformation()
*
1
1
jo:Benefit
A-BOX
instances
*
r:Region
jo:Benefit
JobOffer
ContactInfo
-ID : string
-type : string
-email : string
-fax : string
+getID()
+setID()
+getEmail()
+setEmail()
+getFax()
+setFax()
Organization
-ID : string
-type : string
-hasContactInfo : ContactInfo
+getID()
+setID()
+getHasContactInformation()
+setHasContactInformation()
Salary
-ID : string
-type : string
-minAmount : float
+geID()
+setID()
+getMinAmount()
+setMinAmount()
binding
Organization
1
Class Model
-ID : string
-type : string
-isOfferedBy : Organization
-hasSalary : Salary
-name : string
+getID()
+setID()
+getIsOfferedBy()
+setIsOfferedBy()
+getHasSalary()
+setHasSalary()
*
-ID : string
-type : string
-hasContactInfo : ContactInfo
+getID()
+setID()
+getHasContactInformation()
+setHasContactInformation()
<?xml <fb:oninsert-row>
<fb:insert-bean
addmethod="add
HasBenefits"/>
</fb:on-insert-
ContactInfo
-ID : string
-type : string
-email : string
-fax : string
+getID()
+setID()
+getEmail()
+setEmail()
+getFax()
+setFax()
Salary
-ID : string
-type : string
-minAmount : float
+geID()
+setID()
+getMinAmount()
+setMinAmount()
template
<?xml
version="1.0"
olspan="2"
align="right">
<ft:widget
</td>
model
<?xml
version="1.0"
encoding="UTF<fd:javascript>
var success
</fd:validation>
Form description
1
*
Application runtime
instantiation
load()
jobOfferObject : JobOffer
ID : string = jo:jobOffer_0123
type : string = jo:JobOffer
isOfferedBy : Organization = organizationObject
hasSalary : Salary = salaryObject
name : string = Java programmer
1
1
*
salaryObject : Salary
Instance
mapping
ID : string = jo:salary_5050
type : string = jo:Salary
minAmount : float = 1300
Objects
*
organizationObject : Organization
ID : string = jo:organization_3636
type : string = jo:Organization
hasContactInfo : ContactInfo = contactInfoObject
publishing
1
*
contactInfoObject : ContactInfo
update()
ID : string = jo:contactInfo_6134
type : string = jo:ContactInfo
email : string = bob@mail.com
fax : string = 421533633
binding
Server side
Client side
JOP
Per period:
Per
Per
Per
Per
Per
Region:
hour
daz
week
month
year
New York
Washington
Boston
Texas
Houston
Redmond
Fig. 2 Crud pattern support.
Zmizniiii!!!
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 [1].
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 [3].
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.
A.1.4 External Links and Publications
[1] 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.
[2] 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.
[3] 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.
[4] 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.
A.2.1 Dependencies
JOP uses:
 Apache Tomcat 5.5
 Cocoon 2.1.9
 Sesame 1.2.5
A.2.2 Installation
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
/tomcat/webapps/WEB-INF/lib/ directory.
directory
must
be
copied
into
3. Set
the
Sesame
repository
configuration
/tomcat/webapps/cocoon/portal/configuration/sesame.properties.
file
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.
A.2.3 Configuration
The sesame.properties file contains the following values:

repositoryURL

repositoryID

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 URL where the repository is running
− ID of 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:
<MappingRule>
<PropertyURI>http://nazou.fiit.stuba.sk/nazou/ontologies/v0.6.17/offe
r-job#hasContactInformation</PropertyURI>
<Multiple>false</Multiple>
<Type>object</Type>
<ProcessProperty>true</ProcessProperty>
</MappingRule>
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;
Creating a new job offer instance
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.
Editing an existing 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.
Java bean generation
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:
BeanGenerator (String configurationDirectory);

configurationDirectory:
o
destinationPath:
directory where the following attributes are defined:
the path to the directory into which the Java beans will be
generated
o
sesameConfigurationFile:
o
mappingRulesFile:
file which
configuration like defined in A.2.3.
contains
the
sesame
repository
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.
BeanGenerator (String repositoryID, String repositoryURL, String
userName, String userPassword, String destinationPath , String
mappingRulesFile);
The generation process is realized by calling the
parameters:
generator.generateBean();
generateBean
function without
Object-ontology mapping
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).
CRUDRealizer(String configDir);
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.
CRUDRealizer(String repositoryID, String repositoryURL, String userName,
String userPassword, String mappingRuleXmlFileName);
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:
CRUDRealizer realizer = new CRUDRealizer("joboffers",
"http://localhost:8080/sesame-1.2.5/", "user", "pass",
"MappingRules.xml");
ImplJobOffer208582597 bean = (ImplJobOffer208582597)
realizer.retrieve("http://nazou.fiit.stuba.sk/nazou/ontologies/v0.6.17/of
fer-job#JobOffer_d30c3804c8c819618a04c7b222bf9b95");
………………
………………
realizer.update(bean);
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
elements will be contained,
/portal/coplets
directory, where the tool’s
 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 copletdata element must be added to the xml file. An example:
<coplet-data id="AjaxJobOffer" name="standard">
<title>Job Offer form</title>
<coplet-base-data>CachingURICoplet</coplet-base-data>
<attribute>
<name>buffer</name>
<value xsi:type="java:java.lang.Boolean">true</value>
</attribute>
<attribute>
<name>handleParameters</name>
<value xsi:type="java:java.lang.Boolean">true</value>
</attribute>
<attribute>
<name>uri</name>
<value
xsi:type="java:java.lang.String">cocoon:/coplets/html/application</value>
</attribute>
<attribute>
<name>temporary:application-uri</name>
<value
xsi:type="java:java.lang.String">cocoon://portal/coplets/AjaxJobOffer/off
er.form</value>
</attribute>
</coplet-data>
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
following matcher element:
AjaxJobOffer
directory in the
<map:match pattern="*.form">
<map:call function="handleForm">
<map:parameter name="function" value="anyFormDisplay"/>
<map:parameter name="definitionURI"
value="forms/{1}_model.xml"/>
<map:parameter name="bindingURI"
value="bindings/{1}_bind_bean.xml"/>
<map:parameter name="renderMode" value="{1}"/>
<map:parameter name="contextPath"
value="{request:contextPath}"/>
</map:call>
</map:match>
The coplets are placed into several tabs. Their placement is defined in the:

/portal/profiles/copletinstancedata/portal.xml

/portal/profiles/copletinstancedata/portal-user-anonymous.xml
and
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:
<coplet-instance-data id="AjaxJobOffer-1" name="standard">
<coplet-data>AjaxJobOffer</coplet-data>
</coplet-instance-data>
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
SCRUD support
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.
A.4.2 Dependencies
There are no dependencies.