José Luis Aguirre
email: luis.aguirre@inria.fr

José Luis

Aguirre Cervantes

Aguirre Wrote

prototype ⊠ report dissemination Dissemination level public consortium

Keywords: ontology matching, ontology alignment, evaluation, benchmarks, efficiency measure

for dissemination)

This deliverable reports on the current status of the service implementation for the automatic evaluation of matching tools, and on the final status of those services. These services have been used in the third SEALS evaluation of matching systems, held in Spring 2012 in coordination with the OAEI 2011.5 campaign. We worked mainly on the tasks of modifying the WP12 BPEL work-flow to introduce new features introduced in the RES 1.2 version; testing the modified work-flows on a local installation and on the SEALS Platform; writing transformations of result data to be compliant with the new SEALS ontologies specifications; and finally, extending the SEALS client for ontology matching evaluation for better supporting the automation of WP12 evaluation campaigns and to advance in the integration with SEALS repositories. We report the results obtained while accomplishing these tasks.

Executive Summary

The aim of this deliverable is to report on the work that has been done in the last phase of task 12.5: iterative implementation of services for automatic evaluation of matching tools, and on the final status of those services. Since the previous iteration, reported in [START_REF] Trojahn | Iterative implementation of services for the automatic evaluation of matching tools[END_REF], we have been working on the following main tasks:

• extending the previous BPEL workflows in order to integrate the new custom services and fault handlers ( §2);

• experimenting with the new release of SEALS RES environment (RES 1.2) ( §3);

• defining suite metadata transformations for raw results and interpretations using SPARQL queries to be compliant with new SEALS ontologies specifications ( §4);

• working with SEDL development team to adapt our SEALS Evaluation Description Document to the new version of the SEALS Evaluation Description Language ( §5);

• extensions of the SEALS client for ontology matching evaluation ( §6).

The first four tasks concern integration with the SEALS technology, while the last task concerns WP12 specific services that have been extended to advance the automation of evaluation campaigns and to sustain the OAEI 2011.5 campaign.

Regarding integration with the SEALS technology, our focus was on extending previous implementations of the WP12 services to conform with new versions/requirements of SEALS presented during the meeting held in Grenoble, France on February 2012. This comprehends a new distribution of RES (RES 1.2) and directives to transform the metadata of raw and interpretation results to a format compliant with new specifications of SEALS ontologies.

The new functionality and improvements introduced in the RES 1.2 version were added to our BPEL work-flow. This includes the use of fine-grained facilities for tool execution time and memory consumption measurements, and the standardization of Core Tool Services fault handling. The modified work-flows have been successfully tested with the RES 1.2 distribution, both on a local installation and on the SEALS Platform. These tests confirmed that significant differences arose when comparing the results obtained against results obtained using a runtime measurement custom service implementation present in previous versions.

SPARQL queries have been written to transform legacy metadata generated for raw results and interpretations in order to be compliant with the new SEALS ontologies specifications. This shows that even if the ontologies evolve, the legacy data can still be accessed and visualized using these or new transformations.

The SEALS client for ontology matching evaluation has been extended in two ways. First, a specific parameter setting is now possible to use the client to store the results in the Results Repository. Second, a flexible parameterization was introduced allowing the manipulation of the client through a command line interface where the users can specify the URL of a test repository, the ID of a test suite as well as the ID of a specific version of that test suite. The SEALS client was extensively used for supporting the third SEALS ontology matching evaluation campaign.

Finally, this document reports on the whole set of software pieces that have been developed inside WP12 to support the automatic evaluation of matching tools.

Introduction

Last versions of deliverable D12.5 were focused, on the one hand, on the integration of Work Package 12 developments (WP12) with SEALS components previously released, including Runtime Evaluation Service 1.1.x distributions (RES) and Test Data and Results Repositories (TDRS and RRS respectively). On the other hand, D12.5 deliverables were also focused on WP12 specific services needed to run the first and second SEALS ontology matching campaigns (OAEI 2010 and OAEI 2011). Those works have been reported in [START_REF] Trojahn | Iterative implementation of services for the automatic evaluation of matching tools[END_REF], [START_REF] Trojahn | Iterative implementation of services for the automatic evaluation of matching tools[END_REF] and [START_REF] Meilicke | Iterative implementation of services for the automatic evaluation of matching tools[END_REF]. This version focuses on the same subjects.

Regarding integration with SEALS, during the last stage of the project our focus was on extending previous implementations of WP12 services to conform with new versions/requirements of SEALS presented during the meeting held in Grenoble, France on February 2012. This comprehends a new distribution of RES (RES 1.2) and directives to transform the metadata of raw and interpretation results to a format compliant with new specifications of SEALS ontologies, and that will be used to uniformize the way these data will be visualized through the SEALS portal.

WP12 specific services have been also extended to advance the automation of evaluation campaigns and to sustain the OAEI 2011.5 campaign, which was composed of 5 tracks with several tools evaluated over various test suites [START_REF] Meilicke | Results of the second evaluation of matching tools[END_REF]. As it was stated in one of previous deliverables [START_REF] Meilicke | Iterative implementation of services for the automatic evaluation of matching tools[END_REF], BPEL evaluation work-flows compliant with the SEALS guidelines do not support iteration over tools and test suites. For this reason we considered to run just parts of the campaign using BPEL work-flows running on the SEALS infrastructure. The fall-back strategy followed in OAEI 2011 campaign has been retaken and used with an extended version of the client that was originally designed to support tool developers in testing their tools locally.

In this deliverable, we report first in §2 on the modifications of WP12 BPEL evaluation description work-flow for use of new features and improvements included in RES 1.2 distribution. These new features are fine-grained facilities for tool execution time and memory consumption measurements. Also, catching of exceptions was modified for standardize the handling of Core Tool Services faults. In §3, we report on our experiments installing and testing RES 1.2 in local mode, and testing our work-flows on the SEALS Platform. We present in §4 the work done inside WP12 to deal with transformation of raw results and interpretations through SPARQL queries in order to be compliant with new SEALS ontologies specifications. To conclude with the subject of SEALS integration, we deal in §5 with the adaptations of WP12 Seals Evaluation Description Language (SEDL) bundle to the last version released of SEDL [2]. Then we report in §6 on the client extensions done to support the third SEALS ontology matching campaign (OAEI 2011.5). We present in §7 the final status of the services implemented inside WP12 for the automatic evaluation of matching tools, and we end in §8 with some conclusions reflecting the experiences we got in the effort of making our evaluation descriptions work on SEALS infrastructure and the most relevant learning we had running the third evaluation campaign for ontology matching tools.

Updating BPEL evaluation to RES 1.2 distribution

The RES 1.2 distribution was introduced during the SEALS meeting held in Grenoble, France from February 6th to February 9th 2012. RES 1.2 added features to the last version RES 1.1.1, such as the support of fine-grained tool execution time measurement, the support of memory consumption measurement for a given tool execution, and the support of custom tools. Some improvements with respect to RES 1.1.1 were also presented. Those improvements have to do with the standardization of Core Tool Services faults handling, and the recovering of identifiers generated for raw results and interpretations, as this information was not included in the response of the addRawResult and addInterpretations services in RES 1.1.1.

Even if previous versions of BPEL evaluations developed for RES 1.1.1 can run with no modifications on RES 1.2, one of our goals was to modify our evaluation description to take advantage of features/improvements presented within the new distribution. From features and improvements listed above we worked only on the runtime and memory consumption measurements, and on the standardization of SEALS fault handling. Regarding the recovering of raw results' and interpretations' identifiers, for WP12 this information is directly passed as parameters via the SoapUI project, so we did not need to modify our work-flow neither our metadata generation custom service implementation. Next sub-sections detail the tasks that we had to do in order to achieve that goal.

Before this, it is worth to remember the general functioning of our BPEL work-flow, whose general structure is shown in Figure 2.1. After some initialization steps, the while step, whose details are hidden in the figure, iterates a tool over a test suite. After the iteration, results are processed and sent to SEALS Results Repository. Figure 2.2 shows the details of the iteration, where an alignment invocation consists in fact on a two-step process. First the message sent to the alignment request mut be populated with parameter data (setParamsAlign step); then the alignment process is invoked (align step).

Runtime measurement functionality

Deliverable [START_REF] Meilicke | Iterative implementation of services for the automatic evaluation of matching tools[END_REF] reported on significant variations on runtime measurements of tools when using the BPEL evaluation work-flow with respect to similar executions using our client version. The reason was due to the fact that runtime measurement with BPEL needed the invocation of an external timestamp service which revealed very time consuming. Taking this into consideration, RES 1.2 offers the possibility to ask for runtime measurement, and also memory consumption, each time a tool is executed.

For introducing the runtime and memory consumption measurement, we modified our BPEL file as indicated during the Grenoble meeting, and we deleted all code having to do with our ancient runtime measurement custom service implementation. All this implied:

• To suppress all variables and links used by the custom service.

• To delete from the iteration part of our work-flow, shown in Figure 2.2, all the steps needed to set and invoke the external timestamp custom service. Fig- • To modify the reference of the ontology matching tools namespace to its new value in the files referring to it (BPEL and deployment files).

• To populate the tool-header part added to the message sent to the alignment request by including in the setParamsAlign step the assignment provided for that:

< bpel : copy > < bpel : from > < bpel : literal xml : space =" preserve " > < tools -schema : ToolHeader > < tools -schema : toolId > any -id </ tools -schema : toolId > < tools -schema : options > < tools -schema : measure -time > true </ tools -schema : measuretime > < tools -schema : measure -memory > < tools -schema : frequency >1000 </ tools -schema : frequency > < tools -schema : unit >B </ tools -schema : unit > </ tools -schema : measure -memory > </ tools -schema : options > </ tools -schema : ToolHeader > </ bpel : literal > </ bpel : from > < bpel : to part =" toolHeader " variable =" AlignRequest " > </ bpel : to > </ bpel : copy > where the AlignRequest variable contains the message that will be passed to the align procedure.

• To recover and process the response after the alignment invocation. As runtime is one of the criteria added for interpretations in the same manner like precision, recall and F-measure, this is done before calling the service that adds those metadata (addIRDataItemMetadata), inside the setParamsAddIRDataItemMetadata step where the message AddIRMetadataRequest is populated:

< bpel : copy > < bpel : from > <![ CDATA [ $AlignResponse . toolHeaderResponse //*[ local -name () = '
ellapsed '] div 1000]] > </ bpel : from > < bpel : to part =" payload " variable =" AddIRMetadataRequest " > < bpel : query queryLanguage =" urn : oasis : names : tc : wsbpel :2.0: sublang : xpath1 .0" > <![ CDATA [ gen -types : runtime ]] > </ bpel : query > </ bpel : to > </ bpel : copy > FP7 -238975 Deliverable 12.5

Standardization of Core Tool Service faults

A result obtained during the execution of an evaluation is the number of problems detected. This information comes in terms of variables incremented each time an exception is caught. Exception catching in RES 1.1.1 was done through a fault type specific to each work package (ontology matching tools, ontology engineering tools and so on). This was redundant as three types of faults are detected independently of the type of tool: platform, tool and bridge faults. Besides, this implied that each time an exception was caught, we must include conditions to identify what was the cause of the problem. Figure 2.4 shows how this was accomplished for exceptions thrown during the alignment invocation. The code behind the steps shown in the figure is:

< bpel : catch faultName =" omt : SEALSFault " faultVariable =" Fault " faultMessageType =" omt : SEALSFault " > < bpel : sequence > < bpel : if > < bpel : condition > <![ CDATA [ boolean ( $Fault . payload //*[ local -name () = ' ToolBridgeFault ']) ]] > </ bpel : condition > < bpel : sequence name =" CatchToolBridgeFault " >
< bpel : assign validate =" no " name =" i n c r e a s e N u m T o o l B r i d g e F a u l t s " > < bpel : copy > < bpel : from > <![ CDATA [ $NumToolBridgeFaults +1]] > </ bpel : from > < bpel : to variable =" NumToolBridgeFaults "/ > </ bpel : copy > </ bpel : assign > </ bpel : sequence > < bpel : elseif > < bpel : condition > <![ CDATA [ boolean ( $Fault . payload //*[ local -name () = ' ToolFault ']) ]] > </ bpel : condition > < bpel : sequence name =" CatchToolFault " > < bpel : assign validate =" no " name =" in crea seNu mTool Faul ts " > < bpel : copy > < bpel : from > <![ CDATA [ $NumToolFaults +1]] > </ bpel : from > < bpel : to variable =" NumToolFaults "/ > </ bpel : copy > </ bpel : assign > </ bpel : sequence > </ bpel : elseif > </ bpel : if > < bpel : rethrow / > </ bpel : sequence > </ bpel : catch > One of the improvements in RES 1.2 is the standardization of Core Service Faults handling. Platform faults are now separated from tool and bridge faults, giving three types of SEALS faults defined like UnexpectedPlatformFault, ToolFault and ToolBridgeFault. To introduce the new way of handling SEALS faults, we modified the namespaces pointing to new fault types and the catching of exceptions where needed. Figure 2.5 shows exception handling for the alignment invocation. The resulting code is: FP7 -238975 Deliverable 12.5 < bpel : catch faultName =" tools -service : ToolBridgeFault " faultVariable ="

ToolBridgeFault " faultMessageType =" tools -service : ToolBridgeFault " > < bpel : sequence > < bpel : assign name =" i n c r e a s e N u m T o o l B r i d g e F a u l t s " > < bpel : copy > < bpel : from > < bpel : literal xml : space =" preserve " > true </ bpel : literal > </ bpel : from > < bpel : to variable =" haveToolFault " > </ bpel : to > </ bpel : copy > < bpel : copy > < bpel : from > <![ CDATA [ $NumToolBridgeFaults +1]] > </ bpel : from > < bpel : to variable =" NumToolBridgeFaults "/ > </ bpel : copy > </ bpel : assign > < bpel : rethrow / > </ bpel : sequence > </ bpel : catch > < bpel : catch faultName =" tools -service : ToolFault " faultVariable ="

ToolFault " faultMessageType =" tools -service : ToolFault " > < bpel : sequence > < bpel : assign name =" in crea seNu mTool Faul ts " > < bpel : copy > < bpel : from > < bpel : literal xml : space =" preserve " > true </ bpel : literal > </ bpel : from > < bpel : to variable =" haveToolFault " > </ bpel : to > </ bpel : copy > < bpel : copy > < bpel : from > <![ CDATA [ $NumToolFaults +1]] > </ bpel : from > < bpel : to variable =" NumToolFaults "/ > </ bpel : copy > </ bpel : assign > < bpel : rethrow / > </ bpel : sequence > </ bpel : catch >

The full BPEL code for the last version of WP12 evaluation can be found at https: //svn.seals-project.eu/seals/deliverables/D12.5/M37/software/evals.

Comments on the use of new functionality

The xsd type definition files describing how a request to invoke a tool must be populated specify that asking for runtime and/or memory consumption measurement is optional. However, we observed that if both of them are not included in the request, an exception is thrown.

An interesting fact was that our tests confirmed that runtime measurements are more fine grained that those we got when using the custom service implementation. Results obtained were more realistic diminishing in a 30-40% percent measurements obtained with custom service implementation.

Experimenting with the RES 1.2 environment

During the Grenoble meeting it was announced that RES 1.2 will be available on the SEALS Platform by the end of February. As the packages to install the RES 1.2 distribution were already available, we decided to test it first on a local installation to prepare our experiments on the SEALS Platform. We present in this chapter some reflections about these experiments.

Testing the RES 1.2 distribution on a local installation

The local installation of RES 1.2 is accomplished in the same manner than that of RES 1.1.1. It is long and tedious but easily done following the instructions contained in [START_REF] Miguel | Iterative evaluation and implementation of the runtime evaluation service[END_REF]. We proceeded successfully with this task, and we confirmed first that RES 1.1.1 evaluation descriptions could be run with no problem under the new distribution. We take advantage of this installation to test also the requirement stated in [START_REF] Miguel | Iterative evaluation and implementation of the runtime evaluation service[END_REF] for wrapping tools. A Python script was written to automate tool re-wrapping, liberating developers to re-compile their code in order to produce the new bridge tool implementation asked by RES. We observed however that tool re-wrapping is not necessary when running RES on a local installation, but it is an important issue as it is needed to execute tools on the SEALS Platform. Once we modify our BPEL work-flow as explained in §2, we also proceed to test it successfully with various tools.

Testing the RES 1.2 distribution on the SEALS Platform

The RES 1.2 distribution was released on the SEALS Platform on February 22th. As various differences were introduced in the way RES Worker instances are managed, we tried first to test evaluation versions for RES 1.1.1. In RES 1.2, the life cycle of RES Worker instances is controlled with a DOS command enabling four operations: stop, clean, start and deploy. We had several problems at the beginning due to the fact that the only documentation available to understand the effects of those operations is a one page diapositive in a hands-on session document.

The biggest problem is that before an evaluation execution, RES worker instances need to be stopped because one needs to inform the RES Worker of the location of the currently deployed tool that will be used for that evaluation. This is done manually by modifying the worker configuration file. Once the configuration file is set, the RES Worker instance can be restarted. However when we executed the SoapUI project to trigger the evaluation, the worker instance was never recognized. We searched for an explanation in the log files, but as they are very huge and contain a lot of non understandable information, we executed the clean operation to re-create them. We did this without knowing that the effect of this operation is also to undeploy the RES packages needed to run a RES Worker instance, so that was the reason the instance was never recognized. After several exchanges with people in charge of RES development, we finally knew that we needed to redeploy the instance.

At the end we could run and test our BPEL work-flow successfully; as we said before, in this context we need to use re-wrapped tools in order to make the resultant alignments available through the File publisher.

At one time we considered the possibility to run part of the evaluation campaign using the BPEL work-flow. However as it was also stated in previous deliverables, BPEL work-flows are unable to iterate over tools and test suites. In current conditions, we have to do a lot of manual work to run an evaluation campaign, and this represented a problem for us, as around 15 tools participated in each track of the ontology matching campaign, and several test suites were tried for each tool [START_REF] Meilicke | Results of the second evaluation of matching tools[END_REF]. To support that affirmation, we present below the steps needed to iterate over tools and test suites on the SEALS Platform (all of them are manual). Before this, we recall that tool interfaces are encapsulated in a ZIP file with the following structure: where the folder bin/lib/ contains all required libraries for executing the tool, while the folders conf/ and lib/ contain configuration and distribution resources required by the tool at runtime, for example word dictionaries, background knowledge and so on. Now, to iterate over tools and test suites we would need to proceed like follows:

1. Stop and clean RES Worker instance.

2. Modify the RES Worker configuration file to indicate the location of the currently deployed tool.

3. Deploy the tool if needed (install the conf and lib folders containing any resource needed by the tool to be executed).

4. Start and deploy RES Worker instance.

5.

Start SoapUI if it is not started.

6. Edit SoapUI project to indicate which is the test suite that will be used and to assign identifiers to Raw Results and Interpretations.

FP7 -238975

Deliverable 12.5

7. Run SoapUI project.

Steps 6 and 7 must be repeated to iterate over test suites, and all the steps must be repeated to iterate over tools. Cleaning the RES worker is not really necessary but it is better to do it to be sure that RES Worker instances will be correctly identified.

Considering all the manual work needed to implement the iterations, we decided not to use BPEL evaluations for running the OAEI 2011.5 campaign. Instead, we use extensively the client version already introduced in other deliverables. We comment on extensions done to this version in §6.

Nevertheless, we conducted several short tests with tools that do not need step 3 of the iteration to be performed. The tools for which we ran BPEL work-flows on the SEALS Platform are Aroma [5], LogMapLt which is a light version of LogMap [START_REF] Jiménez | Logmap: Logic-based and scalable ontology matching[END_REF], MapSSS [START_REF] Cheatham | MapSSS results for OAEI[END_REF], MapEVO [START_REF] Danschel | MapPSO and MapEVO results for OAEI[END_REF] and MapPSO [START_REF] Bock | Discrete particle swarm optimisation for ontology alignment[END_REF], and the results of these tests were stored in the SEALS Results Repository. These results can be accessed via the identifiers OMT-2011.5-biblio-SEALSbenchmarks-%SYSTEM%-rr, which refers to the uninterpreted raw results, and OMT-2011.5-biblio-SEALSbenchmarks-%SYSTEM%-ir for interpretations where %SYSTEM% must be replaced by the name of a tool.

Metadata transformation of WP12 raw results and interpretations

SEALS ontologies are used in the SEALS Platform for representing the resources managed by it, including evaluation descriptions, test data, results, etc. Data stored in the SEALS Result Repository concerns both raw results (i.e., alignments in WP12) and interpretations of these results (i.e., precision and recall measurement). All those data is described in a metadata format according to SEALS ontologies definitions 1 . One functionality to be added to the SEALS portal is visualization of those data.

SEALS suite ontologies have evolved over the duration of the project, and several updates have been done for describing raw results and interpretations in a generic way. Previous versions of the BPEL workflow generated descriptions which are not completely compliant with new SEALS ontologies and just a few work packages integrated already the new ontologies in their metadata results. Then, the problem of what to do with legacy data arose during the Grenoble meeting.

The proposed solution consists in writing some code to transform raw results and interpretations described with the old ontologies to the new ones, which permits on the one hand the visualization of old and new data, and avoids on the other hand rewriting the code that some work packages (including WP12) are currently using for metadata generation. In this way, results of the transformation will be compliant with new ontologies, in order to be processed for visualization purposes through the SEALS portal.

Based on examples put on the SEALS wiki by Raúl García Castro, we wrote two SPARQL queries to transform WP12 raw results and interpretations. The content of these queries can be consulted in Appendix A.

New version of SEDL bundle

As reported in [START_REF] Trojahn | Iterative implementation of services for the automatic evaluation of matching tools[END_REF], an Evaluation Description Document specified in the SEALS Evaluation Description Language (SEDL) defines all required resources and dependencies among them for carrying out an evaluation in the SEALS Platform [START_REF] Bock | Language for describing evaluations -v2 (updated working specification)[END_REF]. It comprises an Execution Contract, a WS-BPEL 2.0 workflow, custom services that are invoked from within the workflow, as well as ontologies that define categories used in the Execution Contract. The last one describes the conditions that need to hold for tools, test suites, and results that can be processed by the evaluation workflow. Those resources are bundled in a ZIP file that must be stored into the Evaluation Description repository (EDRS).

A new version of SEDL being released by January 2012 [2], our previous SEDL bundle had to suffer minor modifications. The SEALS team in charge of SEDL specification and implementation achieved the modifications resulting in the following structure: The SEDL document evaluation.sedl.xml can be found in Appendix B. We observed no big differences between the two versions, the only one being the use of the jar file ed-omt-resources-1.0.0-SNAPSHOT-jar-with-dependencies.jar instead of ed-omt-resources-1.0.0-SNAPSHOT.jar At the time this deliverable is written, the SEALS platform does not seem able to run evaluations stored in the EDRS.

FP7 -238975

Deliverable 12.5

Extensions for running WP12 campaigns

As already explained, we have executed the majority of our evaluations in OAEI 2011.5 with the help of the SEALS client for ontology matching. This client has first been mentioned in deliverable D12.5-v2.0-beta [START_REF] Meilicke | Iterative implementation of services for the automatic evaluation of matching tools[END_REF], where we also report about its usage in the context of OAEI 2011 (the second SEALS evaluation campaign for ontology matching). The client is available as a single jar file. It can be used via a simple command line call to execute a complete evaluation run for one tool and one test suite. The tool needs to wrapped against the SEALS interface and the test suite needs to be stored in the SEALS Test Data Repository. The evaluation can take place on a standard laptop or on a powerful server machine. No specific infrastructure is required.

The client can be used for different purposes. Tool developers can use it to test their systems. They can check whether their tool correctly implements the required interface. This is a requirement for participating in the campaign. Moreover, they can directly compute precision and recall scores for the test suites stored in the TDRS (aside from any specific evaluation campaign). Evaluation campaign organizers can use it to execute basic evaluation workflows, as long as they follow the simple pattern that is common to each WP12 workflow (see Figure 2.1 and Figure 2.2). As explained on the previous pages, we have encountered several problems in running a complete campaign on top of the SEALS platform with a BPEL workflow. For that reason we decided to extend the client to integrate it more tightly with other SEALS components and to prepare it for future campaigns. In particular, we extended the client in the following way.

Storage of results

The results generated by the usage of the previous version of the client were stored locally in an proprietary format. They have not been stored in the SEALS results repository. Meanwhile we have included the component for storing results and interpretation, which has been developed for usage within the BPEL workflow. Via a specific parameter setting it is now possible to use the client to store the results in the Results Repository.

Flexible Parameterization In the previous version of the client we supported to run three predefined test suites. These have been the test suites of OAI 2011. However, in OAEI 2011.5, we needed to execute the client on several new test suites, and the same can be expected to happen in any subsequent campaign.

For that reason we modified the command line interface of the client and allowed to specify the URL of a test repository, the ID of a test suite as well as the ID of a specific version of that test suite.

We have also modified and improved the documentation of the client. The client, as well as its documentation, is available at http://oaei.ontologymatching.org/ 2011.5/seals-eval.html. This documentation helped the tool developers to solve the problem of wrapping their tool against the client on their own. Two or three developers had problems within this process that could finally be solved with our support. A list of available test suites (together with an explicit listing of relevant IDs) can be found at http://oaei.ontologymatching.org/2011.5/suites.html.

The client itself supports no functionality to iterate over tools or test suites. However, it supports a minimal mechanism to deploy the resources required for a tool to be executed correctly and it can easily be called from an external program. Thus, it is easy to implement the iteration in a simple script or in a short java program. This was the pragmatic approach that we have finally chosen to run most of our evaluations. Note also that we executed a large deal of our evaluation runs on the SEALS virtualization infrastructure, i.e., on virtual machines running on SEALS server machines. This was possible due to the flexibility of the client-based approach.

FP7 -238975 Deliverable 12.5

Final status of services for the automatic evaluation of matching tools

Three objectives were established in the document SEALS Description of Work (DOW) for WP12. One of them makes a clear reference to the technology that had to be developed to automate evaluations: "developing automated tools that perform all aspects of evaluation: test generation, benchmark processing, result analysis, and publishing;". With regard to this statement we present in the following the final status of WP12 implementations.

We have implemented a test generator [START_REF] Rosiou | Ontology matching benchmarks: generation and evaluation[END_REF], [START_REF] Trojahn | Iterative implementation of services for the automatic evaluation of matching tools[END_REF] which has been used to produce the tests used in two evaluation campaigns. The generator receives as input a reference ontology and a set of parameters describing the kind of modifications that will be applied to the reference ontology. It delivers as output a set of modified ontologies together with the corresponding reference alignments. The modifications can be done on three dimensions: removing (classes, properties, comments or restrictions), adding (classes or properties), and renaming (classes or properties).

Several pieces of software have been developed to support benchmark processing in an automated way. A module allows for uploading complete data sets to the SEALS Test Data Repository; SEALS metadata compliant with SEALS ontologies is generated at the same time. A python script allows for downloading executable tools that have been uploaded and stored by the tool developers in the SEALS tool repository. Also, we have developed a client for ontology matching evaluation which has been used in two evaluation campaigns; the client can receive as parameters the location where a matching tool is deployed, the URL of a test repository, the ID of a test suite as well as the ID of a specific version of that test suite, and it is able to run the evaluation of that tool for the data set specified.

We have also produced a BPEL work-flow that can process the evaluation of a tool with a data set in the RES 1.2 distribution. However, we did not use the SEALS Evaluation Description Repository because work-flows stored there cannot yet be executed. For the reasons explained in this document §2, we can not run a full campaign via the BPEL work-flows. Instead of that, we wrote a simple Linux shell script as well as a Java program that iterates the client over tools and data sets.

Finally, related with results analysis and publishing, both the client and the BPEL work-flow allow for uploading the results of an evaluation to the SEALS Results Repository. These results data sets are freely available and can be donwloaded by everyone. We have not developed visualization components as other SEALS partners are working on this aspect, however, the ontology matching evaluation results stored in the Results Repository are compliant, through the use of SPARQL queries, with the SEALS ontologies. This will allow visualization tools to process those results as soon as these tools are available.

All these pieces of software can be found at https://svn.seals-project.eu/ seals/deliverables/D12.5/M37/software.

Final remarks

This deliverable has reported about the work we have done in the last iteration of task 12.5: iterative implementation of services for automatic evaluation of matching tools, and on the final status of those services. We worked mainly on the task of modifying the WP12 BPEL work-flow to take advantage of the new functionality and improvements introduced in the RES 1.2 version during the SEALS meeting held in Grenoble on February 2012. The modified work-flows have been successfully tested both on a local installation and on the SEALS Platform. We worked also on the task of writing transformations of result data to be compliant with the new SEALS ontologies specifications. Finally, the SEALS client for ontology matching evaluation, used extensively in the third SEALS ontology matching campaign , has been extended for better supporting the automation of WP12 evaluation campaigns and to advance in the integration with important parts of SEALS technology, like the Tools, Test Data and Results repositories.

The lessons learned during this iterations can be resumed in the following points:

• Runtime measurement has been added to tools invocation confirming that significant differences resulted when comparing the results obtained against results obtained using a runtime measurement custom service implementation.

• Iteration over tools and data sets using the RES environment revealed a big time consuming task. A lot of manual work has to be done if we want to run a complete evaluation campaign with this environment. We hope that the release of the SEALS manager will help to solve this problem for future campaigns.

• Metadata generated for raw results and interpretations has been easily transformed through SPARQL queries to be compliant with the new SEALS ontologies specifications. It seems then that even though the ontologies continue to evolve, legacy data for results and interpretations can still be accessed and visualized using these transformations.

• We have seen that the client-based approach allows us to run a complete campaign in an automated way. The client is both a flexible solution and integrated with many other components of the platform. However, we cannot use it to measure, for example, memory consumption.

As we said before, we hope that the release of the SEALS manager will permit to fully exploit the hardware infrastructure and the software modules developed for the SEALS project.

From the very beginning of the project we decided to integrate SEALS campaigns with existing OAEI campaigns. Thus, we had a different starting point compared to the other research work packages. Our decision was based on the high acceptance of OAEI in the matching community. In doing so, we could benefit from a high number of participants and a partially predefined overall procedure. At the same, this resulted in a number of technical challenges. In particular, we had to use the software developed within the project from the very beginning in a complex scenario with a high number of participants that were used to a certain procedure following a tight schedule.

Finally, we can draw the conclusion, that the SEALS technology we have introduced to OAEI in an iterative way -from OAEI 2010 over OAEI 2011 to OAEI 2011.5 -has been very positively accepted. The main improvements are the reproducibility of results and the measurement of runtimes and scalability. As a side effect of asking tool developers to wrap their tools against the interfaces of the SEALS platform, many tools have become available in a more robust and executable version compared to the time before OAEI 2011. Overall, we conclude that the technology introduced by SEALS helped to improve OAEI evaluations significantly.

B. SEDL document

This section lists the SEDL document that specifies all the requirements needed to execute an evaluation workflow.

:00" > <! --~~~~~~~~~~~~~--> <! --Documentation --> <! --~~~~~~~~~~~~~--> < sedl : Documentation > OMT evaluation description . </ sedl : Documentation > <! --~~~~~~~~~~~~~~~~~~~~~~~--> <! --Execution Contract Part --> <! --~~~~~~~~~~~~~~~~~~~~~~~-->
< sedl : ExecutionContract > < sedl : Parameters > < sedl : Parameter name =" testSuite " type =" tdcat : OMTTestS uite " resourceRef =" OMTOntology "/ > < sedl : Parameter name =" t e s t S u i t e V e r s i o n " type =" tdcat : O M T T e s t S u i t e V e r s i o n " resourceRef =" OMTOntology "/ > < sedl : Parameter name =" tool " type =" seals : O n t o l o g y M a p p i n g T o o l " resourceRef =" OMTOntology "/ > < sedl : Parameter name =" toolVersion " type =" seals : O n t o l o g y M a p p i n g T o o l V e r s i o n " resourceRef =" OMTOntology "/ > </ sedl : Parameters > < sedl : Outputs > < sedl : Output name =" rawResult " type =" rcat : OMTRawResult " resourceRef =" OMTOntology "/ > </ sedl : Outputs > </ sedl : ExecutionContract > <! --~~~~~~~~~~~~~~~~~~~~--> <! --Custom Services Part --> <! --~~~~~~~~~~~~~~~~~~~~--> < sedl : CustomServices > < sedl : CustomService name =" PRFService " > < sedl : Documentation > Service that computes precision , re call and f -measure . </ sedl : Documentation > < sedl : WSDL portType =" service : PRF " resourceRef =" PRFServi ceWSDL " xmlns : service =" http :// www . seals -project . eu / resource s / omt / custom / prf / wsdl / v1 "/ > < sedl : Impleme ntation className =" eu . sealsproject . doma in . omt . custom . prf . v1 .

PRFImpl " resourceRef =" C u s t o m S e r v i c e s J A R "/ > </ sedl : CustomService > < sedl : CustomService name =" M e t a d a t a G e n S e r v i c e " > < sedl : Documentation > Service that generate the required raw result and inte rpretati on suite metadata . </ sedl : Documentation > < sedl : WSDL portType =" service : MetadataGen " resourceRef =" M e t a d a t a G e n S e r v i c e W S D L "

Figure 2 . 1 :

 21 Figure 2.1: WP12 BPEL workflow.Figure 2.2: Iteration over a test suite.

Figure 2 . 2 :

 22 Figure 2.1: WP12 BPEL workflow.Figure 2.2: Iteration over a test suite.

Figure 2 . 3 :

 23 Figure 2.3: Iteration over a test suite without timestamp external service.

Figure 2 . 4 :

 24 Figure 2.4: Exception handling for the alignment step in previous version.

Figure 2 . 5 :

 25 Figure 2.5: Exception handling for alignment after standardization of Core Service Faults.

<

  ? xml version ="1.0"? > <! --* * * * * * * * * * * * * * * * * * * * --> <! --OMT SEDL Document --> <! --* * * * * * * * * * * * * * * * * * * * --> < sedl : E v a l u a t i o n D e s c r i p t i o n xmlns : sedl =" http :// www .

  =" http :// www . seals -project . eu / resource s / omt / custom / metadataGen / wsdl / v1 "/ > < sedl : Impleme ntation className =" eu . sealsproject . doma in . omt . custom . metadataGen .v1 . M e ta da ta G en Im pl " resourceRef =" C u s t o m S e r v i c e s J A R "/ > </ sedl : CustomService > </ sedl : CustomServices ><! --~~~~~~~~~~~~~~~~~~~~~~~~--> <! --Evaluation Workflow Part --> <! --~~~~~~~~~~~~~~~~~~~~~~~~--> < sedl : E v a l u a t i o n W o r k f l o w processName =" wp12 -evaluatio n " resourceRef =" E valuati onBPEL "/ > <! --~~~~~~~~~~~~~~--> <! --Resources Part --> <! --~~~~~~~~~~~~~~--> < sedl :Resources > < sedl : Resource xsi : type =" sedl : X M LR es ou r ce Ty p e " name =" E valuatio nBPEL " xmlType =" BPEL " location =" resources / bpel / Eval uationW P12 . bpel " > < sedl : Dependency resourceRef =" PRFS erviceW SDL "/ > < sedl : Dependency resourceRef =" M e t a d a t a G e n S e r v i c e W S D L "/ > </ sedl : Resource > < sedl : Resource xsi : type =" sedl : X M LR es ou r ce Ty p e " name =" P RFServic eWSDL " xmlType =" WSDL " location =" resources / wsdl / prf . wsdl "/ > < sedl : Resource xsi : type =" sedl : O n t o l o g y R e s o u r c e T y p e " name =" OMTOntology " o n t o l o g y L a n g u a g e =" OWL " location =" resources / ontologies / OMTOntology . owl "/ > < sedl : Resource xsi : type =" sedl : X M LR es ou r ce Ty p e " name =" M e t a d a t a G e n S e r v i c e W S D L " xmlType =" WSDL " location =" resources / wsdl / metadataGen . wsdl "/ > < sedl : Resource xsi : type =" sedl : B i n a r y R e s o u r c e T y p e " name =" C u s t o m S e r v i c e s J A R " location =" resources / impl / ed -omt -impl -1.0.0 -SNAPSHOT -jar -with -dependencies . jar "/ > </ sedl : Resources > </ sedl : EvaluationDescription >

  Runtime measurement functionality . . . . . . . . . . . . . . . . . . . . 2.2 Standardization of Core Tool Service faults . . . . . . . . . . . . . . . . 2.3 Comments on the use of new functionality . . . . . . . . . . . . . . . .

	Table of Contents
	List of figures
	1 Introduction
	2 Updating BPEL evaluation to RES 1.2 distribution
	2.1 4 Metadata transformation of WP12 raw results and interpreta-
	tions
	5 New version of SEDL bundle
	6 Extensions for running WP12 campaigns
	7 Final status of services for the automatic evaluation of match-
	ing tools
	8 Final remarks

3 Experimenting with the RES 1.2 environment 3.1 Testing the RES 1.2 distribution on a local installation . . . . . . . . . 3.2 Testing the RES 1.2 distribution on the SEALS Platform . . . . . . . . References A Sparql queries for transformation of raw results and interpretations metadata A.1 Transformation of Raw Results . . . . . . . . . . . . . . . . . . . . . . A.2 Transformation of Interpretations . . . . . . . . . . . . . . . . . . . . . B SEDL document

See definitions in http://www.seals-project.eu/wiki/index.php/Ontologies.

http://www.seals-project.eu/ Document URL EU Project Officer Carmela Asero tomatic evaluation of matching tools -v2.0-FR

A. Sparql queries for transformation of raw results and interpretations metadata

This section lists the queries written to transform WP12 metadata formats to new SEALS ontologies descriptions.

A. [START_REF] Bock | Language for describing evaluations -v2 (updated working specification)[END_REF] ? dataItem dc : identifier ? did . ? dataItem sealsv1 : isLocatedAt ? locatedAt . } ? suite rdf : type sealsv1 : Suite . ? suite rdf : type omt : I n t e r p r e t a t i o n S u i t e . ? suite sealsv1 : hasSuiteItem ? suiteItem .

A.2 Transformation of Interpretations

? suiteItem dc : identifier ? sid . ? suiteItem omt : h a s C r i t e r i o n I t e m ? r u n t i m e C r i t e r i o n I t e m . ? suiteItem omt : h a s C r i t e r i o n I t e m ? p r e c i s i o n C r i t e r i o n I t e m . ? suiteItem omt : h a s C r i t e r i o n I t e m ? r e c a l l C r i t e r i o n I t e m .


Jérôme Euzenat

Jérôme David
email: jerome.david@inria.fr

Keywords: mobile, API, linked data, content provider

Mobile devices are now a main way to access data. Yet they do not offer any uniform way to deal with it.

Linked data provides a uniform interface for accessing linked data over the web.

We have developed an API in order to offer uniform access to data within mobile devices and across devices. It extends the Content Provider API designed to share data across Android applications. Finally, this API introduces a transparent URI dereferencing scheme allowing for exposing device content to others.

As a consequence, any application can access data as linked data without any a priori knowledge of the data source.

Introduction

Smartphones are becoming the main personal information repositories. Unfortunately, this information is stored in independent silos managed by applications and thus, it is difficult to share data across them. Nowadays, mobile operating systems, such as Android, deliver solutions in order to overcome this, but they are limited by the application database schemas that must be known beforehand.

The difficulty of sharing phone data at the web scale can be seen as another drawback. One can synchronize application data, such as the contacts or the agenda using a Google account. However, they are not generic solutions and there it is no mean to give access to data straight from the phone. The W3C Device API1 cover this need across devices but they do offer specific APIs for specific applications and not a uniform and flexible access to linked data.

Our goal is to provide applications with a generic layer for data delivery in RDF. Using this solution, applications can exploit device information in an uniform way without knowing from the beginning application schemas. This information can also be exposed to the web and web information can be considered in the same uniform manner. For example, an application may be used as a personal assistant: when one would like to know which of his contacts will participate to an event, he can consult the calendar of all his contacts in order to retrieve the answer. For sure, according to the security settings of the corresponding contact, he may be allowed or not to access the calendar.

Moreover, we propose to do it along the linked data principles (use URIs, provide RDF, describe in ontologies, link to other sources).

The mobile device information can as well be accessed remotely, from any web browser, by any person who has been granted access to it. In this case, the device acts like a web server.

Some proposals have been made in that direction [START_REF] Lassila | Semantic web approach to personal information management on mobile devices[END_REF]. We presented a first version of the RDF content provider in [START_REF] David | Linked data from your pocket: The Android RDF-ContentProvider[END_REF]. This layer, built on top of the Android content provider, allowed to share application data inside the phone. In this paper, we extend the previous version by adding capabilities to access external RDF data and to share application data as linked data on the web.

We first describe the context in which the Android Platform stores its data, and how it can be extended in order to integrate RDF. Then, we present two applications that sustain its feasibility: the first one is an RDF browser that acts like a linked data client and allows the navigation through the device information, and the second one is an RDF server which exposes its information to the outside world. We continue to present the challenges raised by such applications and solutions we implemented for them. Finally, we conclude presenting future improvements and challenges in this field.

The Android architecture

Android is a Linux-based operating system for mobile phones. It allows for developing applications in Java [START_REF] Meier | Professional Android 2 Application Development[END_REF][START_REF] Gargenta | Learning Android[END_REF].

Inside the Android system, each application runs in isolation from other ones. Android assigns to each application a different and unique user. Only this user is granted access to the application files. This allows one to take advantage of a secure environment, but prevents the exchange of data across applications. To overcome this drawback, Android provides the content provider mechanism.

Services and Intents

Android is built around different kinds of services that are provided by an application1 :

-Activities are user interaction modalities (an application panel, a chooser, an alert); -Services are processing tasks; -Broadcast receivers are filters which react to events; -Content providers expose some data of the application to other ones.

An application is build around zero or more of each kind of services. Applications and application components communicate through messages called "intent". They are defined as:

Intent intent = new Intent( Action, Data );
such that Action is a Java like package name (e.g., fr.inrialpes.exmo.rdfoid.GETRDF) and the Data can be anything but would generally be a URI (e.g., content://contacts/people/22) and optionally a mime-type specifying the expected result. When called through:

startActivity( intent );
The targeted component can be explicit, i.e., identified the components to deal with the request, or Android can look for an application/component able to answer the Action on the Data and pass it the call and the arguments.

Android Content Providers

Android is built around different kinds of services, one of which being ContentProvider which exposes some data of an application to other applications. Content providers enable the transfer of structured data between device applications. They encapsulate the data and control the access to it through an interface. This interface empowers one to query the data or to modify it.

A content provider2 is a subclass of ContentProvider and implements the following interface: which allows one to query, to insert, to delete or to update the data . Queries are issued in an SQL manner and the results are presented to the user as a table.

Android URIs

With the content provider API, each data (table or individual) is identified by a URI having the following structure: content://authority/path/to/data

The content: scheme is the cornerstone of each Content Provider URI, the authority identifies the provider, i.e., the dataset, and the path/to/data identifies a particular table or individual (row) in the dataset. For example, the URI content://contacts/people refers to all the people in the contact application, and the URI content://contacts/people/33 identifies a specific instance of these, namely the instance having the id 33.

When an application wants to access a particular piece of data, it queries its URI. This is done through a call to the ContentResolver which is able to route the query to the right content provider.

From a semantic web point of view, using URIs to identify data is a strong point of the Android content providers. Still, there are several limitations if we would like to use them as a linked data interface.

Specifically, URIs used by content providers are local to each device, i.e., not dereferenceable on the web, and not unique. The content scheme used by providers is not a standard protocol. Furthermore, two distinct devices will use the same URI to identify different data. For example, by using content://contacts/people one would be able to access the contacts from both devices.

The RDF Content Provider Framework

We designed the RDFContentProvider framework to offer uniform access to phone data and to give a semantic web flavour to Android. It is composed of the RDFContentProvider API and the RDFContentResolver application. The API must be included inside the applications that want to access RDF providers and inside the applications that want to define new RDF content providers. The RDFContentResolver application is the one that records all the RDF content providers installed on the device and routes queries to the relevant provider. Figure 3.1 gives an overview of the framework architecture.

The RDF Content Provider API

The goal of the RDFContentProvider API is to answer to two types of queries:

-Queries that request information about a particular individual (i.e., tell me what you know about individual X). The provided answer would be made of a set of triples which will correspond to the description of one object and the attribute values. -Queries that request only the values for some variables that must satisfy a specific condition (i.e., SPARQL-like queries). In this case, the answer should correspond to a table of tuples, like in ContentProviders or SPARQL.

The RDFContentProvider API delivers the following classes and interfaces:

-RdfContentProvider: An abstract class that should be extended if one wants to create an RDF content provider. It subclasses the ContentProvider class belonging to the Android framework; -RdfContentResolverProxy: A proxy used by applications to send queries to the RDFContentResolver application; -Statement: A class used for representing an RDF statement; -RdfCursor: An iterator on a set of RDF statements; -RdfContentProviderWrapper: A subclass of RdfContentProvider which allows for adding RDF content provider capabilities to an existing classical content provider.

RDFContentProvider follows primarily the same kind of interface as ContentProvider. The minimal interface to implement linked data applications is:

-RDFCursor getRdf( Uri id )
The Cursor iterates on a table of subject-predicate-object (or predicate-object) which are the triples involving the object given as a URI. If one wants to offer a more elaborate semantic web interface, i.e., a minimal SPARQL endpoint, the following methods have to be also implemented:

- The RDF providers that we have developed so far are implementing only the first three primitives. This interface corresponds to the one we required to web services in our work on ambient intelligence [START_REF] Euzenat | Dynamic context management for pervasive applications[END_REF]. Indeed, to some extent, this work is similar to the work in ambient intelligence except that instead of dealing with a building-like environment, it works within the palm of one's hand. But the problem is the same: applications which do not know each others and have to communicate through semantic web technologies.

The RDF Content Resolver Service

The RDFContentResolver service has the same goal as the ContentResolver belonging to the Android framework. It maintains the list of all the installed RDF content providers, and forwards the queries it receives to the corresponding one. This application is never visible to the user, therefore we have implemented it as an Android service.

When an RDF Content Provider is instantiated by the system, this provider automatically registers to the RDFContentResolver. A principle similar to the one from the Android Content Provider framework is used.

The RDFContentResolver can route both the local (content:) and external (http:) URIbased queries. In case of a local URI, i.e., starting with the content scheme, the resolver decides to which provider it must redirect the query. In case of an external URI, i.e., starting with the http scheme, the provider automatically routes the query to the RDFHttpContentProvider (see Figure 3.1).

The RDFHttpContentProvider allows one to retrieve RDF data from the Web. It parses RDF documents and presents them as RDFCursors. So far, only the minimal interface has been implemented, i.e., the getRdf( Uri id ) method.

RDF Provider wrappers for Phone applications

The RDF Content Resolver application is also bundled with several RDF content providers encapsulating the access to Android predefined providers. The Android framework has applications that can manage the address book and the agenda. These two applications store their data inside their own content provider.

In order to expose this data as RDF, we developed the RDFContactProvider and the RDFCalendarProvider. These providers are wrapper classes for the ContactProvider and the CalendarProvider residing inside the Android framework. The same could be obtained by bypassing their ContentProvider interface and using instead the W3C Device APIs since they exist for each of these applications1 . So doing should not be significantly more difficult and would ease porting to other platforms than Android.

RDFContactProvider exposes contact data using the FOAF ontology. It provides data about a person's name (display name, given name, family name), about his phone number, email address, instant messenger identifiers, homepage and notes.

RDFCalendarProvider provides access to the Android calendar using the RDF Calendar ontology2 . The data supplied by this provider contains information about events, their location, their date (starting date, ending date, duration, and event time zone), the organizer of the event and a short description.

RDFPhoneSensorsContentProvider aims to expose sensor data from the sensors embedded inside the mobile device. Contrary to the others, they are not offered as Content Providers. At the present time, it only delivers the geographical position (retrieved using the Android LocationManager service). In order to express this information in RDF, we use the geo location vocabulary3 , the one that provides a namespace for representing lat(itude) and long(itude).

Developing a wrapper would consist, in general, of the following steps:

-Identify data exposed in the application content provider; -Choose ontologies corresponding to this data; -Provide a URI pattern for each ontology concept; -Implement a dereferencing mechanism which, for each type of resource, extract information from the content provider and generates RDF from this (generating URIs for related resources).

A native RDF Content Provider application may follow the same steps. However, it may be developed without any Content Provider. In this case, the analysis has to be carried out from the application data (or a corresponding API).

Pikoid

Pikoid is a simple application allowing a user to annotate on the phone pictures with people from the address book, places from the map and events from the calendar. It uses the foaf and vcal ontologies. It natively implements the RDF Content Provider interface.

RDF Browser

The RDF Browser acts like a linked data client. Given a URI, the browser makes an HTTP URI request in order to retrieve the information from the specified location. It works both with http: and content: URIs. If the data contains other URIs, the user can click on them and the browser will issue a new query with this URI.

An example can be found in Figure 4.1. In this case, the user uses the RDFBrowser to get the information about the contact having the id 4. When the browser receives the request, it sends it further to the RDFContentResolver. Since the URI starts with the content:// scheme and has the com.android.contacts authority, the resolver routes the query to the RDFContactProvider. This provider retrieves the set of triples describing the contact and sends it to the calling application which displays it to the user. Thereupon, the user decides that he wants to continue browsing and selects the contact's homepage. In this case, since the URI starts with the http:// scheme, the resolver routes the query to the RDFHttpContentProvider. The same process repeats and the user can see the remote requested file, i.e., Tim Berners-Lee FOAF file.

RDF Server

The RDF Server is a new component added to the architecture. This server provides to the outside world the data stored into the device as RDF. Due to the fact that the server must maintain a permanent connection to the Internet without user interaction, we implemented it as an Android service, i.e., a background process.

One important issue appears when one would like to get data from a device because the URI used to query the content providers has a local meaning. In the outside world, the URI used to query the address book of two different people will be the same, but the content of the address book will be different.

The server principles are quite simple. In the beginning, the server receives a request from the outside. Then, it dereferences the requested URI, i.e., it translates the external URI into an internal one, which has meaning inside the Android platform. The RDF Server sends it further to the RDFContentResolver. In a manner similar to the one explained for the RDF Browser the set of triples is obtained but, before sending this set to the server, the URIs of the triples are externalized and the graph is serialized using a port of Jena under the Android platform.

The URI externalization process translates the local URI content://authority/path/to/data into the dereferenceable one http://deviceIPAddress:port/authority/path/to/data. Reversing the translation of such a URI is possible since both the authority and the path are kept during the externalization process.

Usually, mobile devices do not have a permanent IP address and thus, the externalized URIs are not stable. To overcome this, a dynamic DNS client 12 can be used.

In addition, the server supports a minimal content negotiation mechanism. If one wants to receive the data in RDF/XML, it will set the MIME types of the Accept-type header of its request to "application/rdf+xml" or to "application/*". In the opposite case or when the client sets the MIME type to "text/plain", the data will be transmitted in the n-triple format. Not only the requester has the opportunity to express its preferences regarding the format of the received data, but the default format of the transmitted data can be specified in the server settings, as well the port on which the server can listen on and the domain name server for it. An example can be found in Figure 5.1. In this scenario, the user retrieves information about the fourth contact from the device address book. The request is processed by the RDF Server in a manner similar to the one of the RDF Browser.

Technical issues: application size

The RDF Server included in our architecture eases the access of the user to the RDF data found on the web. For that purpose, we wanted to reuse an existing semantic web framework, such as Jena or Sesame. Yet they are not suitable to be employed under the Android platform (the code depends on some libraries that are unavailable under Android). There are a few ports of these frameworks to Android: Microjena1 and Androjena2 are ports of Jena and there exists a port of Sesame to the Android platform mentioned in [START_REF] Mathieu D'aquin | Building SPARQL-enabled applications with android devices[END_REF]. We use Androjena.

A problem that arises when we use this framework is that the size of the application increases substantially. This problem could have been avoided by reimplementing only the Jena modules that are needed in our architecture. Still, we would like to improve our architecture by adding more features (such as a SPARQL query engine) that require additional modules to those used to read/parse/write RDF, available in Jena.

A tool that we found useful in our development process was ProGuard. ProGuard3 is a code shrinker, optimizer, and obfuscator. It removes the unused classes, methods or variables, performs some byte-code optimizations and obfuscates the code. The tool proved to be efficient in reducing the size of our application (our framework including Androjena) by half, i.e., its initial size was 6.48MB, and after we applied the tool it diminished up to 2.98MB.

The existence of such tools as ProGuard, is a step forward in the continuous battle between applications that require a considerable amount of space for storing their code and devices with a reduced memory storage.

Perspectives: SPARQL querying

We are currently examining how to query the device data using SPARQL. There are three main ways of doing this:

-creating a new RDF content provider which relies on a triple store to deposit the data [START_REF] Le Phuoc | RDF On the Go: An RDF storage and query processor for mobile devices[END_REF], and then using SPARQL to query it; or -translating SPARQL queries into SQL queries, and further decompose it in a form compatible with the ContentProvider interface. -translating SPARQL queries into more specific request that may be answered by an RDF Content Provider (does not require to have a Content Provider or a SQL database).

Concerning the second option, there are several available tools that can make the translation from SPARQL to SQL, like Virtuoso or D2RQ. However, these tools solve only half of the problem because the SQL queries have to be adapted to the ContentProvider interface, i.e., the queries have a particular format, different than the SQL one. This interface allows for querying only one view of a specified table at a time, hence it is not possible to ask Content Providers to perform joins.

Further challenges regarding security must be taken into account. The user of the application should be able to grant or to deny the access to its personal data. A specific vocabulary should be used in order to achieve this1 . Moreover, the dangers of granting system access to a third-party user can be avoided by using a secure authentication protocol2 .

Finally, the problem of resource consumption is mentioned here for the record. Such resource may be related to bandwidth (WiFi or 3G) that are consumed by having the RDF-Server working. In addition, such a server, and the use of our framework in general, may affect energy consumption. This will have to be precisely considered.

As can be seen, there are still technical problems in implementing a full RDF framework at the core of Android. Specific solutions must be developed.

Conclusion

Involving Android devices in the semantic web, both as consumers and providers of data, is an interesting challenge. As mentioned, it faces the issues of size of applications and URI dereferencing in mobility situations.

The application described here are available from http://swip.inrialpes.fr. A next step is to provide a more fine grained and structured access to data through SPARQL querying. Another extension when querying is the use of an alignment server in order to transform queries on the fly when different ontologies are used in the query and a corresponding content provider.

This promises to raise the issue of computation, and thus energy, cost on mobile platform.

A further issue will be the control of privacy in such a framework. But here too, we think that semantic technologies can help.

A. Demo path

  Cursor query( Uri id, String[] proj, String select, String[] selectArgs, String orderBy ) Uri insert( Uri id, ContentValues colValueList) int update( Uri id, ContentValues colValueList, String select, String[] selectArgs ) int delete( Uri id, String select, String[] selectArgs ) String getType( Uri id ) .

Figure 3 . 1 :

 31 Figure 3.1: The architecture components and the communication between them. Components with double square have a graphic user interface.

  Figure A.1 shows browsing starting from Pikoid.

Figure 4 . 1 :

 41 Figure 4.1: An example of using the RDF Browser.

Figure 5 . 1 :

 51 Figure 5.1: RDF Server response. 1 Dynamic DNS Client: https://market.android.com/details?id=org.l6n.dyndns&hl=en. 2 DynDNS: http://dyn.com/dns/ .

Figure A. 1 :

 1 Figure A.1: The Pikoid application annotates images with metadata stored as RDF. RDF-Browser allows for querying this information to the Pikoid RDFContentProvider interface and displaying it. The current picture metadata is shown in the second panel (pikoidRDFprovider/60). From there, it is possible to browse the information available in the address book (people/104) and the calendar (events/3) through the corresponding RDF Content Providers wrapping them (see Figure A.2). Finally, RDFBrowser also allows for inspecting available RDFContentProviders and the ontologies they manipulate.

Table of Contents

 of Services and Intents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Android Content Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Android URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 The RDF Content Provider Framework 3.1 The RDF Content Provider API . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 The RDF Content Resolver Service . . . . . . . . . . . . . . . . . . . . . . . . 3.3 RDF Provider wrappers for Phone applications . . . . . . . . . . . . . . . . . 3.4 Pikoid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

	1 Introduction
	2 The Android architecture
	2.1 4 RDF Browser
	5 RDF Server
	6 Technical issues: application size
	7 Perspectives: SPARQL querying
	8 Conclusion
	References
	A Demo path

http://www.w3.org/2007/uwa/Activity.html

http://developer.android.com/guide/topics/fundamentals.html

http://developer.android.com/guide/topics/providers/content-providers.html

http://www.w3.org/2009/dap/ or http://www.w3.org/TR/geolocation-API/

RDF Calendar vocabulary: http://www.w3.org/TR/rdfcal/.

Geo location vocabulary: http://www.w3.org/2003/01/geo/ .

http://poseidon.ws.dei.polimi.it/ca/?page_id=59.

http://code.google.com/p/androjena/.

http://proguard.sourceforge.net/.

http://www.w3.org/wiki/WebAccessControl.

http://www.w3.org/wiki/Foaf+ssl.

ANR Contint -ANR-10-CORD-Un ascenseur pour les donnes Project URL http://www.datalift.org/