Multilanguage Semantic Interoperability in Distributed Applications

JOSI is a soware framework that tries to simplify the development of such kinds of applications both by providing the possibility of working on models for representing such semantic information and by offering some implementations of such models that can be easily used by soware developers without any knowledge about semanticmodels and languages.is soware library allows the representation of domain models through Java interfaces and annotations and then to use such a representation for automatically generating an implementation of domain models in different programming languages (currently Java and C++). Moreover, JOSI supports the interoperability with other applications both by automatically mapping the domain model representations into ontologies and by providing an automatic translation of each object obtained from the domain model representations in an OWL string representation.


Introduction
Semantic information is assuming more and more importance both for the development of knowledge-based applications and for supporting the interoperability among different applications [1][2][3][4].In particular, ontologies have been gaining interest for the representation of the application domain models and their use has been spreading in different applications �elds [5][6][7][8].
Domain models are increasingly speci�ed as formal ontologies through the use of a semantic Web language (e.g., OWL [9,10]), but such models remain difficult to be utilized in applications developed through the used soware languages and libraries.In fact, the mapping of such models into the code of a typical application development language oen is not possible because of the different expressive power of the modeling and the implementation language.Moreover, when it is possible, the obtained implementation is too complex to be used by the large part of soware developers.
However, the development of domain models that represent semantic information is very difficult without the use of a semantic language.To cope with this problem, a possible direction is to integrate usual programming techniques with some meta-programming techniques.In particular, the Java programming language supports metaprogramming through annotations and re�ection [11].In fact, while annotations allow the decoration of the Java code with new concepts and idioms, re�ection allows the retrieval of the information associated with annotations and then to use them for either modifying the usual execution of the Java code or for building new Java code.
In this paper, we present a soware framework, called JOSI (Java and OWL for System Interoperability), whose goal is to simplify the development of the soware libraries for managing the data that implement the domain models shared by the systems of a distributed enterprise application.e next section introduces related work on the use of annotations for the development of soware and on the mapping between OWL ontologies and Java code.Section 3 describes the JOSI soware framework.Section 4 describes how a domain model is represented.Section 5 presents how an implementation of a domain model is built starting from its JOSI representation.Section 6 introduces how domain model implementations are used in a soware application.Sections 7 and 8 represent and discuss the experimentation of the JOSI soware framework.Finally, Section 9 concludes the paper sketching some future research directions.

Related Work
e idea of using Java annotations for extending the Java language is not new and several research teams worked in that direction.
AspectJ [12] is probably the �rst important work that shows how Java annotation can provide a meta-programming layer on the top of Java programming structures.In particular, AspectJ is an aspect-oriented extension of the Java programming language that uses Java annotations for realizing declaring aspects, point-cuts, and advices.
Andreae et al. [13] proposed a soware framework that supports pluggable type systems in the Java programming language by the de�nition of custom constraints on Java types through Java annotations.
AVal [14] is a soware framework for the de�nition and checking of rules for programs written by using an attribute domain-speci�c built on the top of Java.is soware framework allows the validation of such kinds of program through a set of prede�ned Java annotations.Moreover, it allows to the users of the framework to add new annotations to provide new kinds of validation.
Bordin and Vardanega [15] used Java annotations to embed in the source code a declarative speci�cation of the required concurrent semantics and then for producing the source code that implements the declared concurrent semantics.
Cimadamore and Viroli [16] proposed a soware framework that tried to simplify the seamless integration of Prolog code into Java applications taking advantage of Java annotations to incorporate the declarative features of Prolog into Java programs.
A lot of work has been done also towards the mapping of OWL ontologies into Java code and vice versa.
e �rst important work that shows the partial translation of OWL ontologies in Java code is the Protégé Bean Generator [17].In particular, it transforms Protégé frame-based ontologies into Java source code for developing JADE agents [18,19].
RDFReactor [20] is a toolkit for dynamically accessing an RDF model through domain-centric methods (getters and setters).In particular, it allows the access to the RDF model through a set of proxy objects that provide the methods for querying and updating the RDF elements.
A more sophisticated approach was presented by Kalyanpur et al. [21].is approach deals with issues as multipleinheritance by mapping OWL classes in Java interfaces.However, there is not a soware tool which takes advantage of this approach for mapping OWL ontologies into Java code.
SeRiDA [22] is a methodology for enabling a three-tier mapping along ontologies, object-oriented java beans and relational database.In particular, it allows the generation of both an object-oriented and a relational model starting from a domain conceptualization expressed in OWL.is methodology has been experimented by realizing a soware tool that generates programming interfaces as enterprise Java beans and Hibernate object-relational mappings from OWL ontologies.
Quasthoff and Meinel [23] presented a mechanism that allows application developers, with limited knowledge about RDF and OWL, to easily map arbitrary Java classes and interfaces to corresponding OWL concepts by using Java annotations.In particular, this mechanism has already been experimented in the development of a social network application testing new access control mechanisms on usergenerated content with the help of Semantic Web rules [19].
OWLET [24] is a Java soware environment based on an object-oriented model, which allows a simple and complete representation of ontologies de�ned by using OWL DL pro�le, and provides a complete set of reasoning functions together with a graphical editor for the creation and modi-�cation of ontologies.OWLET supports the development of heterogeneous and distributed semantic systems where nodes differ for their capabilities (i.e., CPU power, memory size, etc.).In fact, it offers a layered reasoning API that allows to deploy a system where high power nodes take advantages of all the OWLET reasoning capabilities, medium power nodes take advantages of a limited set of OWLET reasoning capabilities (e.g., reasoning about individuals) and low power nodes delegate reasoning tasks to the other nodes of the system.
Finally, the OWL API can be considered the reference Java API for managing ontologies [25,26].In fact, besides providing the manipulation of ontologies, it offers: a general purpose reasoner interfaces, the validators for the various OWL pro�les, and the support for parsing and serializing ontologies in a variety of syntaxes.e API also has a very �exible design that allows third parties to provide alternative implementations for all major components.
Different works cope with the problem of de�ning models for integrating different data sources in enterprise information systems.
Astrova and Kalja [27] proposed an approach for system interoperability that maps relational database schemas into OWL ontologies and allows an improvement of database schemas by identifying "hidden" (implicit) semantic relationships and bad design solutions.
Lin and Harding [28] proposed a general manufacturing system engineering knowledge representation scheme to facilitate communication and information exchange in interenterprise, multidisciplinary engineering design teams.It has been developed and encoded in the standard semantic web language.e proposed approach focuses on how to support information autonomy that allows the individual team members to keep their own preferred languages or information models rather than requiring them all to adopt standardized terminology.
Salguero et al. [29] proposed a framework which encompasses the entire data integration process.e data source schemas as well as the integrated schema are expressed using an OWL extension which allows the incorporation of metadata to support the integration process.

Software Framework Overview
JOSI (Java and OWL for System Interoperability) is a soware framework that tries to simplify the development of the soware libraries for managing the data that implement the domain models shared by the systems of a distributed enterprise application.
e main features of such soware library are as follows: (i) a strict separation between the representation of a domain model and its implementation, (ii) an automatic generation of an implementation of the representation of the domain model in different programming languages; (iii) an automatic generation of an OWL ontology from the representation of a domain model and vice versa, and (iv) the possibility of using an OWL string representation of the domain model data to support the interoperability between systems implemented in different programming languages and so the possibility of translating domain model data to OWL string representations and vice versa.
JOSI is implemented in Java and takes advantage of Java interfaces and annotations to build a representation of a domain model and uses Java re�ection to drive the processing of the information maintained by such interfaces and annotations for generating the source code of the classes that de�ne the concrete implementation of the domain model.
e following sections will describe how a domain model is represented through Java interfaces and annotations, how the Java classes providing a concrete implementation of such a domain model are generated from such interfaces and annotations, and how such a soware framework enables an application to use a concrete implementation of a domain model.T 1: Java annotations used in the representation of a domain model.@Abstract @Getter @Name @Symmetric @AllValuesFrom @HasValue @Ordered @SomeValuesFrom @Binding @Immutable @Set @Transitive @Cardinality @InverseOf @Setter @Version

Domain Model Representation
A domain model is represented by a set of Java interfaces.Each domain entity is represented by a Java interface (from here called entity interface) that de�nes the two methods for reading and modifying its attributes.Moreover, an additional Java interface (from here called factory interface) provides both some general information about the domain model and the factory methods for the creation of the Java classes which implement the different entity interfaces.Figures 1  and 2 show some entities of two domain models represented through the use of Java interfaces and annotations.Table 1 lists the Java annotations used in the representation of a domain model.
To support the creation of the implementation of such entities, each Java interface is enriched by some Java annotations and constant declarations.
e two annotations: @Getter and @Setter are applicable to the entity interface methods and de�ne the reading and modifying methods of a speci�c attribute.e type of the [] } F 2: Two entities of a domain model describing the life-cycle of a soware agent.
attribute is identi�ed by both the return type of the reading method and the type of the argument of the modifying method (of course they need to identify the same type).In particular, the value of any attribute must be: a Java primitive data, an instance of the String class, an instance of a class implementing an entity interface, or an array of the previous kinds of value.
e four annotations: @Abstract, @Immutable, @OneOf, and @Singleton, are applicable to the entity interfaces.e �rst annotation identi�es an abstract entity, that is, an entity that does not have any direct implementation.e second annotation identi�es an entity that has an immutable implementation, that is, the interface cannot de�ne methods that modify the value of its attributes and the implementation of its reading methods will be de�ned to return either the value of an attribute (if it is an immutable value) or a copy of the value (if it is a mutable value).e third annotation is used for identifying entities that have an extensional description (e.g., that can be de�ned through an enumeration).Finally, the forth annotation is used for the de�nition of some special entities that can be represented by a single class object.
Oen the use of an implementation of a domain model inside an application needs the availability of operations for the comparison and ordering of their entities.In a Java implementation, such operations can be performed by implementing the compareTo, equals, and hashCode methods.e annotation @Comparator is introduced for this scope.In fact, it identi�es the sequence of attributes on which the previous three methods must work.
In a domain model oen is necessary both to restrict the value that some attributes can assume and to establish a relationship between the attributes of some entities.It is done by associating some additional annotations to the reading methods of the entity interfaces.
e four annotations: @AllValueFrom, @SomeValues-From, @Cardinality, and @HasValue, de�ne the most known constraints that OWL applies to the properties of an ontology.In particular, the �rst annotation constrains the values of an attribute to belong to speci�c type (of course, an implicit constraint of such a kind, is de�ned when the reading and modifying methods of an attributed are de�ned.�owever, an additional constraint can be added by imposing that the values of an attribute must belong to a subtype of the declared attribute type).e second annotation imposes that some of the values of an attribute must belong to a speci�c type (of course, such a type must be a subtype of the declared attribute type).e third annotation imposes that an attribute can have either a �xed number of values or a variable number of values de�ned by a minimum and�or a maximum value.Finally, the forth annotation imposes that an attribute must always contain some values (in this case, for the limited set of value types that can be associated with the attributes of an annotation, the values of such constraints are de�ned through constant variables and the annotations refer to the names of such constant variables).
In some cases it can be necessary to impose that an attribute does not have duplicated values and that its values are maintained ordered: the two annotations: @Set, and @Ordered, impose the previous two constraints (in particular, the second constraint is implemented either by using the natural ordering between values or the ordering de�ned by the compareTo method built through the @Comparator annotation introduced above).
e three annotations: @InverseOf, @Symmetric, and @Transitive, de�ne the most known constraints that ��L applies to the relationship between properties of an ontology.e �rst annotation de�nes an inverse relationship between attributes.e second annotation de�nes a symmetric relationship between the entities that have such kind of attribute.Finally, the third annotation de�nes a transitive relationship between the entities that have such kind of attribute.
Finally, the two annotations: @Name and @Version, are applicable to the factory interfaces: the �rst annotation indicates the name associated with the domain model and the second annotation identi�es the version of the model.Lastly, the annotation @Binding is associated with a factory method of a model interface.is annotation identi�es the attribute that each argument of the factory method will initialize.

Domain Model Implementation
� domain model representation, de�ned as described in the previous sections, contains all the information for building an implementation of such a domain model.is implementation is realized by an annotation processor that builds a Java class for each Java interface of the model.Figures 3 and 4 show the source code of the Java classes obtained through the naming domain model introduced in the previous section.e result of such an annotation processor is a set of Java �les.Each Java �le contains the source code of a class that implement an interface of the domain model representation.Moreover, each class that implements an entity interface provides a method for building an OWL string representation of an entity class instance, and each class that implements a model interface provides a method for building an entity class instance from its OWL string representation.
e annotation processor used for generating the domain model implementation is composed by two soware modules.e �rst module, called processing module, e�tracts the information from the domain model representation, generates an intermediate representation and then calls the second module.en the second module, called generation module, builds the domain model implementation from the intermediate representation.
e intermediate representation is based on a two level tree where the root object maintains the information about the model interface and each leaf object maintains the information about an entity interface.
e processing module is independent from the implementation of the generation module because it calls a generation module by a Java interface and the generation module implementation is a parameter of the processing module constructor.erefore, it is very easy to provide different implementations of some domain model representations by de�ning new generation modules able to process in different ways the intermediate representation built by the processing module.In particular, the current version of the soware framework provides another generation module which builds OWL ontologies from the domain model representations and stores them in RDF format [30].

Domain Model Application
Aer the creation of an implementation of a domain model, its use inside an application is very simple.In fact, the JOSI soware framework provides a class, called DataStore, which has the duty of both maintaining the information about the different domain models available for the current application and providing the access to their implementation through the creation of an instance of the class that implements their domain interface.In particular, the Datastore instance can access to the list of the domain models used by the application through a property �le.erefore, aer the creation of an instance of the Data-Store class, the code of the application can create instances of any class implementing the factory interface of a domain model and then use it for creating instances implementing any entity interface of such a domain model.Figure 5 shows a sample of Java code performing the operations described above.

Experimentation
We are using the JOSI soware framework for the development of the models and then the implementations of the data necessary for supporting the basic interactions among the components of a distributed system realized through the HDS soware framework.Moreover, JOSI was experimented for de�ning the domain models of some applications in the �elds of distributed information sharing and social networks.
HDS (Heterogeneous Distributed System) is a soware framework that tries to simplify the realization of pervasive applications by merging the client-server and the peer-topeer paradigms and by implementing all the interactions among the processes of a system through the exchange of typed messages and the use of composition �lters for driving and dynamically adapting the behavior of the system [31].
Typed messages are one of the elements that mainly characterize such a soware framework.In fact, typed messages can be considered an object-oriented "implementation" of the types of message de�ned by an agent communication language and so they are means that make HDS a suitable soware framework both for the realization of multiagent systems and for the reuse of multiagent model and techniques in nonagent based systems.
In particular, the type of a message is de�ned by its content and its content is de�ned by an entity of a speci�c domain model de�ned with the JOSI soware framework.erefore, we used JOSI foe the de�nition of the domain models that support the basic interaction among HDS processes, that is, the managing of the processes themselves and of the resources that can they used in a distributed application.Moreover, we used JOSI for de�ning the domain models used for realizing the typical coordination algorithms of intelligent distributed systems.
RAIS (Remote Assistant for Information Sharing) is a peer-to-peer multiagent system supporting the sharing of information among a community of users connected through the Internet [32].RAIS offers search facility similar to Web search engines, but it avoids the burden of publishing the information on the Web and it guaranties a controlled and dynamic access to information through the use of agents.e use of agents in such a system is very important because it simpli�es the realization of the three main services: (i) the �ltering of the information coming from different users on the basis of the previous experience of the local user; (ii) the pushing of the new information that can be of possible interest for a user; and (iii) the delegation of access capabilities on the basis of a network of reputation built by the agents on the community of users.
RAIS is composed of a dynamic set of agent platforms connected through the Internet.In this case, JOSI has been used for the de�nition of the domain models supporting the de�nition of the interaction of agents for the retrieval and pushing of the information and for the management of the user pro�les.
About the applications in the �eld of the social networks, we are starting the development a system for the study of the most known social networks and, in particular, of the social networks that provide semantic support for the management of both the pro�les and the information published by the users [33].
In particular, we built a system that can simulate the behavior of some of the most known social networks and can compare them with some enhanced versions of such networks that provide semantic support through the use of JOSI domain models.In particular, we de�ned some domain models for representing the user pro�les of different social networks and some domain models for supporting users in the publishing and retrieval of information related to some sample topics (e.g., computer science and music).

Experimental Results
e results of the experimentation of the soware framework showed that the de�nition of a domain model can be done by any programmer with knowledge about the Java programming language, but does not require any knowledge about any knowledge engineering and semantic Web techniques and technologies.Moreover, if the entities of a domain model are de�ned as immutable objects, then the performance of managing such entities is similar to the one of managing JavaBean objects.
Other important results come from some tests that compared the result of the work of groups of students, which developed domain models using JOSI, with the work of other groups of students, which developed domain models without using it.In fact, while the �rst set of groups developed the domain model in few time spending a very limited part of it for code correction, the second set of groups developed the domain model in a very long time spending its large part for code correction.Moreover, the performance measures of the tests showed that the implementations of the domain model based on the JOSI framework provided better measures or at least similar to the ones provided by the "custom" implementations.Of course, while the use of JOSI guaranteed implementations in different programming languages (currently Java and C++) without additional costs, it was not true for "custom" implementations.

Conclusion
is paper presented a soware framework, called JOSI (Java and OWL for System Interoperability), that has the goal of simplifying the development of the soware libraries for managing the data that implement the domain models shared by the systems of a distributed enterprise application.
is soware framework allows to represent a domain model through Java interfaces and annotations and then to use such a representation for automatically generating a Java implementation of the domain model.Moreover, it provides the interoperability with other kinds of systems both automatically mapping the Java domain representation in an OWL ontology and providing an automatic translation of each object de�ned by the domain model representation in an OWL string representation.
JOSI derived from O3L (Object-Oriented Ontology Library), a soware library that provides a complete representation of ontologies compliant with OWL 2 W3C [34].O3L has not the goal to be used for the creation and manipulation of ontologies, but provides a simpli�ed and e�cient API for the realization of applications, that interoperate through the use of shared ontologies, and allows: (i) the use of OWL individuals as data of the applications, (ii) the exchange of OWL individuals between applications, (iii) the reasoning about OWL individuals, and (iv) the classi�cation of OWL classes and properties.e experimentation of O3L showed that it is a powerful means for developing applications but with two main limits: developers must have a good knowledge of semantic techniques and technologies and oen applications cannot provide the required performances.
Current and future research activities are dedicated, besides to continue the experimentation of the current implementation of JOSI, to: (i) the development of a soware generation module that allows the automatic generation of a C++ and Python implementation from a JOSI model representation, (ii) the generation of a JOSI model representation from an OWL ontology compliant with the JOSI domain model representation, (iii) the generation of OWL ontologies compliant with such a representation from OWL ontologies that contain classes and properties that cannot be de�ned through the annotations de�ned in the JOSI soware framework, (iv) the introduction of new annotations for increasing the expressive power of the JOSI model representation.

F 3 :
Java implementation of the entities of the naming domain model.

F 4 :
Java implementation of the model of the naming domain model.

F 5 :
Java code for creating instances of the entities of two domain models.