Semantic Data Access and Persistence Components

engineerbeetsAI and Robotics

Nov 15, 2013 (3 years and 9 months ago)

234 views





















Semantic Data Access

and Persistence




Components

www.iks
-
project.eu

Interactive Knowledge Stack for Semantic

Content Management Systems

Deliverable
:
5.4 Intermediate Report


p敭慮ti挠aat愠䅣捥a猠慮d m敲獩et敮捥⁃cmp

湥湴猠

Delivery Date:
June

2010

Author(s):
Gokce B. Laleci,
Ozgur Kilic, Cihan Cimen,

Filename:
iks_d54_Se
manticPersistenceComponents_V0.5
.docx

Publication Level:
Restricted

Web link
:
http://www.iks
-
project.eu/iks
-
story/documentation

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





2

/

63

Table of Content
s


Document History

................................
................................
................................
................

4

Document

Information

................................
................................
................................
.........

4

IKS in a Nutshell

................................
................................
................................
...................

5

1

Introduction

................................
................................
................................
.................

5

2

Persistence Store (Backend Knowledge
-
base)

................................
.........................

5

2.1

Overview

................................
................................
................................
..............

5

2.2

Related Requirements

................................
................................
..........................

7

2.3

Interfaces

................................
................................
................................
.............

9

2.4

Setting up Persistence Store within the FISE Framework

................................
...

10

3

Ontology Generator

................................
................................
................................
..

13

3.1

Overview

................................
................................
................................
............

13

3.2

Related Requirements

................................
................................
........................

15

3.3

Interfaces

................................
................................
................................
...........

16

3.4

Setting up Ontology Generator

................................
................................
...........

24

4

Search Component

................................
................................
................................
...

25

4.1

Overview

................................
................................
................................
............

25

4.2

Related Requirements

................................
................................
........................

27

4.3

Interfaces

................................
................................
................................
...........

28

4.4

Setting up Search Component

................................
................................
...........

31

5

Appendix

................................
................................
................................
....................

34

5.1

Persistence

Store WADL

................................
................................
....................

34

This document contains material, which is the
copyright of certain IKS consort
i-
um parties, and may not be reproduced or copied without permission. The
commercial use of any information contained in this document may require a
license from the proprietor of that information. Neither the IKS consortium
as a
whole, nor a certain party of the IKS consortium warrant that the information
contained in this document is capable of use, nor that use of the information is
free from risk, and accepts no liability for loss or damage suffered by any pe
r-
son using thi
s information.


Neither the European Commission, nor any person acting on behalf of the
Commission, is responsible for any use which might be made of the information
in this document.


The views expressed in this document are those of the authors and do
not ne
c-
essarily reflect the policies of the European Commission.

IKS is co
-
funded by the European
Union and develops technology for
intelligent content management

Notice


Copyright


© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





3

/

63

5.2

XML Schema used in Persistence Store WADL

................................
.................

41

5.3

Ontology Generator WADL
................................
................................
.................

46

5.4

XML Schema used in Ontology Generator WADL

................................
..............

53

5.5

List.xml for Deploying Persistence Store on FISE

................................
..............

57




© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





4

/

63

Document History

Version

Name

Date

Remark

V
0.2

Gokce B. Laleci,


Ozgur Kilic,
Cihan Cimen

2010
-
0
7
-
30

Initial version

V0.5

Suat Gonul, Senan Postaci

2010
-
0
9
-
23

Functional requirements mapping added

Document

Information

Item

Value

Identifier


Author(s):

Gokce B. Laleci,
Ozgur Kilic
,
Cihan Cimen
, Suat Gonul, Senan Postaci

Document title:

IKS
Intermediate
Report



5
.
4
:
Semantic Data Access and Persistence

Requirements and Specification

Source Filename:

iks_d54_Se
manticPersistenceComponents_V0.5
.docx

Actual Distribution level

Restricted

Document context information

Project (Title/Number)

Interactive Knowledge FP7 231527

Work package / Task

WP
5

/ T
5
.
4

Responsible person and pr
o-
ject partner:

Ozgur Kilic
,
Software Research,

Development and Consultancy, Turkey

Quality Assurance / Review

Name / QA / Release / Co
m-
ment


Citation information

Official citation


© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





5

/

63

IKS in a Nutshell

“Interactive Knowledge Stack” (IKS) is an integrating project targeting small to medium
Content Management Systems (CMS) providers in Europe providing technology platforms for
content and knowledge management to thousands of end user organizations. Current

CMS
technology platforms lack the capability for semantic web enabled, intelligent content, and
therefore lack the capacity for users to interact with the content at the user’s knowledge level.
The objective of IKS therefore, is to bring semantic capabili
ties to current CMS frameworks.
IKS puts forward the “Semantic CMS Technology Stack” which merges the advances in
semantic web infrastructure and services with CMS industry needs of coherent architectures
that fit into existing technology landscapes. IKS w
ill provide the specifications and at least
one Open Source Reference Implementation of the full IKS Stack. To validate the IKS Stack
prototype solutions for industrial use cases ranging from ambient intelligence infotainment,
project management and contro
lling to an online holiday booking system will be developed.


1

Introduction

IKS is an integrated project targeted at the hundreds of SMEs in Europe, which are providing
technology platforms for content and knowledge management to thousands of end user o
r-
ganisations. The IKS project will develop and demonstrate the use of semantically enhanced
CMS which allows new forms of interaction with knowledge rich content.


The aim of this report is
to give detail information about
the implemented components
of the

Semantic
Data Access and Persistence Layer of the IKS Stack.
Persistence Store
,

one of
the

components of the
Persistence Layer

is described in
Section
2
.
Main respo
nsibility of this
component is to provide storage and access points for the semantic data. Section
3

d
e-
scribes the Ontology Generator

component which creates bridge
s between the content r
e-
positories and the Persistence Store component. Ontology
G
enerator enables connecting
content repositories through
standard interfaces like
JCR and CMIS. Furthermore it provides
RESTful services to enable content repositories to
submit their content model.

Section 4 d
e-
scribes the semantic search component which is implemented on top of the persistence
store. It enables semantic search functionality over the ontology

generated by the Ontology
Generator component.


2

Persistence Sto
re (Backend Knowledge
-
base)

2.1

Overview

This component is responsible for providing storage and access points for semantic data a
s-
sociated with the content items of a CMS. During the requirements analysis phase of s
e-
mantic data access and persistence layer,
we have investigated various triple stores. In
general they provide same functionality like storing, retrieving and querying triples. However
,
they differ in reasoning and scalability capabilities. Furthermore
,

each may have different l
i-
censing requirement
s. Considering the pros and cons of different triple stores, we have d
e-
cided to provide a generic interface to communicate with triple stores, so that independent of
© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





6

/

63

the triple store hosted at the backend knowledge
-
base, the semantic
enhancement/
lifting
me
chanism
s

can feed and query
knowledge

hosted. We have
specified

REST
f
ul interfaces
to create/update/delete ontologies, classes, properties, individuals.
In the c
urrent
impleme
n-
tation

REST
f
ul services
can
be bound to Jena and Virtuoso triple stores

through
implemen
t-
ed adapters
. This generic knowledge
-
base interface also enables us to integrate other more
scalable triple stores that support reasoning for more expressive ontologies.





Figure
2
.
1

Persistence
Store Architecture


Figure
2
.
1

depicts the architecture of the Persistence Store component of the semantic data
access and persistence layer.
Clients can access the
Knowledge
-
base through the provided
RESTful interfaces. Stored ontologies can also be merged with

external

domain and horizo
n-
tal ontologies available in the Semantic Web

through ontology merging functionality provided
by the
Protégé

tool
.

As a result of

me
rging, we have much richer semantics to reason on and
hence to present

more expressive and comprehensive searching capability to CMS users.


Furthermore, Persistence Store is wrapped as an OSGI bundle and implements the store
and SPARQL interfaces defined
in FISE framework
1
. Persistence Store can be registered,
activated and deactivated within the FISE framework through the OSGI environment.

It is a
l-
so possible to use other Store implementations within the FISE framework by implementing
relevant interfaces
defined in the services API
2
.




1
Furtwangen IKS Semantic Engine,
http://wiki.iks
-
project.eu/index.php/FISE

2
http://iks
-
p
r
o-
ject.googlecode.com/svn/sandbox/fise/trunk/generic/servicesapi/src/main/java
/eu/iksproject
/fise/servicesapi/

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





7

/

63

2.2

Related Requirements

Functionality of the persistence store component is described through the following requir
e-
ments:




HLR 3403 Ontology Administration



HLR 3404 Support for Reasoning



HLR 3405 Support for Rule
-
based Inference



HLR 3406 Support for Querying Mechanisms



HLR 3407 Support for Indexing



HLR 3408 Support for Versioning



HLR 3409 Support for Semantic Lifting

Current functionality of the persistence store only covers some
of the
requirements defined
by HLR3403, HLR3404,
HLR 3406
and HLR 3409.
Table 1 gives
list functional requirements

addressed by the

persistence store component.



Table 1
-

Functional Requirements Addressed by Persistence Store


ID

Requirement

I
mplemented

FR
-
340301

The IKS Persistence Layer shall
support registering ontologies

Yes

FR
-
340302

The IKS Persistence Layer shall support deleting ontologies

Yes

FR
-
340303

The IKS Persistence Layer shall support merging ontologies

No

FR
-
340304

The IKS Persistence Layer shall support adding ontology elemen
ts

Yes

FR
-
340305

The IKS Persistence Layer shall support updating ontology elements

Yes

FR
-
340306

The IKS Persistence Layer shall support deleting ontology elements

Yes

FR
-
340307

The IKS Persistence Layer shall support defining merging rules

No

FR
-
340308

The IKS Persistence Layer shall detect conflicts during merging operation

No

FR
-
340401

The IKS Persistence Layer shall provide interfaces to attach reasoners

Yes

FR
-
340402

The IKS Persistence Layer shall execute reasoners on the stored
knowledge

Yes

FR
-
340403

The IKS Persistence Layer shall populate its knowledge with the inferred
instances

Yes

FR
-
340501

The IKS Persistence Layer shall be able to store submitted rules

No

FR
-
340502

The IKS Persistence Layer shall provide interfaces to attach rule engines

No

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





8

/

63

FR
-
340503

The IKS Persistence Layer shall support execution of rules on the stored
knowledge

No

FR
-
340601

The IKS Persistence Layer shall provide services to submit queries

Ye
s

FR
-
340602

The IKS Persistence Layer shall provide service descriptions to state which
query languages are supported by the knowledge store

No

FR
-
340701

The IKS Persistence Layer shall be able to create index for the specified
content

No

FR
-
340702

The
IKS Persistence Layer shall enable defining indexed paths

No

FR
-
340703

The IKS Persistence Layer shall provide interface to search over index

No

FR
-
340704

The IKS Persistence Layer shall support rules to reason over index

No

FR
-
340705

The IKS Persistenc
e Layer shall provide interfaces to define named querries

No

FR
-
340706

The IKS Persistence Layer shall provide interface to execute named
querries

No

FR
-
340707

The IKS Persistence Layer shall provide interface to perform faceted
search/navigation

No

FR
-
340801

The IKS Persistence Layer shall be able to query only latest versions of
contents

No

FR
-
340802

The IKS Persistence Layer shall be able to query only archived versions of
contents

No

FR
-
340803

The IKS Persistence Layer shall be able to query all

versions of contents

No

FR
-
340804

The IKS Persistence Layer shall be able to query over changes in between
versions

No

FR
-
340805

The IKS Persistence Layer shall create “version of” relation upon checkin
operation received from CMS

No

FR
-
340901

The IKS
Persistence Layer shall provide interfaces to add annotations about
a specified content

Yes

FR
-
340902

The IKS Persistence Layer shall provide interfaces to delete annotation of a
specified content

Yes

FR
-
340903

The IKS Persistence Layer shall provide int
erfaces to retrieve annotations of
a specified content

Yes





© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





9

/

63



2.3

Interfaces

Persistence Store provides two types of interfaces. As an OSGI bundle it implements the i
n-
terfaces specified in the FISE framework. Secondly, it has RESTful interfaces.

2.3.1

Interfaces
implemented

in the FISE Framework

FISE

specifies services APIs for defining the interactions between the server
-
side comp
o-
nents. So far following interfaces have been specified for accessing and storing semantic
enhancements:




Store



SparqlQueryEngine

Although “Store” interfaces enables persist
ing

the content itself
in addition to

the enhanc
e-
ments of the content, Persistence Store implementation stores only the enhancements as tr
i-
ples. The reason for not storing the original content is

to avoid duplicating it. The aim of the
persistence store
implementation
is to use it as a backend knowledge
-
base for existing
CMSs which will be able to store enhancements/annotations regarding the contents they
store.


FISE also specifies “SparqlQueryE
ngine” interface to perform SPARQL queries on the e
n-
hancements stored by the “Store” implementation. Persistence Store
implemetation

also i
m-
plements this interface.


In addition to the interfaces defined in services API, Persistence Store also implements t
he
following interfaces
located at
3

to enable ontology management and search functionalities
:





IPersistenceStore



ISearch

2.3.2

RESTful Interfaces

In addition to the

FISE interfaces, Persistence Store also provides RESTful interfaces to i
n-
teract with clients
outside the OSGI container. RESTful interface description in WADL is gi
v-
en in Appendix

5.1
. In summary, following resources
have been

described through Restful
in
terface:




Ontology



OntologyClass



OntologyIndividual




3
http://iks
-
pr
o-
ject.googlecode.com/svn/sandbox/fise/trunk/stores/persistencestore/persiste
ncestore/src/m
ain/java/eu/iksproject/fise/stores/persistencestore/

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





10

/

63



DatataypeProperty



ObjectProperty

Persistence Store enables manipulating an ontology and its elements through the described
RESTful interfaces. Furthermore, Persistence Store provides two additional RESTfu
l inte
r-
faces to allow clients to execute SPARQL queries on the triples stored in the Persistence
Store.

2.4

Setting up Persistence Store within the FISE
Framework

2.4.1

External Software Requirements

Following software needs to be installed prior to the set up of
the persistence store comp
o-
nent:



JDK 6



Maven 2.X



MySQL Server 5

2.4.2

Deploying Bundles


Three bundles should be installed on
FISE Framework
4
:



eu.iksproject
/
eu.iksproject.fise.stores.persistencestore



eu.iksproject
/
eu.iksproject.fise.stores.persistencestore
.jena



eu.iksproject
/
eu.iksproject.fise.stores.persistencestore
.jena.tdb



eu.iksproject
/
eu.iksproject.fise.stores.persistencestore.adapter



eu.iksproject/org.semanticweb.owlapi



eu.iksproject/org.semanticweb.owlapi.owllink

These bundles are available at
FISE
5

repository directory

as maven projects and can be buil
t

by following steps:

1.

Checkout project

2.

Go

to base directory of the project (Where the pom.xml file exists)

3.

Type “mvn clean install


DskipTests=true

in command line

provided there is an m
a-
ven
6

install
ation in the system

4.

To convert into eclipse project
type “mvn eclipse:eclipse”

then the required eclipse
project files will be generated.

Following dependencies are required to run these bundles:


Dependency




4
The runnable for FISE framework can be generated by building
IKS FISE Sling
-
based
standalone launcher

which can be found at
http://iks
-
project.googlecode.com/svn/sandbox/fise/trunk/launchers/sling

5
https://iks
-
project.googlecode.com/svn/sandbox/fise/trunk/stores/persistencestore


6
http://maven.apache.org/

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





11

/

63

javax.ws.rs jsr311
-
api 1.0

Provided by Clerezza

org.apache.commons commons
-
math 2.1

Can be found at :
http://repo1.maven.org/maven2/org/apache/c
ommons/commons
-
math/2.1/commons
-
math
-
2.1.jar

mysql
mysql
-
connector
-
java 5.1.12

Can be found at:
http://repo1.maven.org/maven2/mysql/m
ysql
-
connector
-
java/5.1.12/

mysql
-
connector
-
java
-
5.1.12.jar


edu.smu.tspell jaws 1.2

Embedded into jar

org.nsdl.mptstore mptsotre 0.9.1

Embedded into jar

com.hp.hpl.jena j
ena 2.6.3

Provided by Clerezza

com.hp.hpl.jena.arq 2.8.5

Provided by Clerezza

com.hp.hpl.jena.tdb 0.8.7

Provided by Clerezza

org.apache.clerezza.rdf.core 0.12
-
incubating
-
SNAPSHOT

Provided by Clerezza

org.apache.clerezza.rdf.simple.storage
0.7
-
incubating
-
SNAPSHOT

Provided by Clerezza

eu.iksproject.fise.servicesapi 0.9
-
SNAPSHOT

FISE Bundle

org.osgi.compendium 4.0.0

OSGI Bundle


There is a list.xml file provided in
Appendix
5.4

that shows all the required bundles for buil
d-
ing FISE with Persistenc
e Store deployed on it.
The file

{project fol
d-
er}
\
sandbox
\
fise
\
trunk
\
launchers
\
sling
\
src
\
main
\
bundles
\
list.xml


in bundle


IKS FISE Sling
-
based standalone launcher

should be replaced by the one in the Appendix
5.4

and then pr
o-
ject should be built with “
mvn clean install
”.

A jar file named

eu.iksproject.fise.launchers.sling
-
0.9
-
SNAPSHOT.jar


will
be
generated under directory

{project folder}
\
sandbox
\
f
ise
\
trunk
\
launchers
\
sling
\
target

.
This file can be
executed

by “java

jar
eu.iksproject.fise.launchers.sling
-
0.9
-
SNAPSHOT
”.

Then HTML interface of FISE can be used through
http://localhost:8080/
.


Restful Interfaces or Persistence Store can be accessed through
http://localhost:8080/persistencestore


2.4.3

Co
nfiguring Bundles

Persistence Store needs a database connection to
resource and ontology URIs
.

Configur
a-
tion for the database connection is done through the Apache Felix Web Console’s Configur
a-
tion Tab which can be accessed through
http://localhost:8080/system/console/configMgr

.
You sho
uld enter valid values for
fields in
the

configuration of the

bundle IKS FISE

Jena

Pe
r-
sistence Store:




eu.iksproject.fise.stores.persistencestore.dbuser.name
: Username used for a
u-
thentication when connecting to database
.



eu.iksproject.fise.stores.persistencestore.dbpassword.name
:
Password for the
username above
.



eu.iksproject.fise.stores.persistencestore.dbpassword.name
:
Url for the jdbc
connection in the following format : jdbc:
mysql
://{host}:{port}/{database_name}
.


For
the bundle IKS FISE Jena TDB Persistence Provider:

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





12

/

63



eu.iksproject.fise.stores.persistencestore.jena.tdb.datasetpath.name
:
Path to
the directory where
the triples will be stored.


If there is no JAX
-
RS Handler to register Restful Interface resources you can
do that by act
i-
vating the component
eu.iksproject.fise.stores.persistencestore.rest.ServletRegisterer

through Apache Felix Web Console’s Components Tab which can be accessed at
http://localhos
t:8080/system/console/components
.



In order to use these services you may need to add some
permission

to BasePermissinRole
(If you use the jar generated by FISE launcher this module will not be available) through
http://localhost:8080/admin/user
-
manager/manage
-
role
-
permissions?roleTitle=BasePermissionsRole




( java.net.SocketPermission "localhost:3306" "resolve, connect")



( java.util.PropertyPerm
ission "user.language" "write" )



( java.io.FilePermission "*" "read" )



( java.lang.RuntimePermission "accessDeclaredMembers")



( java.lang.reflect.ReflectPermission "suppressAccessChecks" )




Figure
2
.
2

Persistence Store Configuration

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





13

/

63

Also the demo package
7

includes a launcher in
/Launchers

which can be run to start an
Apache Felix Framework that contains all necessary bundles for running Persistence Store.


Persistence Store needs inferencing to accomp
lish some of its functionalities. This requires
integration with a reasoner. Therefore, another configuration element has been defined that
can be assigned through the Apache Felix Web Console is the reasoner URL as shown in
Figure
2
.
2
.




eu.iksproject.fise.stores.pe
rsistencestore
.
reasonerURL.name


Persistence store can be integrated with an OWLlink reasoner by assigning a valid URL to
the above property.

3

Ontology Gen
erator

3.1

Overview

The users of a content repository express the semantics they have in mind while defining the
content items and their properties, and forming them into a particular hierarchy. However,
this valuable semantics is not formally expressed, and
hence cannot be used to discover
meaningful relationships among the content items in an automated way. Although the need is
apparent, there are several challenges in explicating this semantics in a fully automated way:
first, it is difficult to distinguish

between data and the metadata in the repository and secon
d-
ly, not all the metadata defined, such as the file size or encoding type, contribute to the
meaning. More importantly, for the developed solution to have practical value, it must a
d-
dress the constr
aints of the Content Management System (CMS) industry: CMS industry
cannot change their repositories in production use and they need a generic solution not li
m-
ited to specific repository architecture.


The value of extracting the already available semantic
s in the content models as ontology is
apparent; however our challenge is to achieve this within the constraints of the CMS industry.
Our solution is to have a backend knowledge
-
base and then develop semantic bridges b
e-
tween content repositories and the kn
owledge
-
base where the content repository semantics
is maintained.


Equally important is to support a generic architecture that is not limited to a specific content
repository. Several different content repositories have been developed with different APIs
which do not interoperate. This problem is addressed through the Con
tent Repository API for
Java (JCR) and Content Management Interoperability Services (CMIS) which provide access
to otherwise incompatible content repositories in a standard way; JCR through a java API
and CMIS through Web Services and REST services. When a

semi automated ontology
generation mechanism is built on JCR and CMIS Interfaces, a good percentage of the CMS
market is covered. In addition to this, we have provided RESTful services that can be used
by content repositories that do not support JCR or CM
IS. Through RESTful services, the
available content model and the updates can be sent to the ontology generation mechanism
so that an ontological representation of the content repository semantics can be created.
This semi
-
automatic ontology generation mec
hanism can be thought as a Semantic Bridge
between a content repository and a knowledge
-
base storing the extracted semantics. The



7

Demo package location
-

http://
195.142.27.165
:8585/DemoSetup.rar

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





14

/

63

overall picture of the ontology generator integrated with the persistence store component is
shown
in
Figure
3
.
1
.




Figure
3
.
1

Ontology Generator integrated with the backend Knowledge
-
base



The content management industry are

eager to improve their business by using semantics,
yet they do not want to modify their already in use content repositories drastically. Therefore
the semantic annotation and reasoning must take place separately from their repository. We
have find out th
e need for semantic bridges in order to explicate the semantics of a content
repository supporting standard interfaces JCR and CMIS.



Figure
3
.
2

Generic Repository Content Model


Both JCR and CMIS define a
hierarchical repository model. JCR calls the building blocks as
nodes while CMIS calls them as objects. In each of them, repository items may have several
properties, which may be assigned data type values, or other repository items. A repository
item may
include other repository items as child objects. Apart from the repository items,
both JCR and CMIS have specific node type or object type definitions through which the r
e-
pository item definitions can be restricted, where the properties and child items the
y may
© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





15

/

63

have, can be restricted further. These types can be thought as template repository item def
i-
nitions.

Since our aim is to have a generic model that can be used by

any content repository,
we keep the common model as abstract as possible as

depicted in

Figure
3
.
2
.


After retrieving the object types and processing them according to the mapping rules, the o
n-
tology generation mechanism requires processing of these sema
ntic bridges, and the ont
o-
logical representation of the repository content model is enriched with the new axioms. We
have specified four types of semantic bridge constructs:




Concept

Bridge: This bridge allows the content administrator to annotate the
grap
h-
ically selected objects in the content repository as classification objects. As a result of
this bridge execution, an ontology class or an ontology

class hierarchy is created co
r-
responding the selected objects.



Subsumption

Bridge: This bridge allows
users to specify the properties in a content
repository that correspond to subsumption relationships in the ontology. A Subsum
p-
tion Bridge has two elements:

objectQuery


element is used to specify the objects as
“SuperClasses”, and the

predicateName


spe
cifies the property name that will be
used to select the “SubClasses” of these objects selected as “SuperClasses”. If a
Subsumption

Bridge is used within a Concept

Bridge, the subsumption relationship is
established automatically among the objects qualifie
d by the Concept

Bridge and
hence there is no need to define an

objectQuery

.



Property

Bridge: In order to selectively
extract

some of the content repository prope
r-
ties to the ontological representation being created, Property Bridge construct is
used. T
his is necessary, because not all of the properties defined for an object in the
content repository may have a semantic value; some of them can be syntactic attri
b-
utes such as the file size. Property Bridge helps to selectively
extract

the semantics of
pro
perties. Similar to Subsumption Bridge, the Property Bridge has two elements: the

object Query


element is used to specify the set of objects to which this Property

Bridge is applied to. The selected objects are set as the “domain” of the ontology
propert
y that is to be generated. The

predicateName


element gives the name of the
property in the content repository to be used to select the range of the ontology pro
p-
erty. Note that a property may refer to another object, or to a data value. If the prope
r-
ty i
s referring to another object, then an OWL “ObjectProperty”, else a
“DataTypeProperty” is created in the ontology. If the Property

Bridge is specified wit
h-
in a Concept

Bridge, then there is no need for an

objectQuery

; the selected ontolo
g-
ical properties
of all the objects qualified by the Concept

Bridge are established
automatically.



Instance

Bridge: This bridge is used to select the objects in the repository that are a
c-
tually used for storing content items, i.e. to select content objects. Each selected
o
b-
ject is created as an individual of the class created to represent its object type.

3.2

Related Requirements

Functionality of the
ontology generator

component is described through the following r
e-
quirement:



HLR 3401 Ontology Generation from the Content Model

in Content Repositories

Table
2

gives a list functional requirements addressed by the
ontology generator

component.

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





16

/

63




Table 2


Functional Requirements addressed by Ontology Generator

ID

Requirement

I
mplemented

FR
-
340101

The IKS Persistence Layer shall enable user to define ontology extraction
rules for converting CMS content model to Ontology constructs

Yes

FR
-
340102

The IKS Persistence Layer shall support extracting ontology concepts from
content types defined in the
repository

Yes

FR
-
340103

The IKS Persistence Layer shall support extracting ontology concepts from
taxonomies defined in the repository

Yes

FR
-
340104

The IKS Persistence Layer shall support extracting ontology instances from
content hierarchies residing
in the repository

Yes

FR
-
340105

The IKS shall be able to interact with CMS repositories through JCR
interface.

Yes

FR
-
340106

The IKS shall be able to interact with CMS repositories through CMIS
interface.

Yes

FR
-
340107

The IKS shall enable CMS
repositories to submit their content model.

Yes

FR
-
340108

The IKS shall enable CMS repositories to submit their content model
updates.

Yes

FR
-
340109

The IKS shall provide interfaces to browse content model of CMS
repositories .

Yes


3.3

Interfaces

Ontology
Generator provides graphical user interfaces for extracting ontologies from CMSs
through JCR and CMIS interfaces.
Since not all of the existing CMSs support standard inte
r-
faces like CMIS and JCR, Ontology Generator also provides
RESTful services

through wh
ich

the available content model and the updates can be sent to the ontology generation mech
a-
nism so that an ontological representation of the content repository semantics can be crea
t-
ed
.

3.3.1

Graphical User Interfaces

JCR/CMIS to Ontology
Bridge

is

the UI compo
nent
of
Ontolo
gy Generator. It enables user to
visually create bridges between the content repository and the knowledge base. Once the
tool is installed
into the local machine and started up,
JCR/CMIS to Ontology Bridge

can be
started using the following link:




http://localhost:8080/jcr2ont/JCRtoOntoBridgeGUI/JCRtoOntoBridgeGUI.html


© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





17

/

63



Figure
3
.
3

JCR/CMIS to Ontology Bridge



Figure
3
.
3

displays the page opened by the above
URL
. It prompts user to enter information
to connect to

the content repository.
Namely, the following information is requested from the
user:




Connection API:
Two connection methods which are JCR and CMIS can be selected.



URL: location of the repository



Workspace:
repository workspace



Username: used for conn
ecting to the repository



Password: used for connecting to the repository


Once the requested data is provided and user clicks the “Connect”

button,
JCR/CMIS to O
n-
tology Bridge

component connects to content repo
sitory through the selected interface using
the given
credentials
.

After

successful connection
to the repository
the
page

shown in
Figure
3
.
4

is presented to the user.



© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





18

/

63


Figure
3
.
4

Browsing Content Repository




In
Figure
3
.
4

a
n explorer labeled “JCR/CMIS Tree Nodes and Properties


resides a
t the bo
t-
tom
part
of th
e

page. Content hierarchy of the connected repos
itory can be browsed through
this

explorer. It should
be noted
that the

view presented in the explorer depends on the JCR
or CMIS interface supported by the content repository.

The pane right side of the explorer
lists

the properties of selected node in the explorer.


The pane above the explore
r lists the bridges defined by the user.
When the user clicks the
“New Bridge”

button on top of this pane, a “Bridge Definition Choice” dialog appears on the
screen

as shown in
Figure
3
.
5
.

Then user can select the type of bridge using the combo box
component which lists the following bridges:




Concept Bridge



Subsumption Bridge



Property Bridge



Instance Bridge



© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





19

/

63


Figure
3
.
5

Bridge Creation



When a user selects the bridge type and clicks the check box a pane for creating the selec
t-
ed bridge is opened. Pane for defining a Concept Bridge is shown in
Figure
3
.
6
. User creates
a concept bridge to transform the node as an ontology class in the knowledge base by dra
g-
ging the root node “NewsSubjectCodes” to the Query field of the pane.


User can check the “Indicate as tree root” field to trans
form the selected node and its chi
l-
dren as ontology classes. If user does not indicate a concept name for the specified node,
then its label is used, otherwise newly created class for the node is labeled with the specified
concept name.


Furthermore, user
can specify subsumption bridges by clicking the “Add Subsumption” bu
t-
ton within the scope of the Concept Bridge. If a property of selected node is specified as the
predicate of the Subsumption Bridge then the relationship between the nodes indicated by
the

property is converted as subsumption relation in the target ontology. To convert a node
hierarchy as subclass hierarchy, “child” value should be given as predicate name.



© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





20

/

63


Figure
3
.
6

Defining Concept Bridge



Once the concept bridge definition is completed, it can be saved by clicking the check button
in the bottom of the dialog.

Then
, the bridge definition will appear in the top pane of the page.

User can view the created bridge by
clicking the “Edit” column or he/she can delete it by
clicking the “Delete” column of the corresponding row.


Figure
3
.
7

shows the page when the user selects

Instanc
e Bridge


in the “Bridge Definition
Choice” Dialog
.
At the bottom
-
right of the page there is pane which enables user to create
instance bridges between the nodes of the repository and target ontology.


User can check the “Indicate as tree root” field to tr
ansform the selected node and its chi
l-
dren as ontology individuals.
Furthermore, user can specify property bridges by clicking the
“Add Property Bridge” button within the scope of the Concept Bridge.
Figure
3
.
8

shows the
“Property Bridge” dialog which enables user to define property bridges between the prope
r-
ties of content repository and its corresponding semantic construct in the target ontology.
User can drag and dr
op property names from the “JCR/CMIS Tree Nodes and Properties”
pane to the “Predicate” field of the “Property Bridge” dialog.


© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





21

/

63


Figure
3
.
7

Defining Instance Bridge



Once all bridges are
defined
, user
can view them in XML format by clicking the “Save” button
of the bridge pane.
Pane shown in
Figure
3
.
9

lists the bridge definitions created so far in
XML format.



The dialog displaying bridge definitions in
Figure
3
.
9

has

a “Start Engine” button which en
a-
bles user to
submit bridge definitions to th
e mapping engine. For each bridge definition,
mapping engine access
es

the content repository through JCR or CMIS with the specified p
a-
rameters
.
Then it retrieves the corresponding objects according to the predicate of the bridge
definitions and

creates cor
responding constructs in the target ontology

having URI specified
in the Ontology URI field
.



When the mapping engine completes processing bridge definitions it stores the generated
ontology in the persistence store. It is possible to navigate the generat
ed ontology through
the RESTful interface of the
Persistence Store component as shown in
Figure
3
.
10
.



© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





22

/

63


Figure
3
.
8

Defining Property Bridge



Figure
3
.
9

Executing Mappings

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





23

/

63


Figure
3
.
10

Browsing Ontology


3.3.2

R
EST
ful Interfaces

Ontology Generator also provides RESTful
interfaces to interact with CMSs which do not
support CMIS or JCR. RESTful interface description in WADL is given in Appendix. In su
m-
mary, following resources are described through Restful interface:




Workspace



Mapping File



Content Object



Object Type



Clas
sification Object



Property Definition

Ontology Generator
enables manipulating ontology
mappings

through the described RESTful
interfaces.


© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





24

/

63

3.4

Setting up Ontology Generator

Source code for the ontology generator
currently is not available in
google code
8
. We
are
planning to put it there
soon
.
Currently there is a demo package
9

available in
which Ontology

generator bundle is integrated with FISE framework.

3.4.1

External Software

Requirements

Following software need to be installed in order to proceed set up:



JDK 6



MySQL Server 5

Following software can be used to demonstrate
the functionalities of ontology generator:



Jackrabbit

2.1.0



Alfresco Community Edition
3.3



Nuxeo DM 5.3


Jackrabbit, Alfresco and Nuxeo can be found in the
External

directory of the distribution
package deployed on three different
Apache Tomcat installations

with sample reposit
o-
ries used in the demo.

To run
this

software:



Go to
External/
apache
-
tomcat
-
6.0.16
/bin
run
startup.bat



Go to
External
/
nuxeo
-
distribution
-
tomcat/bin

run
startup.bat

(default port :

8585)



Go

to
External/Alfresco

run
alf_start.bat

(default port :

80
86)


Connection URLs and credentials to be used on
GUI:



JCR (Jackrabbit)

o

URL:

/
/localhost/jackrabbit.repository

o

Username:

username

o

Password:

password



CMIS (Nuxeo)

o

URL:

http://localhost:8086/nuxeo/site/cmis/repository


o

Username:

Administrator

o

Password:

Administrator



CMIS (Alfresco)

o

URL:

http://localhost:8787/alfresco/service/api/cmis



o

Username:

admin

o

Password:

admin


A MySQL database which can be accessible by URL
jdbc:/mysql://localhost:3306/{database_name} where {database_name} is defined in the
co
n-
figuration of
Ontology Generator

should be
created

(
see
4.4.3 for details).

Dump of the dat
a-
base
schema is available at
/Launchers/Ontology Generator/cr2kbmap.sql
.


Lib
directory includes the bundle dependencies that are not currently available in the Maven
Central Repository. These bundles can be installed to any local maven repo by executing
i
n-
stall_local_repo.bat
.




8

IKS Project Google code base
-

http://code.google.com/p/iks
-
project/

9

Demo package location
-

http://
195.142.27.165
:8585/DemoSetup.rar

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





25

/

63

3.4.2

Deploying Components

There are two main components for
Ontology Generator



JCR/
CMIStoOntoBridgeServices:

The services which are invoked by the editor GUI of
the bridge definitions. This
component

also includes the mapping engine along with
the listeners on the JCR
/CMIS

model.



JCR/CMIStoOntoBridgeGUI
:
Graphical
User Interface for Ontology Generator.



Persistence Store Rest
Client:

A java project containing methods to access a remote
Persistence Store’s RESTful services.

Also Persistence Store component should be available to store generated ontologies
.

Onto
l-
ogy
Generator utilizes functionalities of Persistence Store through RESTful services.


Launcher for
Ontology Generator is included under
/Launchers

directory of the demo pac
k-
age

which can be run to start an Apache Felix Framework that contains all necessary bu
n-
dles for running Ontology Generator.

3.4.3

Configuring Ontology Generator

Ontology Generator uses RESTful services of Persistence Store and a database to generate
and store ontologies.
Configuration
for these

services are defined through Apache Felix Web
Consol
e Configuration Tab (
http://localhost:8080/system/console/configMgr
). Following fields
should be set to configure
Ontology Generator
.



eu.iksproject.srdc.ontogen.cr2kb.dbname.name
:
Name of the
database which
should be accessible through URL jdbc:mysql://localhost:3306/



eu.iksproject.srdc.ontogen.cr2kb.db
user
name.name
:

Username to be used in a
u-
thentication when connection to database is made
.



eu.iksproject.srdc.ontogen.cr2kb.dbpasswd.name
:

Password for the user spec
i-
fied above.



eu.iksproject.srdc.ontogen.cr2kb.persistenceHost.name:

Root URL for the
RESTful Services of Persistence Store.



eu.iksproject.srdc.ontogen.cr2kb.persistenceMapHost.name
:

This property is
used
for
internal messaging of

Ontology Generator and its value should always r
e-
main as its default value unless the host or port is changed.


By default some of the fields mentioned above
are

assigned to values such that the launcher
should work without problems provided that all othe
r components are running.


Ontology Generator GUI will be available at
http://localhost:8080/CR2OntGUI/JCRtoOntoBridgeGUI.swf
.

4

Search

Component

4.1

Overview

A Search Component is developed
to exploit the extracted semantics through Ontology
Generator. Again, the aim is to be the least disruptive to the current practices in the CMS i
n-
dustry. Examining the current search techniques used in the CMSs, we build a search inte
r-
face similar to the a
vailable faceted search mechanism. The idea is to present different views
on the results such as possible similar semantic content categories, similar keywords, and
© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





26

/

63

semantic links between the documents. In this way, the search component allows the search
s
cope to be iteratively changed or narrowed until the user is satisfied with the results. The
user is never expected to write a “SPARQL” query; he just navigates through the faceted
search options, the system queries the knowledge
-
base when necessary and pr
esents more
comprehensive results than that could be possible through a full text search engine.


Figure
4
.
1

Extended architecture including the Search Component


Figure 3 displays the extended architecture

where Search Component interacts with the Pe
r-
sistence store to perform semantic search.
The
steps taken by the Search Component

can
be summarized as follows:



The user specifies a free text keyword to the search component. First, a keyword
based search is

performed to collect the content items indexed by a full
-
text search
engine, in our case Lucene.



In the meantime, the search engine queries the knowledge
-
base and for each of the
content item returned in the result set of Lucene, retrieves the correspond
ing indivi
d-
uals. Then the ontology classes related with these individuals through

rdf:type


pro
p-
erty are retrieved from the knowledgebase. While presenting the resulting content
items to the users, these retrieved ontology classes, together with their sup
e
r-
classes/subclasses are also presented as related semantic categories in a navigable.



The user is free to navigate the explicated ontology presented together with the r
e-
sulting document set, and the search scope can be restricted accordingly.



Based on us
er’s preferences, the extracted ontological representation of the content
repository can be used more effectively to enhance the initial result set. After keyword
based search is finalized, the semantic categories of the resulting documents and
their subcl
asses/superclasses, or the ontology resources related with these semantic
© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





27

/

63

categories through object properties, can be used to query the knowledge
-
base, to
r
e
trieve “semantically similar” content items
.
In other words, the ontology classes in a
vicinity of

one another may provide useful semantic information to the user. The cha
l-
lenge here is to be able to provide related ontological sources without overwhelming
the user. Our solution is to set configurable thresholds for calculating the vicinity set
of an o
ntology resource, i.e., how many superclass/subclass, objectProperty links
should be followed to enrich the ontology resource set that will be used to query the
knowledge
-
base to retrieve the relevant contents. Based on the vicinity of the ontol
o-
gy resourc
e to the semantic category, the resulting documents are ranked to give the
user a semantic similarity measure.



Additionally, the user defined keywords are queried from the extracted ontology using
string similarity metrics
10
, and the search results are
extended with the content items
that have been annotated with lexically similar ontological resources (classification
objects in the content repository). Hence it becomes possible to retrieve related co
n-
tent that the full
-
text based search engines have not

indexed.

Our ultimate aim is to improve the discovery mechanisms of content repositories by practical
semantic means that they can use in production. Another such mechanism is to enrich the
search keywords. A horizontal ontology such as WordNet
11

or DBpedia
12

can be used to di
s-
cover the resources semantically related to the keywords provided by the users. The original
set of keywords is then expanded with those retrieved from the ontology look
-
up. The search
process proceeds as purely full
-
text que
rying of the indexed documents with the expanded
keyword set as the new input.
For example
,

when

the user gives “drug“ and “factory” as
keywords and a set of synonymous and related terms (such as hyponyms, hypernyms) are
retrieved from the WordNet Ontolog
y. Once the keyword set is expanded with these terms,
further meaningful results can be obtained. For example, the document entitled: “Cannabis
factory found by police” is also retrieved since “cannabis” is a hyponym of the “drug” term in
WordNet Ontology.

Similar to the WordNet, the DBpedia ontology can be queried to enhance
the keyword set. DBPedia is an initiative to realize the Linked Data vision
13

and it is possible
to locate resources linked to a given keyword, by making use of Wikipedia Infoboxes. For

example, given a keyword “German Chancellor”; the “Angela Merkel” resource can be easily
located from the DBPedia, since these two resources are semantically associated with each
other in the DBPedia ontology and this new keyword can be used in the facete
d search. The
user is also allowed to decide whether to include such additional keywords directly to the
search process, or they can graphically select the ones to be included in the next step of the
search.

4.2

Related Requirements

F
unctionality of the persis
tence store component
corresponds to

the following requirement:




HLR 2204
Semantic se
arch & semantic query




10

Similarity metrics, http://www.dcs.shef.ac.uk/˜sam/simmetrics.html

11

WordNet, http://wordnet.princeton.edu/

12

DBpedia, http://dbpedia.org,

13

Linked D
ata vision, http://linkeddata.org/,

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





28

/

63

4.3

Interfaces

4.3.1

Graphical User Interfaces

Search component provides a simple interface to enable user to perform searches over the
semantically enhanced c
ontent repository. It
accepts free format text keywords and perform
a hybrid search by combining the full
-
text search and semantic search functionalities toget
h-
er.





Figure
4
.
2

UI of Search Component

Figure
4
.
2

displays
the initial graphical user interface of the Search Component. User can s
e-
lect the ontology to work on through the combobox component. Combobox com
ponent also
allow searching the entire ontlogies when “ALL” value is selected. Once the user enters the
string to be searched and clicks the
“Search”
button, hybrid search mechanism of the Search
component is triggered.


Figure
4
.
3

displays
the page which presents the
search results as well as
functionalities for
faceted search and similarity finding. P
ane residing on the left
-
bottom of the page lists
the
results of t
he search. Items listed in this pane
are
ordered
based on their scores calculated
by the hybrid search mechanism.
User can navigate the
results using “Next” and “Prev” bu
t-
tons.


© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





29

/

63

On the right hand side
, there is a pane which lists the top related ontology
classes regarding
the search criteria. Each class listed with a score which determines its relevance with the
search keyword. This pane also enables user to filter the re
sults through selecting and de
-
selecting the related classes in this pane.




Figure
4
.
3

Search Results

Besides list view, related ontology classes can also be presented in a tree view. The pane
can be transformed to tree view by clicking the “Tree View” button.
Figure
4
.
4

presents the
tree view
form of the related ontology classes pane.


There two buttons under the ontology classes pane which are:




Filter



Search with Classes


“Filter” is used
to select the result items which are directly related to the selected ontology
classes listed in the
“Related Ontology Classes” pane.
On the other hand, “Search with Cla
s-
ses” button

enables user to
perform faceted search
by
start
ing

a new search in the
knowledge base to collect
instances of the selected ontology classes.


To enrich the search keywords s
earch component has
been
integrat
ed

with Wordnet r
e-
sources

and DBPedia resources as well
.
Bottom right pane displays the related Wor
dnet r
e-
sources as shown in
Figure
4
.
3
.


© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





30

/

63




Figure
4
.
4

Filtering Through Classes


Once the results listed on the page,
user can get further details by clicking the links of the r
e-
sult items. In
Figure
4
.
5
, a dialog which presents the details of “HowToMakeASwineFluVa
c-
cine” object is dis
played. These details include the properties which are “createdBy” and
“name” for the object shown in
Figure
4
.
5
. “href” property contains the URL to the CMIS o
b-
ject,

hence user can use this link to fetch the item through CMIS interface of the content r
e-
pository.

Type attributes indicate the “instanceof
“ relations

and list the classes of the
displayed item.

If the item is generated from a JCR repository
, JCR object

can

be fetched
through the JCR interface and displayed when user clicks the “Show JCR Object” button.






© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





31

/

63



Figure
4
.
5

Result Item Details


4.4

Setting up Search Component

Source code for the search component
currently is not available in google code
14
. We are
planning to put it there soon. Currently there is a demo package
15

available in which search
component bundle is integrated with FISE framework.

4.4.1

External Software Requirements



JDK 6



Wordnet 2.X dictionary



S
olr



A JCR Repository (Jackrabbit 2.1.0 is used in the demo package)





14

IKS Project Google code base
-

http://code.google.com/p/iks
-
project/

15

Demo package location
-

http://195.142.27.165:8585/DemoSetup.rar

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





32

/

63

To start Solr go to
External/solr/example
and run
start_solar.bat.

Solr server should start
at
http://localhost:8983/

to test check
http://localhost:8983/solr/admin

. This address will be
used in configuring Search component.



To start Jackrabbit go to
External/apache
-
tomcat
-
6.0.16/
bin

and run
startup.bat
to run
Jackrabbit 2.1.0.

Default URL and credentials for the Jackrabbit should be as following:



URL
: //localhost/jackrabbit.repository



Workspace: default



Username: username



Password: password


4.4.2

Deploying Components

There are two main components for Search Component:



SemanticSearch
Services
: The service functions which are invoked within the Sema
n-
ticSearchGUI procedures.



SemanticSearchServices
GUI: Graphical User Interface for Search Component


Also Persistence Store component should be available
with some generated ontologies
already

persisted so that search is conducted over them
.

Search Component
utilizes fun
c-
tionalities of Persistence Store through RESTful services.

A database dump is
available at

/Launchers/Search/ikspersistencestore.sql.

This file can be used to populate the database
that Persistence Store uses.


Launcher for Search Component is included under
/Launchers

directory of the demo pac
k-
age

which can be run to start an Apache Felix Framework that contains all necessary bu
n-
dles f
or running
Search Compo
nent
.



4.4.3

Configuring Components

Search Component uses RESTful services of Persistence Store a Solr server and and a
Wordnet dictionary. Configuration for these services are defined through Apache Felix Web
Console Configuration Tab (
http://localhost:8080/system/console/configMgr
). Following fields
should be set to configure Search Component
:



eu.iksproject.fise.jenastore.persistence.search.RestfulInteraction.RestRootURL
:

Roo
t URL for RESTful Services of Persistence Store (default for demo
launcher
are
http://localhost:8080/persistencestore/
)



eu.iksproject.fise.jenastore.persistence.search.RestfulInteraction.SOLRHost:

Solr host URL (default for demo launchers are

http://localhost:8983/solr/


)



eu.iksproject.fise.jenastore.persistence.search.RestfulInteraction.JCRReposito
ry:

A JCR Repository URL (Jackrabbit
2.1.0 is used for de
mo launcher
, default value
is
//localhost/jackrabbit.repository
)



eu.iksproject.fise.jenastore.persistence.search.RestfulInteraction.JCRUsernam
e:

Username to be used authentication of JCR connection (default for demo launcher
is username)



eu.iksproject.fise
.jenastore.persistence.search.RestfulInteraction.JCRPasswor
d
:
Password for the username specified above.



eu.iksproject.fise.jenastore.persistence.search.RestfulInteraction.JCRPasswor
d
:
JCR Workspace name (default for demo launcher is

default
)


© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





33

/

63

By default
all of the fields mentioned above are assigned to values such that the launcher
should work without problems provided that all other components are running.



Also configuration property
eu.iksproject.fise.stores.persistencestore.wordnet.WordnetClient.databaseDirectory


for com
ponent
eu.iksproject.fise.stores.persistencest
ore.wordnet.WordnetClient

should
be set to full path of Wordnet dictionary
/External/wordnet/dict
.


Search Component GU
I will be available at
http://localhost:8080/SemanticSearch/SemanticSearchGUI.swf




© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





34

/

63

5

Appendix


5.1

Persistence

Store WADL

<?
xml

version
=
"1.0"

encoding
=
"UTF
-
8"

standalone
=
"no"
?>

<
application

xmlns
=
"http://research.sun.com/wadl/2006/10"
>


<
doc

xmlns:jersey
=
"http://jersey.dev.java.net/"

jersey:generatedBy
=
"Jersey: 1.4
-
SNAPSHOT 07/28/2010 05:57 PM"
/>


<
resources

base
=
"http://localhost:8080/persistencestore"
>


<
resource

path
=
"/ontologies/{ontologyPath}/dump"
>


<
param

xmlns:xs
=
"http://www.w3.org/2001/XMLSchema"

name
=
"ontologyPath"

style
=
"template"

type
=
"xs:string"
/>


<
method

id
=
"ontologies.ontologyPath.dump.dumpOntology"

name
=
"GET"
>


<
response
>


<
representation

mediaType
=
"application/xml"
/>


</
response
>


</
method
>


</
resource
>


<
resource

path
=
"/ontologies/{ontologyPath}/search"
>


<
param

xmlns:xs
=
"http://www.w3.org/2001/XMLSchema"

name
=
"ontologyPath"

style
=
"template"

type
=
"xs:string"
/>


<
method

id
=
"ontologies.ontologyPath.search.reIndex"

name
=
"POST"
>


<
request
>


<
representation

mediaType
=
"application/x
-
www
-
form
-
urlencoded"
>


<
param

xmlns:xs
=
"http://www.w3.org/2001/XMLSchema"

name
=
"reIndex"

style
=
"query"

type
=
"xs:boolean"
/>


<
param

xmlns:xs
=
"http://www.w3.org/2001/XMLSchema"

name
=
"query"

style
=
"query"

type
=
"xs:string"
/>


</
representation
>


</
request
>


<
response
>


<
representation

mediaType
=
"*/*"
/>


</
response
>


</
method
>


</
resource
>


<
resource

path
=
"/ontologies/{ontologyPath}"
>


<
param

xmlns:xs
=
"http://www.w3.org/2001/XMLSchema"

name
=
"ontologyPath"

style
=
"template"

type
=
"xs:string"
/>


<
method

id
=
"ontologies.ontologyPath.retrieveOntology"

name
=
"GET"
>


<
request
>


<
param

xmlns:xs
=
"http://www.w3.org/2001/XMLSchema"

default
=
"false"

name
=
"withInferredAxioms"

style
=
"query"

type
=
"xs:boolean"
/>


</
request
>


<
response
>


<
representation

mediaType
=
"application/rdf+xml"
/>


</
response
>


</
method
>


<
method

id
=
"ontologies.ontologyPath.retrieveOntologyMetadata"

name
=
"GET"
>


<
request
>

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010





35

/

63


<
param

xmlns:xs
=
"http://www.w3.org/2001/XMLSchema"

name
=
"retrieveResourceWithURI"

style
=
"query"

type
=
"xs:string"
/>


</
request
>


<
response
>


<
representation

mediaType
=
"application/xml"
/>


</
response
>


</
method
>


<
method

id
=
"ontologies.ontologyPath.delete"

name
=
"DELETE"
/>


</
resource
>


<
resource

path
=
"/ontologies/{ontologyPath}/classes/"
>


<
param

xmlns:xs
=
"http://www.w3.org/2001/XMLSchema"

name
=
"ontologyPath"

style
=
"template"

type
=
"xs:string"
/>


<
method

id
=
"ontologies.ontologyPath.classes.retrieveOntologyClasses"

name
=
"GET"
>


<
response
>


<
representation

mediaType
=
"application/xml"
/>


</
response
>


</
method
>


<
method

id
=
"ontologies.ontologyPath.classes.generateClass"

name
=
"POST"
>


<
request
>


<
representation

mediaType
=
"application/x
-
www
-
form
-
urlencoded"
>


<
param

xmlns:xs
=
"http://www.w3.org/2001/XMLSchema"

name
=
"classURI"

style
=
"query"

type
=
"xs:string"
/>


</
representation
>


</
request
>


<
response
>


<
representation

mediaType
=
"*/*"
/>


</
response
>


</
method
>


</
resource
>


<
resource

path
=
"/ontologies/search"
>


<
method

id
=
"ontologies.search.reIndex"

name
=
"POST"
>


<
request
>


<
representation

mediaType
=
"application/x
-
www
-
form
-
urlencoded"
>


<
param

xmlns:xs
=
"http://www.w3.org/2001/XMLSchema"

name
=
"query"

style
=
"query"

type
=
"xs:string"
/>


<
param

xmlns:xs
=
"http://www.w3.org/2001/XMLSchema"

name
=
"reIndex"

style
=
"query"

type
=
"xs:boolean"
/>


</
representation
>


</
request
>


<
response
>


<
representation

mediaType
=
"*/*"
/>


</
response
>


</
method
>


</
resource
>


<
resource

path
=
"/ontologies/{ontologyPath}/objectProperties"
>


<
param

xmlns:xs
=
"http://www.w3.org/2001/XMLSchema"

name
=
"ontologyPath"

style
=
"template"

type
=
"xs:string"
/>


<
method

id
=
"ontologies.ontologyPath.objectProperties.generateDatatypeProperty"

name
=
"POST"
>


<
request
>


<
representation

mediaType
=
"application/x
-
www
-
form
-
urlencoded"
>

© IKS Consortium

2010



Deliverable 3.4 Semantic Data Access and Persistence Requirements Specification



June 2010