VOCBENCH_2.0_D&Dx - FAO.org

taupesalmonInternet και Εφαρμογές Web

21 Οκτ 2013 (πριν από 4 χρόνια και 19 μέρες)

130 εμφανίσεις

VocBench 2.0

DOCUMENT
STATUS

SHEET


Version

Date

Description of evolution

Owner

0.1

18

October 2012

First draft

Armando Stellato


Note
: for rationales behind the choices which led to current VOCBENCH 2 Architecture, see past
document

VocBench
SKOS
Development Strategy
”, first drafted on
the
11
th

November 2009, and
finalized on
the
22
nd

of

November 2011






Contents



1

VOCBENCH 2.x Architecture: main directions

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

3

1.1

Getting source code of Semantic Turkey

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

4

2

VOCBENCH 2 Architecture

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

5

3

List of VOCBENCH Services

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

6

3.
1

Semantic Turkey Core Services

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

6

3.2

VOCBENCH 2.x specific services

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

10

5

Improvements in Semantic Turkey to be included (if possible) directly in VOCBENCH 2.0

..

1
1

5.1

Project Mavenization

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

11

5.2

OSGi Management: Integration with Spring/OSGi

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

11

5.2.1

A new OSGi Manager

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

12

5.3

Service Publication: Standard Serialization of objects
................................
........................

12

5.3.1

Normalization of Content: Service Responses
................................
.............................

12

5.3.2

Normalization of content: Service Requests

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

15

5.4

Service Publication: Introducing Spring Features

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

15

5.5

Automatic Generation of Controllers

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

17

5.6

Automatic Generation of Client API

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

17

6

Status of Design and Development

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

18

6.1

List of JIRA issues

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

19

7

References

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

97




1

VOCBENCH 2.x Architecture: main directions

The project
VOCBENCH 2
wa
s born

on the basis of two contrasting factors: its success, and its
observed

flaws.

T
he
VOCBENCH platform

has been initially

developed for exclusive internal usage in the
maintenance of the AGROVOC vocabulary
.

However, thanks to its almost unpaired (at least in the
open source world) features of collaborative editing, easiness of use and intuitiveness of the
UI with
respect to its intended target of thesauri and vocabulary editors, it
has captured the interest of many
more actors, still internally to FAO (other groups with similar exigencies to the OEKC group)
,
and
externally

as well
.

On the other
hand
, this
l
arge
interest has
put into evidence its main flow: its low flexibility
and
openness
with respect to
the
task of migrating

to a new domain.

Simply put, the VOCBENCH is not
easily portable to new domains (new schemes, ontologies etc…) as it requires heavy re
structuring
of its organization, even at code level.

There are various levels of stativity which emerge when
VOCBENCH needs to be ported to a new domain, in particular:

1.

It source code contains

static references to
a given vocabulary.

In the specific: a gen
eric set
of metaproperties/classes which drive the application behavior, and a domain model; the set
of both these resources was represented by a vocabulary called AOS.owl (AOS stands for
Agriculture Ontology Services)
.

Moving to a new
vocabulary required
creating static
references at least for domain objects in the code

2.

AOS.owl included both application data and domain data,
plus there is no way in
VOCBENCH to keep portions of data distinct nor to address provenance
. As a consequence,
all the triples
related to AOS.owl and to the domain data (e.g. the AGROVOC Dataset) are
merged by the application. This does not ease maintenance of the information.

3.

Finally,
the domain vocabulary (if any) need to rely on specific properties defined in the
meta
-
section o
f AOS.owl, thus it is not possible to adopt on
-
the
-
fly any new (even if
standard) vocabulary inside VOCBENCH, as this must be adopted by specifying
connections to the application
-
driving vocabulary (part of AOS.owl).

Stativity is not the only
limitation of

VOCBENCH,
as also compliance with standards is hampered
by the obsolete
legacy
meta
-
model which was being used to structure and organize domain
information
. As SKOS had still n
ot been provided by the W3C at the time

VOCBENCH was first
designed
, VOCBENCH developers had to define a custom
meta
-
model

defined in OWL
, which
allowed for the definition of concepts as first
-
order entities

, which was the main concern as for the
necessity of remaining into the scope
(and decidability)
of OWL DL

[
1
]
.

Today, VOCBENCH
provides, through offline export tools, the possibility to export data in different formats (including
SKOS and SKOS
-
XL) however, with the availability of these standard modeling vocabulary

provided by the W3C, it is
at least opportune, if not necessary
1
,

to support them natively.

D
ifferent scenarios (see
[
2
]

for details)

have thus been considered for the evolution of VocBench, in
terms o
f functionalities to implement, of non
-
functional requirements to satisfy, and, obviously, of
technologies to be adopted
.

The choice of the technical team responsible for the evolution of VocBench has been then

to realize
a jointly
-
ventured project, togeth
er with the ART group of the University of Tor Vergata, for the
integration of VOCBENCH 1 with Semantic Turkey, a Knowledge Management and Acquisition
(open source)
platform
for RDF
designed, developed and maintained by them.




1

This necessity may come into play when dealing, again, with openness of the system to third party
vocabularies being
injected on
-
the
-
fly (as of porting to a new domain, but also in the context of extensions playing with, or relying on,
further vocabularies), which thus cannot be considered if these vocabularies need any sort of preprocessing.

The objective of this
integration is to take the best of both worlds, in terms of:

1.

Loosely coupled Service
-
based access mechanism (Semantic Turkey)

2.

Compliance
with

the standards (Semantic Turkey, with full support for SKOS/SKOS
-
XL,
and partial support for OWL)

3.

Opennes and Exten
dibility (Semantic Turkey
, thanks to its OSGi
-
based extension
mechanism
)

4.

Support for collaborative editing (VOCBENCH 1)

5.

Web
Remote
Access (VOCBENCH 1)

6.

Thesaurus
-
editing
-
oriented interface

(VOCBENCH 1)

1.1

Getting source code of Semantic Turkey


Semantic Turkey

site is reachable at:
http://semanticturkey.uniroma2.it/


Semantic Turkey is both a tool and a
RDF
framework.
The framework, written in Java and featuring
standard technologies such as OSGi, RDF triple st
ores etc… is a service based extensible
framework for managing RDF resources.

The tool, based on the above framework, is a Firefox
extension allowing for Content Creation, Management and Acquisition from web content.

Currently, the Semantic Turkey project
is a compound Maven project consisting of six modules
integrating different technologies (from Java to Mozilla
JavaScript language and XUL user
interface definitions).


Here follows a brief description of the six modules:

-

st
-
core
-
framework

: the main
module implementing the Semantic Turkey framework. Java
classes for orchestrating Semantic Turkey services, administering RDF projects, selecting
RDF models, etc... are implemented here

-

st
-
core
-
services

: the framework above implements the basis through wh
ich services can be
implemented and published, but offers no service. This module contains the list of all
services which are thought to be part of the basic
Semantic Turkey

distribution.
ST services
are packaged as an OSGi bundle.

-

st
-
firefox
-
ext

: the fire
fox extension which realizes the client of the Semantic Turkey
application

-

st
-
graph
-
applet

: a graph applet which shows a graph
-
browsing application for the
ontology/concept scheme managed through ST

-

st
-
sesame2
-
ontmanager

: an implementation of Ontology Ma
nager abstract component
(see instructions below). It is packaged as an OSGi bundle much the same way as the core
services

-

st
-
test
-
suite

: a dedicated test suite for Semantic Turkey services. Services can be tested
over the server in "real time" mode, with

a dedicated java client replicating the usual
javascript client queries, or in "development mode", by directly accessing the java classes of
the services with no client
-
server communication

Integration with Semantic Turkey will be carried on at service
-
le
vel, that is, Semantic Turkey
services will be invoked remotely by the VOCBENCH system, which will, in its new incarnation,
only dedicated to user management, security and providing the UI through a web application
implemented through the Google Web Toolki
t (GWT).




2

VOCBENCH 2 Architecture

The Architecture of VOCBENCH reflects its integration with the Knowledge Management and
Acquisition Framework Semantic Turkey.





3

List of
VOCBENCH Services

3.1

Semantic Turkey
Core
Services

Here follows a list of
the core
services provided by
the
Semantic Turkey

framework.

These services
are flanked by services developed specifically for VOCBENCH (roughly, these
latter
services are
redundant with respect to the first ones, but their requests may have been optimized to carry

content
in the way/order it is being shown in the VOCBENCH UI)

as described in section
3.2
.

Javadocs are (usually) provided in the method implementing the service
, so they can be viewed
directly from the project code or from the javadocs
.

The service classes are all contained in a
module of the Semantic Turkey project called “st
-
core
-
services” which, during bui
ld, is packed as
an OSGi bundle

and deployed in the ser
vice
-
extension directory of the target
system
build.

Each
service class provides the implementation for a collection of logically
-
bound services. The
service
list reports on the left column the available core service classes (i.e. those which are bundled w
ith
the core distribution of Semantic Turkey, in the above mentioned “st
-
core
-
services” module) and
on the right, for each class, the
contained

services.

For the record, there

is a total of 22 core service classes implementing 156 core services in
Semanti
c Turkey.


SERVICE

CLASS

SERVICE NAME



SystemStart

start


openProject


listTripleStores



Administration

setAdminLevel


getOntologyMirror


deleteOntMirrorEntry


updateOntMirrorEntry



Annotation

getPageAnnotations


chkAnnotations


chkBookmarks


removeAnnotation


createAndAnnotate


addAnnotation


relateAndAnnotate


bookmarkPage


getBookmarksByTopic


getPageTopics


getAllBookmarks


removeBookmark



Cls

getClassTree


getClassesInfoAsRootsForTree


getClassAndInstancesInfo


getSuperClasses


getSubClasses


createInstance


createClass


addType


addSuperCls


removeType


removeSuperCls



Delete

removeProperty


removeInstance


removeClass



Environment

systemprops



Individual

getDirectNamedTypes


addType


removeType



InputOutput

saveRDF


loadRDF


clearData



Metadata

setDefaultNamespace


getDefaultNamespace


setBaseuri


getBaseuri


setBaseuriDefNamespace


getNSPrefixMappings


setNSPrefixMapping


changeNSPrefixMapping


removeNSPrefixMapping


getImports


removeImport


addFromWebToMirror


addFromWeb


addFromLocalFile


addFromOntologyMirror


downloadFromWebToMirror


downloadFromWeb


getFromLocalFile


mirrorOntology


getNamedGraphs



ModifyName

rename



OntManager

getOntManagerParameters



OntologySearch

searchOntology



Page

getBookmarks



Plugins

getPluginList


getPluginsForProject



Projects

openProject


newProject


newProjectFromFile


closeProject


deleteProject


exportProject


importProject


cloneProject


saveProject


saveProjectAs


listProjects


getProjectProperty


setProjectProperty


getCurrentProject


repairProject



Property

getPropertiesTree


getObjPropertiesTree


getDatatypePropertiesTree


getAnnotationPropertiesTree


getOntologyPropertiesTree


getDomainClassesTree


getRangeClassesTree


getSuperProperties


parseDataRange


getDomain


getRange


hasValueInDatarange


addProperty


addPropertyDomain


addPropertyRange


addSuperProperty


createAndAddPropValue


addExistingPropValue


addValuesToDatarange


addValueToDatarangesetDataRange


removePropertyDomain


removePropertyRange


removeSuperProperty


removePropValue


removeValueFromDatarange



Resource

getPropDescription


getClsDescription


getConceptDescription


getIndDescription


getOntologyDescription


getConceptSchemeDescription


getPropertyValues


getPropertyValuesCount


getValuesOfProperties


getValuesOfPropertiesCount



Skos

getTopConcepts


getBroaderConcepts


getNarrowerConcepts


getAllSchemesList


getPrefLabel


getAltLabels


getSchemesMatrixPerConceptReque
st


isTopConcept


addTopConcept


addBroaderConcept


addConceptToScheme


setPrefLabel


addAltLabel


createConcept


createScheme


removeTopConcept


deleteConcept


deleteScheme


removePrefLabel


removeAltLabel


removeConceptFromScheme


removeBroaderConcept


assignHierarchyToScheme


showSKOSConceptsTree



SkosXL

getLabels


getPrefLabel


getAltLabels


getHiddenLabels


setPrefLabel


addAltLabel


addHiddenLabel


createConcept


removePrefLabel


removeAltLabel



Sparql

resolveQuery



Statement

getStatements


hasStatement



Synonyms

getSynonyms


addSynonym






3.2

VOCBENCH 2.x specific services


A separate Maven project provides source which is built as an OSGi bundle and which can be
deployed on the Semantic Turkey service
-
extension folder. These services add functionalities which
are unique to VOCBENCH or, as explained in the previous section, g
roup information coming from
different ST services into one wider service, to save bandwidth and
avoid
costly sequences of
requests to different core services.


VOCBENCH

changeLabelInfo


prefToAltLabel


altToPrefLabel


getLabelDescription


getSubProperties




4

Improvements in Semantic Turkey to be included (if possible) directly
in VOCBENCH 2.0

Semantic Turkey is an always
-
in
-
evolution software platform. Its developers and maintainers
always look for new promising technologies
to integrate
and for interesting design patterns

to
implement
, to facilitate maintenance of the system and, moreover, ease the development of
extensions.

This section covers improvements which were already planned for Semantic Turkey but which have
never been brought t
o the system (mostly because they may require lot of effort and/or strong
changes in the architecture, which may affect compatibility with all developed extensions). The
integration

with VOCBENCH

is an important milestone for which the priority of these

mo
difications has been revised,
thus aiming at providing a stable technology for
the new
VOCBENCH 2.0
, yet from its initial release.

Here follows a list of changes the development of which has already started and which, hopefully,
will see the light before t
he
first

release of VOCBENCH 2.0

4.1

Project Mavenization

Semantic Turkey project definition is totally based on Maven. A plethora of Maven plugins has
been adopted to enable a full automatic build of the heterogeneous technologies adopted into its
modules.

Fo
r VOCBENCH 2.0, we have initially ported also the original VOCBENCH 1 project to Maven
.

The integrated VOCBENCH 2.0 will thus be based on a full Maven
-
based
build &
deploy

process
.

4.2

OSGi Management
: Integration with Spring/OSGi

Currently,
Semantic Turkey f
eatures a proprietary OSGi Manager based on the Felix
2

OSGi
framework, which takes into account the necessity of having a dynamic extension mechanism for
the system, and a configurable directory structure for the folders hosting the various bundles
require
d by the application.

OSGi is thus adopted for its capacity to offer separate classloaders (so that, for instance, library
incompatibilities between dependencies adopted by different extensions do not cause any
inconsistency into the system, being actually

kept in different class loading areas of the JVM)
and
for its dynamic bundle loading.
Extensions managed through this technology fall then into different
areas, called extension points, that is, functional points which specify in advance where the system
can be extended, so that the system, knowing their interfaces in advance, knows where and how to
apply their content.

Semantic Turkey offers two kind of extension points: services and ontmanagers.

The first extension point is related to the publication of
services for implementing all of the system
functionalities. A first set of services (called
core services
, see section
3.1
) is packed in a dedicated
module in the

main project of Semantic Turkey. However, other bundles may be added, defining
new functionalities and publishing them as services.

The second extension point deals with different implementations for triple storing technologies.
Actually, the interface
deals with all tasks related to the management of an ontology, ranging from
mere triple storage to high level functionalities such as automatic resolution of ontology
dependencies etc… However, a dedicated adapter class (
STOntologyManager
) takes care of al
l the
high
-
level functionalities and leaves room for only the basic connection to the triple store
,




2

http://felix.apache.org/

consisting, in turn, of a specific implementation of the OWL ART RDF library and of all the
bootstrapping and
connecting code
.

All classes implementing an e
xtension point in a given bundle are registered to the OSGi Manager
by a BundleActivator, which lists all classes in the package which implement a service and adds
them to a registry; the Manager then inspects this registry and activates the extensions.

4.2.1

A
new
OSGi M
anager

When dealing with OSGi based applications, there are usually two architectural paradigms wich can
be followed:

-

Building an application, and then connecting its extensions through OSGi

-

Putting everything under an OSGi Manager

While in the c
urrent Semantic Turkey, we followed the first approach for the purposes of having a
cleanly defined traditional architecture, enriched with extensidibility, we are now in the process of
moving
towards
a
n existing framework (…) which integrates (and takes c
are almost completely of)
both OSGi and Spring
3

features.

In this new environment,
the whole Semantic Turkey application
will be seen itself as an OSGi bundle, which is loaded by a
M
anager (already provided by the
hosting
framework).

The combination of OSG
i and Spring features make this framework ideal for
being easily connected to many hosting environments (e.g. being hosted as a web application in an
application server) through standard connectors,
its installation as a service etc…
whereas the
current ve
rsion
requires

a manual startup

or dedicated effort to be spent on configuring it to be used
as a service.

4.3

Service
Publication
:
Standard Serialization of objects

Semantic Turkey has been initially
developed as a very simple annotation tool based on the OWL

standard (thus not a full OWL editor, but rather
based

on OWL)

for bookmarking pages with
respect to a simply defined ontology.

Later on, the project evolved into a fully
-
fledged RDF Management platform.

As a consequence
(the project is managed by a research group, it has not always been funded nor has it ever been
funded explicitly for its development, but rather in the context of associated projects)

much code
has evolved on top of past one, not always
with a clear and unifying homogeneous perspective.

In the recent year, a process of normalization of domain data has been initiated. This involves
mainly the definition of standard serialization formats for:

1.

Content formats for the service responses

2.

Conten
t formats for the service requests

4.3.1

N
ormalization of
C
ontent
: Service Responses

A standard format for the service responses has already been formalized in 2009. Dedicated
Interfaces for the various response formats are available in the core
-
framework module

of the
project as well as dedicated serialization
s have been implemented for the XML and JSON formats.

Some of the services have been implemented for both formats, and the requester may choose the
preferred one by specifying the preferred format in the

a
ccept


parameter of the http request
header.

Most of the services are however implemented in XML, and accept only that format.




3

http://www.springsource.org/

What lacks in term of normalization is the serialization of the content. All services define ad
-
hoc
response structures which nee
d to be parsed by the calling requester.

We are now progressively moving towards a standardization of the XML format for the responses.
This covers mainly the specification of how to normalize:

1.

The serialization of RDF content

2.

The serialization of structur
es of the above (lists, collections etc..)

3.

the embedding of the two above into a response

Here follows a simple table providing serialization examples for the main three RDF entities: URIs,
Blank Nodes and Literals:

Type

Example

Primitive Value

<value
type="http://www.w3.org/2001/XMLSchema#boolean">true</value>

(the type follow the XMLSchema list of primitive types)

RDF Value

<uri explicit="true" lang="ar" role="xLabel" show="
مممممم
">

http://aims.fao.org/aos/agrovoc/xl_ar_1304999811488

</uri>


or


<pla
inLiteral lang="en">products</plainLiteral>


or


bnode (follows same attribute structure as uri; just its xml tag is called bnode instead
of URI) and the content of the xml Element is the bnode ID

Collection

<collection>


<uri explicit="true" lang="ar"
role="xLabel" show="
تاجت ن م
">



http://aims.fao.org/aos/agrovoc/xl_ar_1304999811488


</uri>


<uri explicit="true" lang="cs" role="xLabel" show="produkty">



http://aims.fao.org/aos/agrovoc/xl_cs_1304999811514


</uri>

</collection>

NamedCollection

<
prefLabels>


<collection>


<uri explicit="true" lang="ar" role="xLabel" show="
تاجت ن م
">



http://aims.fao.org/aos/agrovoc/xl_ar_1304999811488


</uri>


<uri explicit="true" lang="cs" role="xLabel" show="produkty">



http://aims.fao
.org/aos/agrovoc/xl_cs_1304999811514


</uri>


</collection>

</prefLabels>

NamedValue

as for named collection, but contains a single value


With respect to the service list defined in section
3
, the following services have been normalized:

Code

Explanation



NA

Not Applicable (no RDF resources, or no
data at all)



Done

moved to new standard for serialization



Done/Info

Done,
plus the serialization contains
additional info other

than the classical

one









Service

Method

Status

Additional Info









Cls




Cls

getClassTree



Cls

getClassesInfoAsRootsForTree



Cls

getClassAndInstancesInfo



Cls

getSuperClasses

Done


Cls

getSubClasses

Done


Cls

createInstance



Cls

createClass



Cls

addType



Cls

addSuperCls



Cls

removeType



Cls

removeSuperCls











Resource

getResourceDescription

Partially Done

check differences





SKOS

All Unit Tests ran and
currently run OK



SKOS

addAltLabel

NA


SKOS

addBroaderConcept

Done


SKOS

addConceptToScheme

NA


SKOS

assignHierarchyToScheme

NA


SKOS

createConcept

Done


SKOS

createScheme

Done


SKOS

deleteConcept

NA


SKOS

deleteScheme

NA


SKOS

getAllSchemesList

Done


SKOS

getAltLabels

Done


SKOS

getConceptSchemeDescription

Partially Done

check differences

SKOS

getNarrowerConcepts

Done/Info

more (hasChildren)

SKOS

getPrefLabel

Done


SKOS

getSchemesMatrixPerConcept

Done/Info

inScheme="true"

SKOS

getTopConcepts

Done/Info

more (hasChildren)

SKOS

removeAltLabel

NA


SKOS

removeBroaderConcept

NA


SKOS

removeConceptFromScheme

NA


SKOS

removePrefLabel

NA


SKOS

setPrefLabel

NA


SKOS

showSKOSConceptsTree

NA






SKOSXL

All new services are based on

the
normalized responses

Done


VOCBENCH


All new services are based on the
normalized responses

Done


4.3.2

N
ormalization of content
:

Service
Requests


Analoguous considerations to those of the previous sections have been held for the
format in which
to pass
the arguments in a request. For the moment, only specifications for RDF objects (following
the NTRIPLES serialization format) have been provided:



Entity Type

serialization

examples

URI




<uri> or qname

e.g. <http://art.uniroma2.it/stellato>


art:stellato



Notice that: at this moment, the system is retrocompatible to
accept even localnameonly names instead of forcing qnames (e.g.
armando instead of :armando)







BNode

_: prefixed form

e.g. _:23452345










Literal




usual

literal
serialization

e.g. "person"@en


"person"


"123"^^xsd:int


"pippo"^^<http://www.w3.org/2001/XMLSchema#String>



4.4

Service
Publication
: Introducing Spring Features

Currently, Semantic Turkey services are published
as web services
by
implementing a dedicated
interface:
ServiceInterface
4
,

containing

all the methods which, by contract, are then invoked by the
main servlet of the system

when a request is received
.

A
dedicated adapter class implementing most
of
ServiceInterface

methods is available in the same package, called
ServiceAdapter
, so service
developers can actually extend this latter one
.

When am HTTP request arrives to the application servlet, the request is redirected to the proper
class, on the basis of the “servic
e” argument of the request. The specific service method is then
invoked
on the basis of the “request” parameter in the same request.

Each class represents a logically coupled set of services so, for instance, all services related to
management of owl:Class
(es) are contained into the
Cls

cl
ass of the core services bundle, while all
services related to management of the different projects in ST are implemented in the
Project

class.

Implementing a new service class is not a difficult task, but it contains lot
of redundant declarations
and requires implementation in the business logic of the server, of other aspects of development
related to Data Validation, Conversion (for instance, from web service string arguments to complex
Java objects)
, Bindings etc..

A se
rvice class usually starts with a long “switch” portion of code, implemented through a long
list
of if
-
then
-
else constructs,

which is necessary to select the righ method on the basis of the “request”
parameter contained in the request. Here is

an excerpt o
f code from a typical long series of “if”
implementing the switch :




4

it.uniroma2.art.semanticturkey.plugin.extpts
.ServiceInterface





}
else

if

(request.equals(Req.
assignHierarchyToSchemeRequest
)) {





String conceptName = setHttpPar(Par.
concept
);





String schemeName = setHttpPar(Par.
scheme
);





checkRequestParametersAllNotNull(Par.
concept
, Par.
scheme
);





logger
.debug(Req.
assignHierarchyToSchemeRequest

+
":
\
n"

+ response);





response = assignHierarchyToScheme(conceptName, schemeName);


in the above figure, a
positive
check on the

request


argument passed to the service class

is
followed by the initialization of the interested method arguments through a mapping on the
parameters passed to the request. Finally, the method of interest is i
nvoked with the initialized
parameters.

A check (through a vararg method:
checkRequestParametersAllNotNull
invoked on a
subset of the method arguments) in between the arguments initialization and the method invocation
guarantess that the necessary argument
s have been correctly initialized.

The method implementation then follows:


public

Response assignHierarchyToScheme(String conceptName, String schemeName) {

SKOSModel skosModel = getSKOSModel();

XMLResponseREPLY response =
createReplyResponse(RepliesStatus.
ok
);


try

{



ARTResource[] graphs = getUserNamedGraphs();


ARTURIResource concept = retrieveExistingResource(skosModel, conceptName, graphs);


ARTURIResource scheme = retrieveExistingRe
source(skosModel, schemeName, graphs);


assignHierarchyToSchemeRecursive(skosModel, concept, scheme, graphs);



}
catch

(ModelAccessException e) {

return

logAndSendException(e);

}
catch

(NonExistingRDFResourceException e) {

return

logAndSendE
xception(e);

}
catch

(ModelUpdateException e) {

return

logAndSendException(e);

}

return

response;

}


In particular, we may observe some validation, transformation etc.. in the code:

-

Explicit reference to the service response
:
An XML response needs to be
explicitly built
from inside the method (there are facilities for it, as the response is built with a single
method invocation

(
createReplyR
e
sponse(..)
)
,
yet it is explicit while it could be delegated to
the controller publishing the business method, and n
ot to the method itself)

-

Conversion and Validation
: the method takes strings as input, as they ar
e passed to the
service request, it then takes care of
transforming

them into the dedicated java objects
managed by the OWLART library.

Also, a
validation

is c
arried on, as
the method: takes
care, other than converting the input argument strings into RDF Resources, of checking
whether the created rdf resource is defined in the loaded
SKOS

Model.

It is clear that such an approach
:

-

Introduces redundancy

-

It is
slow

to be implemented

-

It is
error prone

-

does n
ot help readability of the code

-

all the information related to a service is split among
its entry in the long initial switch, and the method implementation ahead in the class code.

Luckily, the
integration with

Spring guarantees an easy
adoption

of
specific

design patterns
for
solving the above issues, through dedicated features provided by the framework.

Here follows an example of how we would like to rewrite the above method (
by
also

totally

avoiding

the
long
switch section
)
:


@Service

(security_level=
"user "
)

@RequestMapping("/
concept
", method=RequestMethod.POST)

@RequestMapping("/
scheme
", method=RequestMethod.POST)

public

Response

assignHierarchyToScheme(
@Existing

ARTURIResource concept,
@Existing

ARTURIResource scheme)

throws

ModelAccessException, ModelUpdateException, NonExistingRDFResourceException {

SKOSModel skosModel = getSKOSModel();

XMLResponseREPLY response = createReplyResponse(RepliesStatus.
ok
);

ARTResource[] graphs =
getUserNamedGraphs();

assignHierarchyToSchemeRecursive(skosModel, concept, scheme, graphs);

return

response;

}


As it is easy observable, the
reported java
annotations take care of explicit
i
ng the
semantics of the
validation and of the publishing of the
method, while implicit conversion will be guaranteed

by the
declaration of specific
converters

which are automatically invoked upon recognition of the method
arguments (see
http://static.springsource.org/spring/docs/current/spring
-
framework
-
reference/html/validation.html

for more details)
.

In particular, the
@Service

annotation instructs the service publisher that this is a method which
needs t
o be published as a service. Service publishing and OSGi registration is handled by the
backing framework

(obviously, some customization is necessary)
.

The
@RequestMapping

annotations
inform about which arguments need to be exposed while the
@Existing

is a custom annotation
defined by us, delegating a dedicated Spring Validator (again, defined by us) for checking that the
annotated RDF resource is available in the
managed
semantic repository
.

4.5

Automatic
Generation

of Controllers

In Spring, a service
def
inition and
implementation is split into
two areas: the
B
usiness
L
ogic

(BL)
,
and the
C
ontroller
. While the Business Logic represents the inner mechanics of the
service

itself,
the Controller is a sort of front
-
object which acts as a mediator between the
BL

method
and its
publication as a service.

As many of the informations which are specified in the method controller are typically
homogeneo
us in our framework, we prefer

to allow users to write one single method, and let,
through implicit and explicit (i.e.

custom annotations) analysis of its content, a controller method be
generated automatically.

The technology adopted to perform this task (which will be carried automatically at build time) is
represented by the Velocity Template Engine
5
.

4.6

Automatic Generat
ion of Client
API

Probably not to be included with the first release of the system, this aspect deals with the automatic
generation of Client code for querying the system. As Semantic Turkey is still actively maint
ain
ed
as an independent project (and alway
s synced with any modification the integration with
VOCBENCH may require)





5

http://velo
city.apache.org/

5

Status of Design and Development

Development of VOCBENCH 2.0 has been carried on by (partially) following the SCRUM
methodology, with almost regular check points and
the definition
of EPIC areas, describing major
areas of interest in the design of the new platform, STORIES, providing specific improvements,
changes, etc… which needed to be realized and Technical Tasks, with very detailed and specific
implementation objectives to be fu
lfilled.



Figure
1
.
An overview of the 1
2

EPICS of the VOC
BENCH 2.x project


A
n overview of the 12 EPICs driving the main design&development aspects in the realization of
VOCBENCH 2.0
6

is
depicted in
Figure
1
.

5.1

List of JIRA issues

In the next pages, we provide a report about the full list of JIRA issues (including both EPICs,
STORies and Technical Tasks) which detail the status of development o
f the VOCBENCH 2.0
system









6

For interested people connecting to the JIRA project: actually, the EPICs returned
are 13, but one EPIC is related to
the development of Web Services (based on analogous technologies) for getting reports about data from the main FAO
vocabularies. These Web Services are actually a project apart, but did not deserve the creation of a dedicated JIRA
project, so their development has been incorporated inside the VOCBENCH project. They have been cut off from this
representation

5.1.1

[VOCBENCH
-
1]

Innovation on how to automatically publish ST/RDF services
starting from inner system methods
Created: 16/Mar/12

Updated: 17/Oct/12

Status:

In
Progress

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Epic

Priority:


Minor

Reporter:


Armando Stellato


Assignee:


Armando Stellato


Resolution:


Unresolved

Votes:


0

Labels:


Innovation

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified

Environment:


will require deep investigation about technologies for services publication and
how to standardize this process as much
as possible. Obviously, a specific
grounding for our environment is necessary (e.g. it would be great to specify
RDF objects through native OWLART API java objects and get them
marhalled/unmarshalled appropriately).


Issue Links:


Blocks

blocks

VOCBENCH
-
2

Innovat i on on how t o aut omat i cal l y ge...

In Progress


Epic/Theme:

VOCBENCH
-
1, VOCBENCH
-
28



Description





This EPIC deals with making innovation on the way services are
published.

Currently, services are manually written, there are facilities for making code development easy and
making services' code compact and readable, but still there are repeated portions of code related to
serializing/deserializing resources, retriev
ing them from the semantic repository (according to
different strategies: retrieving, check that a resource has alredy been defined, creating it etc..). Also,
all services signatures communicate in terms of string arguments which are passed as arguments to

the service. The service implementation deals with the appropriate deserialization of arguments

The innovation deals with the development of support machinery for:

1) automatically producing the services signature

2) bind it to methods which are closer to

the internal representation of objects

3) automate processing of string arguments fed to the services, to produce the arguments for the
inner methods, according to different management strategies






5.1.2

[VOCBENCH
-
2]

Innovation on how to automatically generate service
consumers
Created: 16/Mar/12

Updated: 16/Oct/12

Status:

In Progress

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Epic

Priority:


Minor

Reporter:


Armando Stellato


Assignee:


Armando Stellato


Resolution:


Unresolved

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified

Environment:


based on technology adopted/developed in EPIC
VOCBENCH
-
1
.

Specific implementations of this general solution, will have to deal with the
technology for the specific considered client layer (e.g. service consumer of the
GWT vocbench client, firefox/javascript functions for ST client, etc...)


Issue Links:


Blocks

is blocked
by

VOCBENCH
-
1

Innovat i on on how t o aut omat i cal l y
pu...

In
Progress


Epic/Theme:

VOCBENCH
-
2



Description





related to EPIC
VOCBENCH
-
1

and strictly depending on it. This EPIC is focused instead on the
automatic generation of services consumers. Ideally, when
VOCBENCH
-
1

is closed, we can move
to this
VOCBENCH
-
2

t realize a unique chain where:

service methods are produced starting from inner methods

service consumers are produced starting from service methods






5.1.3

[VOCBENCH
-
3]

Improving VOCBENCH 1.x client code, which is going to be
reused but needs to be engineered better
Created: 16/Mar/12

Updated: 11/Apr/12

Status:

Open

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Epic

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Sachit Rajbhandari


Resolution:


Unresolved

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified

Environment:


GWT traditional vocbench 1.x client technology


Epic/Theme:

VOCBENCH
-
3



Description





Establish a better separation of roles in the client, to at least be able to assess two layers:

1) pure UI Management

2) service consumer layer

and
then perform these other tasks:

3) establish how RDF resources should be considered in the above 2 layers (OWLART? at least in
the consumer layer, other in the UI? still OWLART?)

4) implement the separation. In theory, results of EPIC
VOCBENCH
-
2

can make the development
of the consumer layer trivial, but in the initial phase of the project, we'll be targeting an immediate
wiring of ST and VOCBENCH with what we have now.






5.1.4

[VOCBENCH
-
4]

Wiring up Vocbench Client to Semantic Turkey SKOSXL
services
Created: 16/Mar/12

Updated: 11/Apr/12

Status:

Open

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Epic

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Sachit Rajbhandari


Resolution:


Unresolved

Votes:


0

Labels:


prototype

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified

Environment:


GWT and other specific Vocbench 1.x technologies adopted in the client layer

Understanding ST services (no need to go deep inside

their implementation)


Epic/Theme:

VOCBENCH
-
4



Description





The outcome should be the first prototypical e implementation of VOCBENCH 2.X






5.1.5

[VOCBENCH
-
5]

OWL Support

Created: 16/Mar/12


Updated: 16/Oct/12

Status:

In Progress

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Epic

Priority:


Minor

Reporter:


Armando Stellato


Assignee:


Armando Stellato


Resolution:


Unresolved

Votes:


0

Labels:


OWL

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified

Environment:


OWLART

ST Services

VOCBENCH UI

RDF Languages Expertise needed


Epic/Theme:

VOCBENCH
-
5



Description





This EPIC deals
with everything related to the support of OWL modeling inside the Vocbench.

Semantic Turkey has already a (partial) support for OWL modeling, so this could initially start from
supporting the already existing services of ST inside VOCBENCH, but this can al
so proceed in
parallel on ST services to improve OWL support






5.1.6

[VOCBENCH
-
6]

Implementing VOCBENCH specific functionalities not available
in ST

Created: 16/Mar/12

Updated: 24/Sep/12

Status:

In Progress

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Epic

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Armando Stellato


Resolution:


Unresolved

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified

Environment:


ST Services


Epic/Theme:

VOCBENCH
-
6



Description





This EPIC covers the realization of services which are currently not

available in the standard suite
of ST services, but which are needed to be compliant with the standard way VOCBENCH retrieves
information from the semantic repository.

In fact, ST (intended as the original desktop platform) may expose different approaches

on the way
resources are managed or their content is being retrieved. For instance, ST has a resource editor
retrieving in a single request all the information associated to a single resource, while VOCBENCH
has different TABS in the equivalent panel, whi
ch submits more specific queries for being
populated.






5.1.7

[VOCBENCH
-
7]

Implementing EUROVOC specific functionalities not available
in ST / VOCBENCH

Created: 16/Mar/12

Updated: 16/Oct/12

Status:

In Progress

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Epic

Priority:


Minor

Reporter:


Armando Stellato


Assignee:


Armando Stellato


Resolution:


Unresolved

Votes:


0

Labels:


EUROVOC

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified

Environment:


OWLART

ST Services

VOCBENCH UI

RDF Languages Expertise needed


Epic/Theme:

VOCBENCH
-
7



Description





EUROVOC has specific requirements for their "ideal" thesauri management tool. There is a large
overlap between EUROVOC reqs and our objectives for VOCBENCH 2.0, though there is a set of
functionalities considered as mandatory for them and prioritized by us
.
This EPIC deals with all
these kind of functionalities.






5.1.8

[VOCBENCH
-
8]

Assuring ST services scale well and are well founded for
multiuser management
Created: 16/Mar/12

Updated: 25/Sep/12

Status:

Open

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Epic

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Armando Stellato


Resolution:


Unresolved

Votes:


0

Labels:


Concurrency, MultiUser, Thread
-
Safety

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified

Environment:


ST Services

OWLART

Specific OWLART Implementation (maybe Sesame2, OWLIM, etc...)


Epic/Theme:

VOCBENCH
-
8



Description





ST is a desktop tool (though it is being developed through a 3
-
tier layer and offers http ajax
services).

In this sense, it has not been ever tested against multiuser/concurrent access/thread safety scenarios.

This EPIC deals with any issue which may be related to these topics.






5.1.9

[VOCBENCH
-
9]

DATA Layer: scalability, performance

Created: 16/Mar/12

Updated:
12/Apr/12

Status:

Open

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Epic

Priority:


Minor

Reporter:


Armando Stellato


Assignee:


Armando Stellato


Resolution:


Unresolved

Votes:


0

Labels:


Data, Ontology

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified

Environment:


ST Services / STOntologyManager

OWLART

Specific OWLART Implementation (Sesame2, OWLIM, etc...)


Epic/Theme:

VOCBENCH
-
9



Description





Everything related to the Data Management aspects of the architecture, from meta
-
modeling issue
to merely technological aspects and associated aspects such as performance, scalability etc...






5.1.10

[VOCBENCH
-
10]

Improving ST functionalities already existing, but not
satisfying VOCBENCH requirements

Created: 16/Mar/12

Updated: 16/Oct/12

Status:

In Progress

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Epic

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Armando Stellato


Resolution:


Unresolved

Votes:


0

Labels:


None

Σ Remaining
Estimate:

Not Specified

Remaining
Estimate:

Not Specified

Σ Time Spent:

乯琠N灥c楦楥搠

Time Spent:

Not Specified

Σ Original
Estimate:

Not Specified

Original
Estimate:

Not Specified

Environment:


ST Services

OWLART


Sub
-
Tasks:

Key

Summary

Type

Status

Assignee

VOCBENCH
-
64


creating methods
for atomic creation
...


Technical task

Open

Andrea Turbati




Epic/Theme:

VOCBENCH
-
10



Description





This differentiates from other EPIC
VOCBENCH
-
6

in that it deals with functionalities already
existing in ST but which maybe fail to satisfy the behaviour expected in VOCBENCH.

Whenever some functionality falls in the above description, the case should be studied carefully, a
decision should be taken i
f to:



keep the original functionality and duplicate it in a different interpretation for the
VOCBENCH



finding the proper solution covering both exigencies



adjusting ST to cover a maybe better interpretation in the VOCBENCH



adjusting VB UI to cover the
original functionality in ST






5.1.11

[VOCBENCH
-
12]

Web Services for accessing Vocabulary LOD Content

Created:
03/Apr/12

Updated: 18/Jun/12

Status:

In Progress

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Epic

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Armando Stellato


Resolution:


Unresolved

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified


Epic/Theme:

VOCBENCH
-
12





5.1.12

[VOCBENCH
-
14]

Deciding how to access ST (methods
or services?)

Created:
11/Apr/12

Updated: 20/Sep/12

Resolved: 20/Sep/12

Status:

Closed

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Story

Priority:


Blocker

Reporter:


Armando Stellato


Assignee:


Sachit
Rajbhandari


Resolution:


Fixed

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified


Epic/Theme:

VOCBENCH
-
4



Comments





Comment by
Armando Stellato

[
20/Sep/12

]

For the moment, ST is accessed by Vocbench through calls to ST's services.

When ST (not a short term objective) will be offering a double
interface, based on Java/Web
Service interaction (probably by exploiting Spring), then we will consider back an interface with
native java calls.





5.1.13

[VOCBENCH
-
15]

Writing a ST Service Consumer
for VOCBENCH UI

Created: 11/Apr/12

Updated: 12/Apr/12

Status:

Open

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Story

Priority:


Critical

Reporter:


Armando Stellato


Assignee:


Sachit Rajbhandari


Resolution:


Unresolved

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified


Epic/Theme:

VOCBENCH
-
4





5.1.14

[VOCBENCH
-
16]

Check WS definitions in:
http://aims.fao.org/tools/vocbench
-
2/web
-
services

Created: 12/Apr/12

Updated: 12/Apr/12

Status:

Open

Project:

VOCBENCH

Component/s:

None

Affects
Version/s:

None

Fix Version/s:

None


Type:


Story

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Andrea Turbati


Resolution:


Unresolved

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified


Epic/Theme:

VOCBENCH
-
12





5.1.15

[VOCBENCH
-
17]

Create new web services implementations (replicating the
already existing ones) based on OWLART

Created: 12/Apr/12

Updated: 12/Apr/12

Status:

Open

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Story

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Andrea Turbati


Resolution:


Unresolved

Votes:


0

Labels:


None

Σ Remaining
Estimate:

Not Specified

Remaining
Estimate:

Not Specified

Σ Time Spent:

乯琠N灥c楦楥搠

Time Spent:

Not Specified

Σ Original
Estimate:

Not Specified

Original
Estimate:

Not Specified


Sub
-
Tasks:

Key

Summary

Type

Status

Assignee

VOCBENCH
-
20


Creating the WS
BL
Implementation on
...


Technical task

Open

Andrea Turbati



VOCBENCH
-
21


Creating the WS
publication code
wrap...


Technical task

Open

Andrea Turbati




Epic/Theme:

VOCBENCH
-
12





5.1.16

[VOCBENCH
-
18]

Create a new set of WSs based on a RESTful approach, which
can be put as search URLs (URI lookup and text search following open search
paradigm) on the VoID description of Agrovoc

Cr
eated: 12/Apr/12

Updated: 12/Apr/12

Status:

Open

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Story

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Andrea Turbati


Resolution:


Unresolved

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified


Epic/Theme:

VOCBENCH
-
12





5.1.17

[VOCBENCH
-
19]

Create a new full text search
engine for OWLART. Maybe
create a new one, as well as try to integrate existing technologies as
extensions for Sesame2, and just create the fulltext search interface over it.

Created: 12/Apr/12

Updated: 12/Apr/12

Status:

Open

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Story

Priority:


Blocker

Reporter:


Armando Stellato


Assignee:


Armando Stellato


Resolution:


Unresolved

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified


Issue Links:


Relates

relates to

VOCBENCH
-
20

Creat i ng t he WS BL Impl ement at i on on ...

Open


Epic/Theme:

VOCBENCH
-
12





Create new web services implementations (replicating the already existing ones) based on
OWLART

(
VOCBENCH
-
17
)


5.1.18

[VOCBENCH
-
20]

Creating the WS BL Implementation on OWLART

Created:
12/Apr/12

Updated: 12/Apr/12

Status:

Open

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Technical task

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Andrea Turbati


Resolution:


Unresolved

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified


Issue Links:


Relates

relates to

VOCBENCH
-
19

Creat e a new ful l t ext search engi ne ...

Open


Epic/Theme:

VOCBENCH
-
12



Comments





Comment by
Armando Stellato

[
12/Apr/12

]

This is not a strict dependency. Just some of the WS implementations need

to rely on a full text
search engine.

Proceed with this task (and all other tasks in this story) and just wait for the search engine to be
available before adding those services performing a full text search

Comment by
Armando Stellato

[
12/Apr/12

]

The WS Business Logic (at least the onre related to services which export plain RDF code) maybe
realized through the new method (update to last version of OWLART from SVN)

for writing RDF
starting from an iterator over statements.
The method is writeRDF, available from class:
BaseRDFTripleModel





Create new web services implementations (replicating the already

existing ones) based on
OWLART

(
VOCBENCH
-
17
)


5.1.19

[VOCBENCH
-
21]

Creating the WS publication code wrapping the BL of
previous task

Created:

12/Apr/12

Updated: 12/Apr/12

Status:

Open

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Technical task

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Andrea Turbati


Resolution:


Unresolved

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified


Epic/Theme:

VOCBENCH
-
12





5.1.20

[VOCBENCH
-
22]

Develop a clearly defined
service access layer which is
separated from the UI code

Created: 12/Apr/12

Updated: 16/Oct/12

Resolved: 16/Oct/12

Status:

Closed

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Story

Priority:


Blocker

Reporter:


Armando Stellato


Assignee:


Sachit Rajbhandari


Resolution:


Fixed

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified


Epic/Theme:

VOCBENCH
-
3





5.1.21

[VOCBENCH
-
23]

Mavenize the whole VOCBENCH CLIENT project.

Created: 12/Apr/12

Updated: 16/Oct/12

Resolved: 16/Oct/12

Status:

Closed

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Story

Priority:


Blocker

Reporter:


Armando Stellato


Assignee:


Sachit Rajbhandari


Resolution:


Fixed

Votes:


0

Labels:


None

Σ Remaining
Estimate:

Not Specified

Remaining
Estimate:

Not Specified

Σ Time Spent:

乯琠N灥c楦楥搠

Time Spent:

Not Specified

Σ Original
Estimate:

Not Specified

Original
Estimate:

Not Specified


Sub
-
Tasks:

Key

Summary

Type

Status

Assignee

VOCBENCH
-
24


Set all the
dependencies on
Maven.
Us...


Technical
task

Closed

Sachit Rajbhandari



VOCBENCH
-
25


Check if there are
any GWT Maven
plug...


Technical
task

Closed

Sachit Rajbhandari



VOCBENCH
-
26


Setup the project
to obtain an
automa...


Technical
task

Closed

Sachit Rajbhandari




Epic/Theme:

VOCBENCH
-
3





Mavenize the whole VOCBENCH CLIENT project.

(
VOCBENCH
-
23
)


5.1.22

[VOCBENCH
-
24]

Set
all the dependencies on Maven. Use repositories (such
as clo
-
jars) to add third party libraries if necessary.

Created: 12/Apr/12

Updated: 31/Jul/12

Resolved: 31/Jul/12

Status:

Closed

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Technical task

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Sachit Rajbhandari


Resolution:


Fixed

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified


Epic/Theme:

VOCBENCH
-
3



Comments





Comment by
Armando
Stellato

[
03/May/12

]

may I close this one?

Comment by
Sachit Rajbhandari

[
04/May/12

]

Following dependencies couldn't be found in the repositories. Please let me know if
you are aware
of any repositories for these libraries. Otherwise we can put them to clo
-
jars and close this issue.

<dependency>

<groupId>edu.stanford.smi.protege</groupId>

<artifactId>protege
-
owl</artifactId>

<version>3.4.1</version>

</dependency>

<depende
ncy>

<groupId>edu.stanford.smi.protege</groupId>

<artifactId>protege</artifactId>

<version>3.4.1</version>

</dependency>

<dependency>

<groupId>it.uniroma2.art.owlart</groupId>

<artifactId>owlart
-
indexer</artifactId>

<version>0.0.2
-
SNAPSHOT</version>

</dep
endency>

<dependency>

<groupId>it.uniroma2.art.owlart</groupId>

<artifactId>owlart
-
protegeimpl</artifactId>

<version>0.0.1
-
SNAPSHOT</version>

</dependency>

Comment by
A
rmando Stellato

[
05/Jun/12

]

Regarding indexer and owlart
-
protegeimpl, if you have the jars, better to put them on clojars
(maybe save them as non
-
snapshot).

Regarding the Protege libs, it is strange, I originally simply imported them from MavenCentral,

but
now they seem to be not present anymore. You can put them on clojars as well then close the task.

Comment by
Sachit Rajbhandari

[
31/Jul/12

]

Following dependent jars has
been added to clojars

<dependency>

<groupId>it.uniroma2.art.owlart</groupId>

<artifactId>owlart
-
protegeimpl</artifactId>

<version>0.0.1</version>

</dependency>

<dependency>

<groupId>edu.stanford.smi</groupId>

<artifactId>protege
-
owl</artifactId>

<version>3
.4
-
betas
-
build
-
130</version>

<type>jar</type>

<scope>compile</scope>

</dependency>

<dependency>

<groupId>edu.stanford.smi</groupId>

<artifactId>protege</artifactId>

<version>3.4
-
betas
-
build
-
130</version>

<type>jar</type>

<scope>compile</scope>

</dependency
>

<dependency>

<groupId>it.uniroma2.art.owlart.indexer</groupId>

<artifactId>owlart
-
indexer</artifactId>

<version>0.0.2</version>

</dependency>

Comment by
Sachit Rajbhandari

[
31
/Jul/12

]

Necessary jars has been uploaded to clojars.org





Mavenize the whole VOCBENCH CLIENT project.

(
VOCBENCH
-
23
)


5.1.23

[VOCBENCH
-
25]

Check if there are any GWT Maven plugins that can be used
to build and deploy the VOCBENCH client project

Created: 12/Apr/12

Updated: 03/May/12

Resolved: 03/May/12

Status:

Closed

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Technical task

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Sachit Rajbhandari


Resolution:


Fixed

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified

Environment:


Maven, GWT


Issue Links:


Blocks

blocks

VOCBENCH
-
26


Set up t he proj ect t o obt ai n an aut oma...

Cl osed


Epic/Theme:

VOCBENCH
-
3



Comments





Comment by
Armando Stellato

[
12/Apr/12

]

I (Armando) found this:

http://mojo.codehaus.org/gwt
-
maven
-
plugin/

Sachit, check if there are other plugins which you may retain more satisfying for our needs, or mark
this task as completed and go ahead to

Comment by
Armando Stellato

[
03/Ma
y/12

]

Issue closed. The chosen Maven GWT plugin has been adopted by Sachit for the Mavenization of
VOCBENCH





Mavenize the whole VOCBENCH CLIENT project.

(
VOCBENCH
-
23
)


5.1.24

[VOCBENCH
-
26]

Setup the project to obtain an automatic build
-
deployment
through Maven

Created: 12/Apr/12

Updated:
31/Jul/12

Resolved: 31/Jul/12

Status:

Closed

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Technical task

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Sachit Rajbhandari


Resolution:


Fixed

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified


Issue Links:


Blocks

blocks

VOCBENCH
-
27

Real i zi ng an i nt egrat ed ST
-
VOCBENCH
d...

Open

i s bl ocked
by

VOCBENCH
-
25


Check i f t here are any GWT Maven
pl ug...

Cl osed


Epic/Theme:

VOCBENCH
-
3



Comments





Comment by
Sachit Rajbhandari

[
31/Jul/12

]

VocBench Client has been mavenized.





5.1.25

[VOCBENCH
-
27]

Realizing an integrated ST
-
VOC
BENCH deployment solution

Created: 12/Apr/12

Updated: 12/Apr/12

Status:

Open

Project:

VOCBENCH

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None


Type:


Story

Priority:


Major

Reporter:


Armando Stellato


Assignee:


Sachit Rajbhandari


Resolution:


Unresolved

Votes:


0

Labels:


None

Remaining
Estimate:

Not Specified

Time Spent:

Not Specified

Original
Estimate:

Not Specified


Issue Links:


Blocks

is blocked by

VOCBENCH
-
26


Set up t he proj ect t o obt ai n an aut oma