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

Jérôme Euzenat
email: jerome.euzenat@inria.fr

Maria-Elena Roşoiu

Linked data from your pocket

The paper describes a lightweight general purpose RDF framework for Android. It allows to deal uniformly with RDF, whether it comes from the web or from applications inside the device. It extends the Android content provider framework and introduces a transparent URI dereferencing scheme allowing for exposing device content as linked data.

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 to share 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.

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. Moreover, we propose to do it along the linked data principles (provide RDF, describe in ontologies, use URIs, links to other sources).

For example, in the future, this application could be used as a personal assistant. When one would like to know which of his contacts will participate to a scientific conference, he can query 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.

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

We presented a first version of the RDF content provider in [START_REF] David | Linked data from your pocket: The android rdfcontentprovider[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.

Android Content Providers

Inside the Android system, each application runs in isolation from other applications. This Linux-based operating system 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.

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 ( [START_REF] Meier | Professional Android 2 Application Development[END_REF], [START_REF] Gargenta | Learning Android[END_REF]).

A content provider is a subclass of ContentProvider and implements the following interface: 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.

Another drawback is the SQL interface of the Android content providers. The queries are issued in an SQL manner and the results are presented to the user as a table.

The RDF Content Provider Framework

We designed the RDFContentProvider framework to give a semantic web flavour to Android and to overcome these problems. It is composed of the RDFProvider 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 1 gives an overview of the framework architecture.

The RDF Provider API

The RDFProvider API delivers the following classes and interfaces:

-RdfContentProvider: An abstract class that should be extended if one wants to create an RDF content provider. In fact, 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-object-predicate (or object-predicate) 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.

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:) URI-based 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 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 Providers for Address Book, Calendar and the Phone Sensors

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 Con-tactProvider and the CalendarProvider residing inside the Android framework.

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

RDFCalendarProvider provides access to the Android calendar using the RDF Calendar ontology 1 . 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 vocabulary2 , the one that provides a namespace for representing lat(itude) and long(itude).

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. 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 2. 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 persons 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 34 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 an 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 3. 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 Details

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: Microjena5 and Androjena6 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. ProGuard7 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.

We are currently examining how to query the device data using SPARQL. There are two 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.

At the moment, we are investigating 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 this8 . More that that, the dangers of granting system access to a third-party user can be avoided by using a secure authentication protocol 9 .

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.

A next step is to provide a more fine grained and structured access to data through SPARQL querying. 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.

  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 ) .

Fig. 1 .

 1 Fig. 1. The architecture components and the communication between them. Components with double square have a graphic user interface.

Fig. 2 .

 2 Fig. 2. An example of using the RDF Browser.

Fig. 3 .

 3 Fig. 3. RDF Server response.

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

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

Dynamic DNS Client: https://market.android.com/details?id=org.l6n. dyndns&hl=en.

DynDNS: http://dyn.com/dns/ .

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.


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

Jérôme Euzenat
email: jerome.euzenat@inria.fr

Jason J Jung
email: j2jung@gmail.com

Experimenting with ontology distances in semantic social networks: methodological remarks

Keywords: Semantic social networks, ontology distance, ontology similarity, personal ontologies, experimental methodology

Semantic social networks are social networks using ontologies for characterising resources shared within the network. It has been postulated that, in such networks, it is possible to discover social affinities between network members through measuring the similarity between the ontologies or part of ontologies they use. Using similar ontologies should reflect the cognitive disposition of the subjects. The main concern of this paper is the methodological aspect of experimenting in order to validate or invalidate such an hypothesis. Indeed, given the current lack of broad semantic social networks, it is difficult to rely on available data and experiments have to be designed from scratch. For that purpose, we first consider experimental settings that could be used and raise practical and methodological issues faced with analysing their results. We then describe a full experiments carried out according to some identified modalities and report the obtained results. The results obtained seem to invalidate the proposed hypothesis. We discuss why this may be so.

I. INTRODUCTION

Semantic social networks are characterised by a social network, i.e., relations between people, involving ontologies (?; 0). These ontologies may be used for categorising resources, such as pictures or music, or for describing relationships themselves. Using ontologies provide more expressiveness to social network users for communicating, e.g., expressing queries, as well as more flexibility since users may choose the ontology they want or design their owns. Semantic social networks may be analysed in three layers (Fig. 1) which are (i) a concept layer, (ii) a ontology layer, and (iii) a social layer.

We are not considering ontologies here as a monolithic reference classification agreed by a group. Our focus is rather on personal ontologies that people may build for personal purposes and that may be used for communicating between them. The goal of these people is not to build the ultimate ontology but rather to design an ontology that meet their needs and which may evolve if these needs evolve. These are true ontology because people make efforts to model their domain and sometimes to reuse existing modeling, even if these people do not feel expert in one domain nor in modeling ontologies.

A common hypothesis is that, in semantic social networks, the closer the ontologies used by people, the more likely they are to develop fruitful relations. This hypothesis may be exploited to efficiently support social collaboration between people by estimating potential relationships between them and organizing communities over the social networks. Contrary to other approaches relying on relationships between users, such methods would take advantage of distances between user ontologies. Instead of clustering people who know each others, it would group people using similar ontologies assuming that they have some chance to share interests. The methodology is the following:

1) compute similarity between user ontologies, 2) cluster users from this similarity, e.g., by using hierarchical clustering algorithms. Ontology distances and similarities in semantic social networks can be computed from:

• the ontology space (third layer),

• the alignment space (second layer), and • a combination between both ontology space and alignment space. In this study, we want to test this hypothesis and to evaluate measures for comparing ontologies in this context. We would like to evaluate the accuracy of various such measures in predicting affinity between users.

For that purpose, after considering the state of the art in semantic social networks (Sect. II) we consider the design space of experiments for evaluating the hypothesis (Sect. III) in order to illustrate the variability and difficulty of such experiments. Then we relate the implementation of such an experiment (Sect. IV) and analyse its results (Sect. V).

II. RELATED WORK

Since (0) has shown how to build semantics-based social networks, there have been various applications, e.g., BibSter (?) and GrouPeer. In particular, (0; 0) proposes an elaborated method for identifying what types of semantics can be applied to relationships between people in Polyphonet. Most of these methods have focused on discovering co-occurrence patterns between users, and they have assumed that such co-occurrence patterns should be an important evidence implying social connections. While they focus on discovering common human behaviors, e.g., tagging and bookmarking, semantic overlay networks (0; 0) utilise auxiliary information to compare members. Ontologies themselves have not been exploited for finding relations between people. (?) went further by using similarity between ontology entities for routing queries to supposedly adequate peers, but did not used this for inferring affinities independently of queries.

Ontology-based overlay structures (0; 0), have been proposed to target user-created ontologies as well as semantic matchings between the ontologies. Hence, the semantic matchings between ontologies are assumed to increase the strength of social affinity between the corresponding people. However, this hypothesis has not been evaluated experimentally.

III. EXPERIMENT DESIGN

The goal of the experiment is to test the main hypothesis and to evaluate the accuracy of similarity measures. For that purpose, it is necessary to collect information about semantic social networks and affinity between people. This kind of information is not particularly easy to obtain: there are no widely used semantic social network yet, and it is difficult to obtain non biased affinity information.

A. Acquiring semantic social networks

The main problem we are facing is the acquisition of semantic social network data, i.e., linked (even loosely) sets of ontologies.

There are five possible strategies we can think of for acquiring the semantic social network.

1) Strategy 1: Finding some existing semantic social network: This is the most natural strategy since it would rely on real world data and not data made on purpose for the experiment.

• pros: This does not cost effort. The data is realistic.

• cons: No corpus readily available. There are no currently developed semantic social network. 2) Strategy 2: Using collaborative ontology building systems: Collaborative ontology building systems, e.g., Cupboard (0) supports online cooperative ontology management. They are aimed at ontology engineers and allow them for storing online and annotating the ontology they use. Using such systems would allow to have direct relation between people and real ontologies in a detailed way. On the other side, the relational aspect of the network would not be really developed.

• pros: It is maintained. All the ontologies of the web are there, through Watson. • cons: Cupboard is for ontology engineers, not for social networks, so this may lead to non relevant results.

3) Strategy 3: Developing a semantic social network: We can invite some volunteers, e.g., students and team members, to use a semantic social network software (PicSter, BibSter) to perform an experiment. (0) already run small experiments under a dedicated peer-to-peer software (PicSter).

• pros: The experiment would be extensive.

• cons: The software on which these experiments were based is not anymore maintained. This require additional involvement from the subjects.

4) Strategy 4: Using some existing social network data using tags instead of ontologies: It may be possible to use classical social network data and to consider how this approximates semantic social networks. There is data available in which ontologies are replaced by rich set of tags ("folksonomies"). These sets of tags could be considered as ontologies without structures. This would still allow to use some measures on these sets of tags. We could also have trivial alignments on tags (based on WordNet for instance).

• pros: It will be easier to find data. The approach could prove useful in a concrete setting. • cons: These are not real ontologies, so no semantic social networks.

5) Strategy 5: Simulating social network data within a controlled experiment: This is the usual procedure in experimental psychology: asking a set of people (subjects) to perform a task that is assumed to have the same characteristics as the tested task.

• pros: Relatively easy to perform; • cons: The experiment is remote from real semantic social network use.

B. Acquiring affinity information

The second problem to address is to determine the relatedness between users. There are basically two ways:

• direct: Asking people to evaluate their affinity with other people.

• indirect: Inferring it from some cues. For instance, their tendency to annotate the same pictures.

We consider again four different strategy to acquire these data. We consider them under the constraint that we will ask people to annotate pictures with ontologies and that the choice of pictures may be used for assessing affinity. 1) Strategy 1: Spontaneous affinity grouping: This is the simplest strategy: Participants are asked to express their affinity, for instance on a scale. The same |P | pictures are given to all the subjects.

• pros: All students have the same pictures. 2) Strategy 2: Thematic grouping: Participants are given different sets of pictures corresponding to different topics:

• pros: Topics will induce affinity.

• cons: We will observe the correlation between ontology topics and not necessarily between people. 3) Strategy 3: Hybrid: This strategy is a mix of the two former strategies: People are asked to be grouped together by affinity and people with same affinity will have similar (but not quite the same) set of pictures.

Alternatively, they can be asked to choose groups of two pictures among {i, j}, {l, m}, {r, s}, {u, v} and {x, y} (see Figure 2), but the former option is better if feasible.

Participants will be grouped by affinity such that, the closer the subjects, the larger number of pictures they share. This aims at counterbalancing the effect of pictures: indeed, if non close subjects have the same pictures, they may end up with close ontologies anyway.

• pros: Since topics and affinity are set together, there should at least be similarity to be found. • cons: There is still a part of the correlation that will be measured by the result which will be due to the topics. 4) Strategy 4: Indirect affinity grouping: Each subject is given a set of 10 pictures. Participants are allowed to trade their pictures (exchange pictures one-by-one).

This can be absolute: The more picture in common, the highest the affinity.

This may be relative: If A has traded for x against y to B, and C has x. Then A is closer to C than to B. Moreover, if C has obtained x by trading it with D, then A is also closer from C than D.

• pros: Topics will induce affinity. The organisation is obtained spontaneously. This reproduces basically things that happen in social (exchange) networks. • cons: It is not possible to ensure that this method will induce a clear order without too many pictures. Order agreement is difficult to test.

C. Population

We can consider three kind of audience to run the experiment:

• our teams pros: People are available.

cons: They are not really available. They may be biased (at least this can be argued).

• students pros: This is the usual procedure, which allows to run the experiment quickly. cons: They should be sufficiently trained.

• outsiders: exploiting a structure like a VoCamp may be an idea.

pros: Enthousiasm.

cons: There is no control over the real population.

D. Measuring agreement

In order to measure the agreement between ontology similarity and subject affinity there may be different modalities. Indeed, no one expect that similarity and affinity will be expressed on the same scale and coincide exactly. What is important is the order induced by such affinities.

Hence, the agreement may be tested through different strategies.

1) Strategy 1: Order agreement: It is possible to compare the two orders and compute an agreement index. For this purpose, there exists measures such as Kendall's rank correlation and its variants (0). They have been adapted in order to consider partial orders.

• pros: Easy to evaluate.

• cons: Require full order data from all subjects.

2) Strategy 2: Cluster agreement: Another opportunity is to use affinity and similarity for defining clusters in the graphs of subjects (which should reveal communities) and comparing such clusters.

• pros: Closer to the particular task of community mining.

• cons: Depends on the clustering technique used.

E. Specific problem

There is a specific problem related to the evaluation of the hypothesis. Indeed, it is claimed that:

1) distance between ontologies is a good approximation of distance between people; 2) distance between ontologies may reveal unknown proximity between people. What can happen with such an experiment:

• we find that distance corresponds to affinity: this is fine, this validates claim (1); • we find that distance does not correspond to affinity: we still can pretend that this validates claim (2). So the results of such experiments must be taken with care. For instance, it could be possible that within each identified group of people we validate claim (1) and across groups, we validate claim (2). This would have to be achieved by checking a posteriori the validity of (2).

In the remainder, we describe an actual experiment for testing the hypothesis.

IV. EXPERIMENT EXECUTION

The goal of this experiment is to obtain a semantic social network and affinity between people involved in this network.

We first tried to implement Strategy 4 of network acquisition and a variant of Strategy 2 of affinity acquisition (through Flickr), but we failed to gather sufficient information about affinity. Then we resorted to use Strategy 5 for network acquisition and the Strategy 1 for affinity acquisition on some of our students. For that purpose we needed to have people creating ontologies. In order to stimulate them, we presented this task as an exam in ontology engineering.

We also needed that people reveal their proximity with each others. However, it is quite difficult to obtain proximity assessment and ontologies in a population we had to resort to questionnaires. The task was given to the students as a rated homework to be returned within one week. The subjects were asked to complete the task individually.

A. Material and methods

After all homeworks were completed and rated, subjects were asked to fill a questionnaire about their opinion about various aspects of the task.

2) Task: Participants have been given |P | = 22 pictures each representing some wildlife scene featuring an animal. They have been asked, as homework, to create an ontology and to annotate the pictures. They have been told that the marks would be on the correctness of ontologies and of the design of ontologies and annotations.

Each subject has been asked to return one week later an ontology and annotations of these pictures using the ontology.

See Appendix 1 for the instructions given to students.

In addition, students have been asked, through a questionnaire (Appendix ??), to provide information about their affinity with other students. In order to not introduce a too large bias, this questionnaire was about different aspects of the task, e.g., time spent, strategy. Affinity information was collected through direct assessment (Which other students do you feel have the same state of mind as yours) as well as indirect information (What is your favorite animal). We only exploited the former.

3) Measure: From the ontologies provided by the subjects, we computed similarity between subjects with similarity measures provided by the OntoSim library. OntoSim is an API dedicated to the computation of distance or similarity measures between ontologies and ontology entities. It provides measures used for matching ontologies and support for the development 1 http://intelligent.pe.kr/papers/2012/CCI-SMC/Appendix/Appendix.pdf of new measures. We tested both ontology space and alignment space measures (0).

More precisely we considered:

• a vector space measure based on the cosine distance in a multidimensional space where each ontology corresponds to a point represented by the TFIDF measure on the terms used in the ontology; • an ontology space distance using a maximal coupling of the ontology entities based on their names; • an ontology space distance using a maximal coupling of the ontology entities based on the triples they appear in; • two alignment space measures based on the paths between ontologies; • two alignment space measures based on the coverage of the alignment paths between ontologies; For alignment space measures, we computed all alignments between pairs of ontologies based on the edit-distance on class names and we applied a threshold of .7 to the resulting alignment.

B. Collected ontologies

In Appendix2 we display the class identifiers used by different users. In green we display those terms which are used by at least one other user. Terms followed by an asterisk (*) need correction before being syntactically the same. In orange, are those terms that can easily be identified as a hyponym/hypernym of another mostly because there is a restricting adjective. In blue, there is a problem that will be explained latter.

Among the 19 students, 4 returned ontologies without identified classes and have been discarded. We have tried to further group the terms found in ontologies in relatively natural domains (that may also be called modules). We identified six of them: species as found in the classification of species, common names used for animals, area location which have been massively used and locomotion means, diet and gender which can be identified but have been less used. Table 3 provides the use of these different groups by the students. We only counted true classes and ignored those classes which identified ontologies like SexValue, habitat or diet.

Table 4 presents the various parameters of the domains as they were used by the subjects. It shows how domains can connect users.

1) Analysis: We can draw several lessons from this set of data.

The first remark is that there is a lot of connections between these ontologies. We already have a network of naive ontologies which are heavily naturally interconnected. These connections come both from students using the same standardised module (species) and from students using the same common names (when the need is the same and the population homogeneous, there are many trivial matches). This remark seems to be important because currently we are lacking examples of networks of ontologies but it seems that they are not that difficult to produce.

The second remark is that there is an important presence of the identified domains: only 6 domains among 14 students, this is impressive, but the task was easy. These domains would certainly be the things on which people spontaneously agree. Moreover, in a task like this one, they converged towards the same kind of domains.

A third remark is the importance of standard vocabularies. Even if students were taught about reusing existing vocabularies, the importance of the reuse of the classification of species is stunning. This classification (whose terms may be easily found from wikipedia) provides many links between people. On the other side, many students felt the need to use some geographic ontology but they were not aware of any standard classification so they invented one, or rather they invented 6 of them, which do not match much.

The blue carnivora is a special case: there seems to be some students wanting to classify animals from their diet who used the carnivora concepts. But there are also students who found the Carnivora order in the classification of species and who found natural to add Herbivora as a taxon. However, there is no such class in the classification of species: Carnivora is a Mammalia characterised by the shape of the skull and dentition (which, of course may be related to eating meat) but does not refer to any diet (some Carnivora are not carnivore, and many carnivore are not Carnivora, like squales which are not mammals).

We only considered here the class labels in the ontologies. It would be interesting to consider the topology of the ontology. One conjecture is that those who have used the classification of species have also preserved its hierarchy.

C. Collected affinity

We have surveyed the students to know if there is some affinity between some of them. This allows for comparing their asserted affinity with the distances between their ontologies. This should also provide us with information about the likeliness that they shared their information.

1) Results: The results of the questionnaire are given in Table 5 . Students provided between one to three other students as affinity bearers.

2) Analysis: It is possible to cluster the directed graph provided by these assertions into 8 clusters of complete subgraphs or 7 strongly connected components (see Figure 6 ). Such clusters clearly represent affinity nests in the perception of subjects.

These are made of very few elements, thus we can conjecture that there are really strong affinity links (because affinity statements have been provided in both directions). Affinity outside these clusters may be considered secondary.

V. AGREEMENT BETWEEN SIMILARITY MEASURES AND

AFFINITY

Our goal is to check if there is some correlation between the affinities given by students and those inferred by ontology measures.

A. Method

For each selected measure, we computed the similarity value between each pair of ontologies. From these measures, we established a ranking from the closest ontology to the farthest one. Then, for each ontology, we compared the average ranking of ontologies used by the subjects selected by the student with the best ranking we can obtain with the same number of ontologies.

Given -→ u the ranks (in ascending order) of the n ontologies used by subjects with which a student has declared affinity and -→ v all the ranks (in ascending order), the agreement between the similarity and the the student affinities is defined as follow:

agreement( - → u , - → v ) = 1 - n i=1 (u i -v i ) n
We also have considered two different cluster comparisons:

• the first one using hierarchical clustering of subjects based on their similarity; • the second by defining the graph whose edges exists when the ontologies have a similarity higher than a threshold (here .4). This is similar to the graph of Figure 7 and the same operation (component decomposition can be applied).

B. Result analysis

Table 8 gives the agreements for each measure and each subject.

We reduced the alignment space path based measure to a single column since the results were the same (only the presence of an alignment path is taken into account and we had such alignments). These measures are not meaningful because all ontologies have the same rank. This remark also concerns VS(cosine+TFIDF) to a lower extent.

Alignment space measures more agreed with the given affinities than ontology space measures. This can be explained by the fact than some ontologies (2149, 2132, 1530 and 1643) do not contain named classes and then they are not comparable with other ontologies by using lexical features (used by these ontology space measures).

However, the level of correlation between affinity asserted by students and the one predicted by the measures are not particularly high, even at .72. This is confirmed by the two cluster analyses that we performed: the cluster computed by either hierarchical clustering or component analysis are largely different from those provided by affinity. Figure 3 In summary, it seems that this experiment contradicts the hypothesis that similarity between ontologies reflects affinity between users in semantic social networks.

VI. CONCLUSION

The goal in this paper was to consider the experimental evaluation of hypotheses and measures for assessing people affinity in semantic social networks through ontology similarity. We offered various alternative settings for such an experiment and analysed the pros and cons of each solution. We performed one such experiment taking into account material availability. The results of this experiment are leaning towards invalidating the proposed hypothesis.

Several parameters may be considered that once corrected may lead to reconsider or to particularize these results: the maturity and training of students, the direct acquisition of affinity statement, or the fact that similarity indeed reveals unknown affinity (see §III-E) which cannot be ruled out.

It would be interesting to consider other suggested experimental settings to see if they confirm this result. Especially using real massive data sets would be an important step.

Peer

  Fig. 1: A semantic social network (Inspired from (0)).

Fig. 2 :

 2 Fig.2: Distribution of pictures to subjects. Each leaf is a subject, each letter is a different picture.

  1) Population: The subjects were |U | = 19 undergraduate students of a university taking an AI course. They were given one hour training in ontologies and Protégé.

  displays the graph made of the highest union path coverage similarity for each subject (similarities within 3% are considered ties). Fig. 3: Neighborhood social graphs and its complete subgraphs obtained from ontology similarity (in bold are arrows representing remaining strongly connected components).

	#16	#3	#18
	#1	#2	#17	#6
	#7	#14	#13	#10
	#12	#9	#8	#4
	#19	#15	#11	#5

http://intelligent.pe.kr/papers/2012/CCI-SMC/Appendix/Appendix.pdf

http://intelligent.pe.kr/papers/2012/CCI-SMC/Tables/Table1.pdf

http://intelligent.pe.kr/papers/2012/CCI-SMC/Tables/Table2.pdf

http://intelligent.pe.kr/papers/2012/CCI-SMC/Tables/Table3.pdf

http://intelligent.pe.kr/papers/2012/CCI-SMC/Figures/Figure3.pdf

http://intelligent.pe.kr/papers/2012/CCI-SMC/Figures/Figure3.pdf

http://intelligent.pe.kr/papers/2012/CCI-SMC/Tables/Table4.pdf

ACKNOWLEDGMENT This work was supported by the Korea Foundation for International Cooperation of Science & Technology(KICOS) through a grant provided by the Korean Ministry of Education, Science & Technology (MEST) in 2009 (No. K20904000009).


A modest proposal for data interlinking evaluation *

Jérôme Euzenat

INRIA & LIG (Jerome.Euzenat@inria.fr) Data interlinking, i.e., finding links between different linked data sets, is similar to ontology matching in various respects and would benefit from widely accepted evaluations such as the Ontology Alignment Evaluation Initiative. Instance matching evaluation has been performed as part of OAEI since 2009. Yet, there has been so far few participants to IM@OAEI and there is still no largely acknowledged benchmark for data interlinking activites.

In order to secure more participation, we analyse the specificities of data interlinking and propose diverse modalities for evaluating data interlinking.

The problem

The data interlinking problem could be described in the same way as the ontology matching problem was: Given two linked data sets, usually tied to their vocabularies (or ontologies), Generate a link set, i.e., a set of sameAs links between entities of the two data sets.

We concentrate on sameAs links because these are by far the most important links to be retrieved when interlinking.

In terms of evaluation, the same kind of procedure as in ontology matching may be used by comparing the provided link set to a reference link set. Measures such as precision, recall or time and memory consumption may be used.

Given the size of the data, it is difficult to provide correct and more specifically complete reference link sets. The OAEI 2011 IM task solved the problem by using links already provided by data providers. This is valuable when these links are curated manually. However, the quality of these links may still be questioned.

Specific interlinking features

We present some features of the way data interlinking is performed nowadays, that distinguish it from ontology matching.

Blocking vs. matching Ontology matching, when confronted to large ontologies, cannot start upfront comparing instances with a similarity measure. The same applies to data interlinking. Hence many data interlinking procedures are designed in two steps: blocking divides the sets of pairs of resources into subsets called blocks in which matching resources should be part;

matching compares entities in the same block in order to decide if they are the same.

Since these two steps are clearly different, well identified, and it is possible to use different matching methods with different blocking techniques, it is useful to evaluate independently the capacities of these two techniques.

In particular, from a reference link set, it is possible to determine how many pairs in the link set a particular blocking technique misses (blocking recall) and how many non necessary pairs a blocking technique imposes to compare (blocking precision). Similarly, a matching technique could be evaluated with a given block structure if this is necessary: the evaluation can be achieved by comparing the part of the reference alignments which can be found from the given blocks.

Scalability Linked data has to deal with large amounts of data. Even if this is also the case in ontology matching, automatic data interlinking is really useful with large amounts of data. So, besides qualitative evaluation, it is critical to assess the behaviour of interlinking tools when data sizes get larger.

Learning Another effect of the size of linked data is that learning is more relevant, mainly for two reasons:

-The size of the data makes it difficult to study it for choosing the best approach and after extracting a training sample, much work remains to be done; -The regularity of the data facilitates machine learning efficiency. So, it is not surprising that learning methods are successful in data interlinking. This provides incentive to evaluate data interlinking techniques using machine learning. For that purpose, it is necessary to provide tests in which a part of the reference link set is provided as training set to the systems which have then to deliver a complete link set.

Instance and ontology matching Data interlinking is dependent on the vocabularies used in data sets. This vocabulary may be described by a schema or an ontology or not described explicitly. Some matchers may be specialised for some of these situations and it may be useful to recognise this by providing different evaluation tasks. In particular, it seems useful to test these configurations:

without published vocabulary (or ontology), with the same vocabulary or, alternatively, with aligned vocabularies, with different vocabularies, without alignment (as in the IIMB data set of IM@OAEI).

Conclusions

In conclusion, it seems that in addition to or in combination with existing tasks provided in IM@OAEI, such benchmarks should consider including:

scalability tests (retaining one tenth, one hundredth, one thousandth of the data); training sets for tools using machine learning; separating the evaluation of blocking and matching for users who specifically consider one of these aspects only; tests with no ontology, the same ontology and different ontologies.

* This work has been partially supported by the French National Research Agency (ANR) under grant ANR-10-CORD-009 (Datalift). A longer version of the proposal is available at ftp://ftp.inrialpes.fr/pub/exmo/publications/euzenat2012b.pdf


François Scharffe

Ghislain Atemezing

Raphaël Troncy

Fabien Gandon

Serena Villata

Bénédicte Bucher

Fayçal Hamdi

Laurent Bihanic

Gabriel Képéklian

Franck Cotton

Franc ¸ois Scharffe

Fayc ¸al Hamdi

Jérôme Euzenat

Zhengjie Fan

Pierre-Yves Vandenbussche

Bernard Vatant

Enabling linked data publication with the Datalift platform

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

One decisive step in the transition towards a semantic and ubiquitous Web is the availability of linked and structured data. Structured data is already present in databases, in metadata attached to medias, and in millions of spreadsheets created everyday across the world. The recent emergence of linked data radically changes the way structured data is being considered. By giving standard formats for the publication and interconnection of structured data, linked data transforms the Web into a giant database. However, even if the raw data is there, even if the publishing and interlinking technology is there, the transition from raw published data to interlinked semantic data still needs to be done.

Datalift 1 ambition is to act as a catalyst for the emergence of the Web of Data [START_REF] Heath | Linked Data: Evolving the Web into a Global Data Space[END_REF]. Made of large raw data sources interlinked together, the Web of Data takes advantage of Semantic Web technologies in order to ensure interoperability and intelligibility of the data. Adding data to the Web of Data consists of (i) publishing data as RDF graphs: a standard data format, (ii) linking these datasets together, by identifying equivalent resources in other data sources, (iii) describing the vocabulary used in published data through ontologies.

The Web of Data has taken recently a strong acceleration with the publication of large datasets by public institutions around the world and experiments being made to publish these data as Linked Data.

However, if isolated data publication initiatives using Semantic Web technologies exist, they remain limited for several reasons: 1. Similarly to the Web, the power of which comes from the interconnection of pages together through hyperlinks, the Web of Data will only make sense if the data it contains are interconnected. A few interlinking tools already exist but require too much manual intervention for reaching Web scale. 2. A large number of ontologies covering various domains are quickly appearing, raising the following problems: many ontologies overlap and require to be aligned together for proper interoperability between the data they describe. Selecting the appropriate ontology for describing a dataset is a tedious task. Once an ontology is selected, the data to be published eventually needs to be converted in order to be linked to the ontology. Solving these technical problems require expertise which leads to publication processes that are not suited for large amounts of heterogeneous data. 3. In order to ensure a publication space which is at the same time open and giving to each publisher its rights on the published data, it is necessary to provide methods for rights management and data access. 4. Finally, and again analogically with the Web, a critical amount of published data is needed in order to create a snowball effect similar to the one that led the Web to take the importance it has nowadays.

The goal of Datalift is to address these four challenges in an integrated way. More specifically, to provide a complete path from raw data to fully interlinked, identified, and qualified linked data sets, we develop a platform for supporting the processes of:

• selecting ontologies for publishing data;

• converting data to the appropriate format (RDF using the selected ontology); • interlinking data with other data sources;

• publishing linked data.

In the remainder of this paper, we detail this framework and its implementation: the Datalift platform.

Datalift framework

This section introduces the steps needed to bring raw structured data to interlinked, identified, and qualified RDF datasets.

Vocabulary Selection: Linked Open Vocabularies

Vocabularies selection is about the many dialects (RDFS and OWL ontologies) used in the growing linked data Web. Most popular ones form now a core of Semantic Web standards but many more are published and used. Not only linked data leverage a growing set of vocabularies, but vocabularies themselves rely more and more on each other through reusing, refining or extending, stating equivalences, declaring metadata.

The publisher of a dataset should be able to select the vocabularies that are the most suitable to describe the data, and the least possible terms should be created specifically for a dataset publication task. The problem is thus to provide means for a data publisher to be able to locate the vocabularies suited for the published data.

The Linked Open Vocabularies2 (LOV) objective is to provide easy access methods to this ecosystem of vocabularies, and in particular by making explicit the ways they link to each other and providing metrics on how they are used in the linked data cloud, to improve their understanding, visibility and usability, and the overall quality.

LOV targets both vocabulary users and vocabulary managers.

• Vocabulary users are provided with a global view of available vocabularies, complete with precious metadata enabling them to select the best available vocabularies for describing their data, and assess the reliability of their publishers and publication process. • Vocabulary managers are provided with feedback on the usability of what they maintain and publish, common best practices their publication should stick to in order to keep being reliably usable in the long run. The LOV tool is further described later in Section .

Creating URIs

The Web uses URIs (Uniform Resource Identifiers) as a single global identification system. The global scope of URIs promotes large-scale network effects, in order to benefit from the value of Linked Data, government and governmental agencies need to identify their resources using URIs.

We provide a set of general principles aimed at helping stakeholders to define and manage URIs for their resources. These principles are based on existing best practices as they are currently collected within the W3C Government Linked Data Working Group3 . The first thing to do is to identify the type of entities the data to be published is about. For example, the National Institute of the Geographic and Forest Information (IGN) in France maintains a Large Scale Reference of the topography of the French territory with a 1-meter resolution. In this database, one can find information about departments, cities, monuments, roads and many other types of geographical entities. This analysis of the data will provide the top level objects that will be present in the URI scheme.

It is a good practice to have a base URI of the form http://{sector}.{domain} where sector refers to an activity (e.g. legislation, education, topography) and domain refers to an internet top-level domain name. From a base URI, we propose the following scheme depending on the nature of the resource the URI identifies:

• URI for ontologies or vocabularies: /ontology/shortname#class

• URI for real-world things: /id/type/id

• URI for data about real-world things: /data/type/id

• URI for datasets: /data/dataset/version For example, the Eiffel tower will be identified by http://topolography.ign.fr/id/monument/PAICULOI000000 0000142427 while the 7th district of Paris will be identified by http://topolography.ign.fr/id/arrondissement/SURFCOMM 0000000013680725. These URIs must be persistent and dereferencable. Upon a retrieval request, a web server should redirect the /id/ URI to the /data/ URI and serve an HTML or RDF representation of the resource according to the instruction of the user agent.

Summarizing, the URIs to be minted should be short and human readable, and incorporate as much as possible existing identifiers where available. While IRIs can also be used for identifying resources, the internationalization of the identifiers yields numerous problems that softwares cannot deal with correctly at the moment.

Converting data formats to RDF

Once URIs are created and a set of vocabulary terms able to represent the data is selected, it is time to convert the source dataset into RDF. Many tools exist to convert various structured data sources to RDF. 4 . The major source of structured data on the Web comes from of spreadsheets, relational databases and XML files.

Our approach is in two steps. First, a conversion from the source format to raw RDF is performed. Second, a conversion of the raw RDF into "well-formed" RDF using selected vocabularies is performed using SPARQL Construct queries. The first step can be automated in most of the cases.

Most tools provide spreadsheet conversion to CSV, and CSV to RDF is straightforward, each line becoming a resource, and columns becoming RDF properties. The W3C RDB2RDF working group 5 prepares two recommendations for mapping relational databases to RDF: the DirectMapping approach automatically generates RDF from the tables names for classes and column names for properties. This approach allows to quickly obtain RDF from a relational database but without using any vocabulary. The other approach, R2RML, provides a mapping language allowing to assign vocabulary terms to the database schema. In the case of XML, a generic XSLT transformation can be performed to produce RDF from a wide range of XML documents.

Access rights

In the Web of Data, providers expose their content publicly, knowing that it is not safe. This may prevent further publication of datasets, at the expense of the growth of the Web of Data itself. Moreover, the mobile, ubiquitous Web is continuously evolving, enabling new scenarios in consuming and contributing to the Web of Data. We must therefore not ignore the mobile context in which data consumption takes place. [START_REF] Costabello | Linked data access goes mobile: Context-aware authorization for graph stores[END_REF] propose a framework which relies on two complementary lightweight vocabularies, S4AC6 for access control, and PRISSMA7 for modeling the mobile context. Context is seen as an encompassing term, an information space defined as the sum of three different dimensions: the User model, the Device features and the Environment in which the request is performed. Access Policies protect a named graph, thus targeting single triples, if needed. Each Access Policy is associated to a privilege level and includes a set of context-aware Access Conditions, i.e. constraints that must be satisfied, conjunctively or disjunctively, to access the protected resources. Access Conditions are implemented as SPARQL 1.1 ASK queries. At runtime, Access Policies are associated to the actual mobile context used to evaluate the set of Access Conditions.

The access control evaluation procedure includes the following main steps: (1) the mobile consumer queries the SPARQL endpoint. Contextual information is sent along with the query and saved as named graph using SPARQL 1.1 Update Language statements8 . (2) The client query is filtered by the Access Control Manager instead of being directly executed on the SPARQL endpoint. (3) The Access Control Manager selects the set of policies affecting the client query and after their evaluation returns the set of accessible named graphs. (4) The client query is executed only on the accessible named graphs and (5) the result of the query is returned to the consumer.

Dataset publication

When the RDF dataset is ready it can be published on a web server and a made available as Linked Data. Various RDF triple stores are available providing access mechanisms to the data. Publication of the dataset also includes attaching metadata information using the VoID vocabulary9 , providing a Semantic Sitemap10 and referencing it on The Data Hub11 .

Linking datasets

Data linking [START_REF] Ferrara | Data linking for the semantic web[END_REF]) is a set of techniques for identifying similar instances between datasets. This can be done by comparing the property values of the instances. String matching the most basic technique to compare whether two values are similar or not. Machine learning is also used to find out the most efficient comparison pattern, as shown in [START_REF] Hu | A self-training approach for resolving object coreference on the semantic web[END_REF][START_REF] Isele | Learning linkage rules using genetic programming[END_REF][START_REF] Ngonga Ngomo | Raven -active learning of link specifications[END_REF]. That is, which property values should be compared and what comparison functions should be used. There are two machine learning branches: supervised method and unsupervised method. Supervised method uses a training dataset to find out the most suitable matching pattern [START_REF] Hu | A self-training approach for resolving object coreference on the semantic web[END_REF][START_REF] Nikolov | Handling instance coreferencing in the knofuss architecture[END_REF]. Now more work focus on exploring unsupervised method for interlinking instances, for it saves time on collecting training sets [START_REF] Araújo | Serimi -resource description similarity, rdf instance matching and interlinking[END_REF]) . Ontology alignment is also used to decrease the comparison scale. For it is composed of correspondences on classes and properties, it is a heuristics to show from which classes to find similar instances, and comparing which property's values for judging similarity or not. Besides, graph structure and statistical techniques are also used for matching. Usually, these techniques are combined to fulfill the interlinking process. One of the main problem lies in the number of comparison to perform in order to evaluate the similarities between two datasets. If there are M instances in the source dataset and N instances in the target dataset. There should be M * N times comparisons. In order to reduce this number, several strategies are proposed. The fundamental strategy is to use keys to index entities so that entities may be looked up for from their keys. However, keys like item IDs or administrative codes often cannot be compared as they appear in only one of the two datasets. It is thus needed to be able to compute various keys on the two dataset to try finding a corresponding one. It is a combination of all these techniques, together with a proper user interface to set the tool parameters that will lead to efficient data linking.

Implementation

This section describes the Datalift platform as it is currently implemented. The platform is designed to be modular, each module performing tasks of the following workflow. The platform can be downloaded at: https://gforge.inria.fr/projects/datalift.

Datalift workflow

The actual workflow of the data lifting process is depicted on Figure 1.

The user begins the data lifting process by submitting a structured data source in one of the supported formats, may it be a CSV or XML file, a relational database or an existing RDF source. The system converts this file to RDF by following a set of rules to apply depending on the submitted file format. This conversion does not take into account vocabularies, namespaces nor links to existing datasets. We call it raw RDF conversion. From this point, we have a unique format: RDF, to work on data sources. Further modifications can be applied as follows. The Selection step asks the user to input a set of vocabularies terms that will be used to describe the lifted data. Once the terms are selected, they can be mapped to the raw RDF and then converted to properly formatted RDF. Technically, a set of SPARQL construct queries Figure 1: Datalift Data Workflow is performed to modify the source RDF graph and generate the target RDF using the selected vocabularies. Other modifications can be performed using enhancing modules. Enhancements include replacing a characters string with a URI from another dataset (for example "Montpellier" becomes http://dbpedia.org/resource/Montpellier) or adding metadata to the published dataset. The data can then be published on the platform SPARQL endpoint. The last step in the process aims at providing links from the newly published dataset to other datasets already published as Linked Data on the Web. The interconnection modules give the possibility to achieve this linkage.

We next describe the platform architecture and the modules currently implementing this workflow.

Platform Architecture

The Datalift platform is a Java-based development and runtime environment for deploying RDF-based REST web services. It includes:

The Datalift framework : a set of Java APIs for developing Datalift components The Datalift core : an implementation of the Datalift framework as a JEE web application A set of RDF stores : (a.k.a. triple stores), to persist RDF data, accessed using the OpenRDF Sesame 2 API Third-party components : (or modules) adding general purpose or customer-specific features to the platform.

The Datalift framework provides a high-level view of the underlying runtime environment to ease the development of RDF-based services, automating access to the RDF stores (regardless the actual RDF engine being used), enforcing authentication and access control, applying URI naming policy, etc. It also provides a file system abstraction to support deployment on distributed (grid) storage.

Once RDF data are produced and persisted in one of the RDF stores, the platform makes them available for Figure 2: Datalift Architecture both direct access (as a web resource accessible through an HTTP(S) URL) and querying (SPARQL 1.1). The provided SPARQL endpoint includes advanced features such as query routing between the available RDF stores, access control, data filtering, data enrichment (e.g. to attach licensing information to the query results), etc. Whereas Datalift components have full access to the RDF stores, including SPARQL Update, the public SPARQL endpoint only offers querying.

The Datalift core is one realization of the Datalift framework for deploying the platform as a JEE web application or a single-user standalone desktop application (actually a web application wrapped in a native executable) . It relies on Jersey (JAX-RS reference implementation), Apache Shiro (security framework) and Apache Velocity (HTML page template engines).

The well-supported OpenRDF Sesame 2 API allows Datalift components to transparently interface with many RDF store products, both open-source (OpenRDF Sesame) and commercial (OpenLink Virtuoso, Ontotext OWLIM, Franz AllegroGraph, etc.). A central configuration file manages the definition of the RDF stores and their visibility (public or private). Public stores are accessible for SPARQL querying or direct RDF resource access without requiring user to first authenticate.

Each Datalift component is packaged as a JAR file and can include REST web services, dynamic HTML pages, static resources, third-party libraries as well as implementations of various internal services (RDF store connector, URI mapping policy, native data parser, etc.). Components are deployed by simply dropping them in a (configurable) directory. Each of them is executed in a sandbox (dedicated Java class loader) to avoid conflict between module using different versions of the same third-party library.

An example Datalift component included in the default distribution is the Project Manager. this module provides a user-friendly interface for lifting datasets from various native formats (CSV, XML, relational databases, etc.) into RDF by applying a sequence of data transformations: direct mapping to "raw" RDF, conversion to a selected ontology, publication of the transformed data, interlinking with public datasets (e.g. DBpedia), etc.

Modules

The modules developed in the platform are described below.

LOV Module. LOV provides functionalities for search and quality assessment among the vocabularies ecosystem, but it also aims at promoting a sustainable social management for this ecosystem.

The LOV dataset contains the description of RDFS vocabularies or OWL ontologies used or usable by datasets in the Linked Data Cloud. Those descriptions contain metadata either formally declared by the vocabulary publishers or added by the LOV curators. Beyond usual metadata using Dublin Core, voiD, or BIBO, new and original description elements are added, using the VOAF vocabulary12 to state how vocabularies rely on, extend, specify, annotate or otherwise link to each other. Those relationships make the LOV dataset a growing ecosystem of interlinked vocabularies supported by an equally growing social network of creators, publishers and curators.

To be included in the LOV dataset, a vocabulary has to satisfy the following requirements:

• To be expressed in one of the Semantic Web ontology languages : RDFS or some species of OWL • To be published and freely available on the Web • To be retrievable by content negotiation from its namespace URI • To be small enough to be easily integrated and re-used, in part or as a whole, by other vocabularies.

Apart from the dataset, the LOV tool provides the following features:

• The "LOV Aggregator" feature aggregates all vocabularies in a single endpoint/dump file. Last version of each vocabulary is checked on a daily basis. This endpoint is used to extract data about vocabularies and is used to generate statistics ("LOV Stat" feature) or to support research ("LOV Search" feature). While a vocabulary is aggregated, for each vocabulary elements (class or property), an explicit link rdfs:isDefinedBy to the vocabulary it belongs to is added. a new vocabulary in order to include it in the LOV catalogue. After validating a vocabulary URI, the user correct the vocabulary before submitting it. Some recommendations for vocabulary metadata description may be of help.

In the current version of the Datalift platform LOV, is provided as a standalone tool. We are currently working on making it more tightly integrated so that users can select the terms relevant to describe their datasets directly form the LOV interface.

Data convertion modules. The platform actually provides two modules for converting CSV and relational databases to RDF; A third module allows to convert raw RDF to well formed RDF usng SPARQL Construct queries. The XML conversion module is currently being integrated into the platform.

Security module. The proposed Access Control Manager [START_REF] Costabello | Linked data access goes mobile: Context-aware authorization for graph stores[END_REF]) is designed as a pluggable component for SPARQL endpoints. The Datalift version has been implemented as a module of the Datalift platform13 , using the Sesame14 RDF store. Each client query over the protected datastore is associated to the RDF graph modeling the client mobile context. The mobile context is sent by the requester to the data server at (Step 1). The module saves current mobile context in a local cache (Step 2). The selection of the Access Policies returns the set of Access Policies concerned by the query (Step 3). We select all the Access Policies which have the identified Access Privilege. The Access Control Manager appends a BINDINGS clause to the Access Conditions included in the selected policies. This is done to bind the ?context variable to consumer's actual context. Access Conditions are executed on the protected datastore. The resources protected by verified Access Policies are added to the set of accessible named graphs, conjunctively or disjunctively (Step 3). Finally (Step 4), the "secured" client query is sent to the SPARQL endpoint with the addition of the FROM clause. Query execution is therefore performed only on the accessible named graphs, according to the contextual information of the requester.

Interlinking module. The interlinking module provides means to link datasets published through the Datalift platform with other data sets available on the Web of Data. Technically the module helps to find equivalence links in the form of "owl:sameAs" relations. The technical details of the module are as follows.

1. an analysis of the vocabulary terms used by the published data set and a potential data set to be interlinked is performed. 2. when the vocabulary terms are different, check if alignments between the terms used by the two data sets are available. We use the alignment server provided with the Alignment API15 for that purpose. 3. translate correspondences found into SPARQL graph patterns and transformation functions combined into a SILK script. 4. run SILK [START_REF] Bizer | Silk -a link discovery framework for the web of data[END_REF]) to interlink datasets.

Until now, SILK is successfully embedded in the Datalift platform. An interface is built for the user to upload the SILK script and other parameters for running the script. Later versions of the module module will provide an interface to assist the user in finding candidates datasets for interlinking. Another interface is designed to display and validate the resulting links.

Conclusion

We have presented the Datalift project aiming at providing a framework and an integrated platform for publishing datasets on the web of Linked Data. We have described the framework, the platform architecture, and the modules actually available, providing a complete path from raw structured data to Linked Data.

While the datalift platform is used today with data publishers associated with the project, it remains an expert tool. Users of the platform needs significant knowledge of the Semantic Web formalisms (RDF, RDFS/OWL, SPARQL) in order to perform the lifting process. We are actually working on making the platform easier to use by • providing graphical user interfaces for the lifting process;

• providing more automation to vocabulary selection, and mapping of vocabulary terms to the source data schema; • automating the interconnection step by generating Silk scripts automatically; • offering templates for the URI design ;

We are finally working on developing end-user applications that make use of the lifting process performed by the platform and show the added value of combining datasets to reveal new insights on the data. In particular we are working with with local and national government agencies to show how the publication and interlinking of datasets enable the development of innovative application for citizens.

Aknowledgements

The Datalift project is funded by the French National Research Agency under grant ANR-10-CORD-009

  LOV Stats are computed on all LOV vocabularies aggregated in LOV Aggregator. It provides some metrics about vocabulary elements. "LOV Distribution" metric is about the number of vocabularies in LOV that refers to a particular element. "LOV popularity" is about the number of other vocabulary elements that refers to a particular one. "LOD popularity" is about the number of vocabulary elements occurring in the LOD.• The "LOV Suggest" feature gives the possibility to submit

	• The "LOV Search" feature gives you the possibility to
	search for an existing element (property, class or vocabu-
	lary) in the Linked Open Vocabularies Catalogue. Results
	ranking is based on several metrics: element labels rele-
	vancy to the query string, element labels matched impor-
	tance, number of element occurrences in the LOV dataset,
	number of Vocabulary in the LOV dataset that refer to the
	element, number of element occurrences in the LOD
	•

http://labs.mondeca.com/dataset/lov

http://www.w3.org/2011/gld/

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

http://www.w3.org/2001/sw/rdb2rdf/

http://ns.inria.fr/s4ac

http://ns.inria.fr/prissma

http://www.w3.org/TR/sparql11-update

http://vocab.deri.ie/void

http://sw.deri.org/2007/07/sitemapextension/

http://thedatahub.org/

http://labs.mondeca.com/vocab/voaf/

A demo of the module may be found at http://dl.dropbox.com/u/15116330/s4acTest.mov

http://www.openrdf.org/

http://alignapi.gforge.inria.fr/