Interacting with the Web of Data through a Web of Inter-connected Lenses ∗ Igor Popov m.c. schraefel Gianluca Correndo School of Electronics and School of Electronics and School of Electronics and Computer Science Computer Science Computer Science University of Southampton University of Southampton University of Southampton SO17 1BJ, Southampton, UK SO17 1BJ, Southampton, UK SO17 1BJ, Southampton, UK ip2g09@ecs.soton.ac.uk mc@ecs.soton.ac.uk gc3@ecs.soton.ac.uk Wendy Hall Nigel Shadbolt School of Electronics and School of Electronics and Computer Science Computer Science University of Southampton University of Southampton SO17 1BJ, Southampton, UK SO17 1BJ, Southampton, UK wh@ecs.soton.ac.uk nrs@ecs.soton.ac.uk ABSTRACT Design, Human Factors. As a medium of structured information available on the Web, Linked Data is still hard to access for most end users. Keywords Current solutions facilitating end user access to Linked Data End-user Interaction, Linked Data, User Interface are either thought the use of data-mapping approaches, which allow configureable interfaces to be quickly deployed over pre-selected aggregations of Linked Data, or enable users 1. INTRODUCTION themselves to browse the Web of Data through the use of End users engage in data-centric activities on the Web on generic data browsers. While the first approach is useful and a daily basis. Every time we view our news feeds on a so- promotes surfacing and easy repurposing of structured data cial networking site or browse shopping items on a online it does little to promote the use of linkages to other, remote commerce site, we are offered tools to browse, filter and find datasets. The second approach is much less useable for end the data we need. Much of these data-centric interactions users, however enables them to experience browsing a inter- and tools, however, are limiting in one fundamental way - connected Web of Data. In this paper we present mash- they confine us to browse and explore the only the data for point, a framework that aims to provide a middle ground which the tool was designed, denying the opportunity to re- between both approaches. The approach treats data-centric focus and find associated data on other web sites offering applications as high-level lenses over the data, and allows related data. One of the advocated advantages of linking selections of data to be pivoted between applications thus data is that links that exist between remote datasets can be facilitating navigation. The paper presents an initial proto- leveraged to effortlessly integrate and navigate to associated type and discusses both implications and challenges in terms data in remote datasets. Despite this vision, we yet to expe- of interaction and technology. rience interfaces where simple interactions allow end users to and navigate and find related data outside the current Categories and Subject Descriptors dataset, in essence denying them to truly experience a Web H5.2 [Information Interfaces and Presentation]: User of Data. Interfaces—Graphical user interfaces (GUI); H5.4 [Information Interfaces and Presentation]: Hypertext/Hypermedia— Currently, three approaches are adopted to surface and allow User issues casual end users to interact with and explore Linked Data. The first approach is the obvious one - creating a tailored interface over pre-selected portions of Linked Data. The sec- General Terms ond approach is a generalisation of the first - through the use ∗Corresponding author. of data-mapping tools that allow developers to easily set up and configure visually rich exploration interfaces over Linked Data without too much programming. For example, Exhibit [7] enables developers to create a powerful data exploration interface without any knowledge of database technology or programming, while mSpace [14] allows installation and con- figuration of a scalable faceted browser over a SPARQL end- point though an installation wizard. While both of the afore mentioned approaches promote the use and repurposing of Copyright is held by the author/owner(s). structured data, they rarely promote to users the linkages LDOW2012, April 16, 2012, Lyon, France. that exist to various other datasets on the Web of Data. In effect, once deployed they create their own data silo - use- ful for exploring the data over which the interface acts as a Countries Currency lens, but unable to relate to data in other, remote datasets. The third approach lets users explore and aggregate arbi- USA USD trary data through the use of generic data browsers, which Ecuador offer browsing the Web of Data as a analogy of browsing the Web of Documents. For example, the Tabulator [3] allows UK users to browse graphs of RDF1 , specify arbitrary selections GBP of the data and analyse the selected data through inputing Germany them in a variety of widgets such as charts, maps and time- lines. Generic data browsers consume and present the data Austria Euro on demand and do not require any configuration. However, since RDF does not prescribe any representational informa- France tion, generic data browsers often resort to generic represen- tations - a one size fits all interface for data. Additionally the interaction and navigation in a generic browser is closely Current view Refocused view associated with the underlying RDF model, which often is too fine grained for the casual user and requires transfor- Set-oreiented operation mations or finding suitable representations before it can be used to solve a particular information need. For such rea- Figure 1: Abstract representation of a set-oriented sons, generic data browsers are often too complex for casual operation. Web users - users that are used to visually rich and custom made interfaces. /facet [5] already provide ways to quickly deploy interfaces A trade off of is evident when accessing Linked Data us- over structured data. Most of these tools, however, offer ing data-mapping approaches on the one hand and generic deploying data exploration interfaces over relatively simple tools on the other. I the first case we sacrifice navigability collections of data; for example a collection of set of re- through Linked Data as a unified, inter-connected resource sources (e.g. a collection of countries) and several facets and be satisfied with islands of applications over limited data for which can be visualised and used for filtering. Naviga- sources unable to interact with each other. If we use more tion and exploration of data from complex graphs, however, generic solutions, however, we risk poor usability and expe- requires more advance interactions. Browsers such as Par- rience will thwart large numbers of users from experiencing allax [6], Humboldt [9], Explorator [1] and gFacet [4] intro- and gathering information from a integrated Web of Data. duce the notion of pivoting and set-oriented browsing. Set- In this paper we present our approach to reconcile these vi- oriented browsing is a natural generalisation of the Web’s sions by offering a middle ground between both approaches. one-to-one browsing paradigm to a many-to-many brows- We propose a framework that allows data-centric interfaces ing method since manipulating data often requires dealing to be linked based on equivalent identifiers in their respec- with multiple items simultaneously and common semanti- tive data sources, enable them to express their state based cally typed links offer a consistent way of refocusing with on these identifiers, and allow these identifiers to be passed multiple items. Figure 1 displays in abstract the concept of as input from one application to another as a way of enabling set-oriented browsing. The majority of set-oriented browsers navigation. In effect, our framework views applications as offer a user interface to explore and query graph data; addi- a higher level lenses or views over graphs of data on the tionally browsers such as Parallax and Tabulator allow users Web. The framework potentially unlocks novel interaction to select data from the explored graph and visualise the re- possibilities and allows for citizen end users to experience an sults as maps, charts, timelines and calendar views. unbounded Web of Data. This paper is structured as follows. In the following section 2.1 Issues with Existing Approaches we briefly discuss related work and discuss challenges facing As we noted in the introduction, data-mapping approaches existing approaches. In Section 3 we present mashpoint 2 , a offer useful and usable interfaces for interacting with data framework for using data-centric applications as lenses over but limit the interaction to the data for which the interfaces the Web; we discuss how users interact with multiple appli- are intended for; generic data browsers on the other hand, cations to explore and solve data-intensive needs. In Section which are capable of browsing and exploring arbitrary data 4, we discuss implementation details. Section 5, discusses from graphs, have not as yet been widely adopted. In the the implications both from an interaction perspective and following we offer several reasons for their low adoption. socio-technical perspective. Finally we conclude in Section 6 and discuss future work. Dealing with Fine-grained Data. Often times the data 2. RELATED WORK that the data browser exposes is much too granular for end As discussed in the introduction of this paper, a number users, often requiring them to do complex transformations of tools, such as Exhibit and Dido [7, 8], mSpace [13], and or many selections before they can complete a information related task. For example, a simple question of viewing a 1 http://www.w3.org/RDF/ visualisation of countries GDP/per capita on a map will re- 2 http://www.mashpoint.net/ quire multiple steps to complete. Normally, a user would have first to explore the graph and find resources of ”Coun- 3. MASHPOINT: USING tries” that will probably be associated with properties such INTER-CONNECTED DATA-CENTRIC as latitude, longitude, GDP and population. Then, a user would have to find and specify which properties will be used APPLICATIONS AS LENSES to query. Moreover, GDP per capita might not be avail- In this Section we describe mashpoint 4 our prototype frame- able, so a user would have to combine the overall GDP and work for using and navigating through higher level abstrac- population data before the data can be used in, for exam- tions or lenses over data. The basic premise of the mashpoint ple, a chart visualisation widget. Eventually, the user can framework is that when data is viewed or interacted with by reach the desired result, however the process can be long end users, it should always be represented within a certain and error prone. For the majority of end users, these inter- context. Data-centric applications are perfect examples of actions are often too complex and time consuming. More- data viewed in context and therefore considered as lens over over, browsers rarely capture this transformation from data some data in the mashpoint framework. A data-centric ap- to usable knowledge done by users and miss the opportunity plication is any application that is powered by and offers of offering previous results as a suggested lens to new users some interaction over some data. For example an Exhibit in the browser3 . is a typical data-centric application. With mashpoint our goal is to enable users to select specific data through the interactions offered in one application and pivot (i.e. exe- Information Overload. Even with a good exploration tool cute a set-oriented operation with that selection) to another that abstracts machine-readable data and allows users to application that can accept that data as input and provide perform various queries, graphs of data can still be diffi- new information corresponding to the selection done in the cult to explore. They can hold enormous amounts of data, previous application. In such a way we achieve set-oriented thus frequently requiring users to find and filter to a small navigation through graph data. Figure 2 depicts this in- teraction technique between two mashpoint enabled appli- portion of the dataset. Additionally, when engaged in an exploratory search - search where users have no concrete in- cations. In the example, the first application5 (Figure 2a) formation goal but rather engage in exploration - they can shows a simple data-centric application which allows users find it difficult to figure out which properties would make to explore data about countries GDP/per capita and pop- sense to combine, visualise, or which properties would make ulation information by allowing the data to be filtered by good facets for filtering. The authors of BrowseRDF [10] ”Income level” or ”Region”. For example, selecting ”Low were the first to take note of this issue by trying out an au- income” from in the first application will filter and show tomatic way of detecting useful facets. They acknowledge, low income countries to users. A user can then click on however, that automatic approaches are limited and that the mashpoint button (Figure 2b), which pops up a window and offers other applications that can take and offer new additional knowledge about the ontology is required. While in the future data-centric browsers could analyse graphs of insights regarding the selected data in the first application. data and offer recommended views based on established on- For example, a user may want to view CIA factbook data tologies we believe that such capabilities are not feasible in about the ”Low income” countries and choses to open that the foreseeable future. application6 (Figure 2c). The CIA factbook application has various data about countries. For example, the user can view information about countries birth-rate vs. death-rate and filter the existing selection on different facets. Note that Representation. Unlike the Web, where each page is care- the items that are shown in the new application reflect the fully crafted for human consumption, a Web of RDF data is items chosen in the previous application. purposely devoid of any presentational content as a adher- ence to the principle of separation of content from presenta- As part of the development of this framework, we started tion. Therefore responsibility is transferred to the browser to adapting and linking existing data-centric applications on figure out how to represent data when the data is fetched. the Web. Figure 3, shows three other applications that we Generic browsers currently only base their representations adapted and linked up using our framework. The first one7 and browsing models on the triple data model of RDF, and (Figure 3a) is a simple Exhibit showing images of world cur- this is often reflected in browsers by employing generic rep- rencies, and the currency code. The second application8 resentations, using simple heuristics to display data (e.g. (Figure 3b) is a simple exploration application which allows searching for rdfs:label to display a resource), or provid- users to view and browse countries flags depicted on a map. ing navigation using the links only between neighbouring The third application9 (Figure 3c) is an existing application resources (those who share a link) in the graph. Additional we found on the Web10 that we integrated into our frame- representational knowledge such as lenses [11] can improve work. data representation, however crafting lenses without any knowledge of the context in which they will be used in the In the following we describe several examples how combin- generic browser is a challenge. Moreover, it is unclear who ing and navigating with different selections in the data can should bear the effort of providing lenses for generic browsers - the publisher of the data or the browser consuming the 4 http://www.mashpoint.net data, and what is the immediate benefit of providing repre- 5 http://mashpoint.net/demoapps/countriesincome/index.html sentations of the data as lenses as opposed to just building 6 http://mashpoint.net/demoapps/birthratevsdeathrate/index.html a custom made web site to display a publishers data. 7 http://mashpoint.net/demoapps/currencycodes/index.html 8 http://mashpoint.net/demoapps/flagsonamap/index.html 3 9 Parallax [6] allows users to export live views of the data http://mashpoint.net/demoapps/mapmigrations/index.html 10 and embed them in blogs and web pages. http://migrationsmap.net/ a Select or Filter items Countries income per capita Countries birth rate vs. death rate c Pivot with selected items on selected application b Choose from applications that can take selected items as input Figure 2: A pivoting operations between two applications in mashpoint. produce some interesting insights into the data: South-east Asia. • Continuing from the previous example, once viewed ge- • In the previous example we used an application that ographically, a user can chose to view additional data showed World Bank data about GDP/per capita (Fig- about the selected ”Low income” countries by pivoting ure 2a). A user can browse the data in that application to the CIA Factbook application (Figure 3b) and ex- using the facets that are provided, however, the appli- plore data about birth rates and death rates for the cation provides only a single representation of the data. selected, low income countries. The user decides to A user may wish to view countries on a map in order compare these with high income countries so he/she to see how countries of different income groups are repeats the same navigation, only this time starting distributed geographically (for example, which conti- with a high income countries in the first application. nents contain ”Low income” countries?). Using current The user can then conclude that there is great diver- tools on the Web, a user would be required to copy and sity in both birth rates and death rates in low income paste each country in another application (e.g. Google countries as opposed to high income countries where Maps) to answer this question. Using mashpoint, how- death rates are fairly consistent, and birth-rates expe- ever, the user can take any selection of the data and rience small variations. find applications that are able to provide geographic information and representations about the data. For • Similarly to the previous example, a user might chose example, after filtering to ”Low income” countries the to view migration patterns and instead of grouping user can open the mashpoint dialog and select the countries by income levels he/she might be interested Flags on a map application (Figure 3a), which can dis- in a particular geographic region. For example, piv- play the current selection of countries on a map as little oting from Middle-eastern countries in (Figure 2a) to flag markers on a map. Immediately it is revealed that the Map Migrations app (Figure 3c) can reveal to the out of the all the low income countries only a single one user that people from those countries typically migrate (Haiti) is in the Americas, while the rest of the low in- to countries in the same region and to countries of the come countries are in sub-saharan Africa, Central and Western Europe and Northern America. a Currency codes b Flags on a map c Migrations map Figure 3: Example applications linked with the mashpoint framework. • A user is planing a trip across Europe, traveling to mul- 4. IMPLEMENTATION tiple European countries. The user is aware that some This Section describes the implementation details of mash- European countries share a single currency however point. Our investigation into designing mashpoint began needs information about each of the countries he/she with the simple interaction challenge by asking ”Why are is traveling to. Deciding that the best way to quickly generic data browsers unusable?” and ”How do we solve select the countries of interest is to use a map, the these problems, and where can we gain in usability with- user selects the countries of interest on the Flags on out sacrificing browsing and navigating capability?”. While a map application (Figure 3a). By selecting the Cur- the implementation of mashpoint were guided by these prin- rency codes application (Figure 3b) the user is able to ciples, we tried to implement mashpoint so that the barrier pivot with the current selection of countries, obtain- for entry for linking application to the framework would be ing the corresponding currencies of each country. This minimal. saves the user time since the alternative would be to look up each country and integrate the information The implementation consists of three parts: (1) the appli- manually. cations themselves, which need to be data-centric in nature and be built with certain requirements, (2) a discovery ser- If we examine carefully the above examples, an interesting vice that allows applications to look up other applications observation can be made from each example. Each applica- so that the user can pivot between them and (3) a means tion by itself offers very limited capabilities to interact over of communication between the applications and discovery that data. By enabling selections of data to be pivoted or service. In the following we discuss each part in detail. shifted to other applications, we not only aid in the discov- ery of new information, which is one of the advocated uses 4.1 Applications of Linked Data, but additionally allow users to interact with In order to enable pivoting between applications, they need the newly found information in a way that is tailored for the to be designed according to some specifications and rules. specific data to be displayed. Our choice of specifications was motivated by a desire to make the integration of new and existing data-centric ap- a plications as painless as possible i.e. not to impose any un- necessary learning curves or restrict developers to use any http://application.com/#?mashpoint=uri1 particular technology. Thus to link an application to mash- point, it needs to have the following properties: b http://application.com/#?mashpoint=uri1,uri2 • Offer Data-centric features. Each application in mashpoint needs allow interaction over data with iden- tifiable resources. An application can hold multiple c collections of identifiable resources - for example be http://application.com/#?mashpoint=uri1,uri2|uri3 about People, Countries, Events etc. An Exhibit like the one in Figure 2c is a typical example of a data pow- ered application that offers browsing over data about countries. In the data of this particular Exhibit, each country is an identifiable real-world object. Figure 4: Preserving the state in a mashpoint-linked application. • Use of URIs. While the data underlying the appli- cation does not necessarily need to be in RDF, an URI instantiation of mashpoint we rely on Freebase11 as a ser- needs to be present for each identifiable resource of the vice to which data used in applications need to be recon- data. In our examples, since the data is about coun- ciled. Note that we have chosen Freebase for convenience tries, each Country needs to be be associated with an reasons - Freebase and the support offered in Google Refine URI. The use of URIs is also needed in order to be offers tools to quickly reconcile12 arbitrary data with Free- able to save the state of the application. We discuss base concepts. While the data in the applications need to how to preserve the applications state in the next two be reconciled against Freebase, it does not preclude using points. other data sources that already use established URIs. For example applications consuming Open Linked Data can use • Be able to select multiple resources. An applica- resources such as sameas.org13 to either reconcile their data tion in this framework should typically enable selection to Freebase or even use the service in real time (although of resources in order to be able to pivot with arbitrary the former is probably the preferred solution because of op- selections of data. Selections of the data can can be timisation issues). In essence, it does not particularly mat- provided in multiple ways. For example, items can be ter which URIs we offer as reconciliation, since the frame- selected thought filtering by providing various facets work requires just reconciliation of identifiers. Moreover, over the data and/or allow arbitrary items to be se- the architecture could also be redesigned in a different way lected. This selection of items will then be passed on - it could allow applications to use whatever URIs they see as input to another application. Whenever an appli- fit and try to reconcile them and do discovery in real time cation changes its focus, the state of the application through the use services such as sameAs.org. To illustrate should be made explicit in the URL of the application. this we have already connected Visor14 [12] a end-user tool In mashpoint we require each application to list the for exploring DBPedia [2] data to the mashpoint framework. current resources in view through a mashpoint param- At this point of time, however, a priori reconciliation pro- eter in the URL. Figure 4 depicts the saving of state vides a more optimised solution to the co-reference problem in each application. Figure 4a for example depicts an in our case. application showing a single resource and a mashpoint that denotes this state. Similarly, Figure 4b shows the interface on a state with two resources. The state can 4.2 Discovery Service also group a list of resources (Figure 4c) in order to In order to be able to find applications which can be used to reflect certain collections of resources e.g. a interface pivot from the current application we implemented a discov- that displays data about both ”Countries” and ”Cur- ery service for mashpoint-enabled applications. The discov- rencies”. ery service is a repository that simply keeps a record about which URI identifiers can be represented in which applica- • Be able to represent multiple resources on in- tions. Applications therefore need to register themselves in put. Application should be able to take any arbi- the discovery service and ”subscribe” their URI identifiers. trary selection of URL identifiers that represent the Registering with a set of URIs means that an application resources of the application and be able to show some can represent and show data about any subset of the iden- representation of that data that reflects the selected tifiers it is subscribed to. Once registered, each application items i.e. be able to arbitrarily retrieve any state of can communicate with the discovery service to find other the application. applications that can take the current selection (represented through the URIs in its state) as input. Figure 5 depicts 11 http://www.freebase.com The choice of URIs is also an important factor in the cur- 12 http://code.google.com/p/google- rent implementation of the framework. In order to enable refine/wiki/ReconciliationServiceApi 13 pivoting between applications we need identical identifiers http://sameas.org/ 14 across all mashpoint enabled applications. In our current http://visor.psi.enakting.org/ this architecture. For clarity, URI identifiers are represented an application may want to offer users pivoting to only a with dots, squares and triangles to denote different groups of certain, predefined set of applications. Therefore the pub- URIs found across different applications. For example Ap- lisher of the application can discover those applications once, plication 1 is registered with the dot identifiers which means and include them as regular links in the application. This it can take any subset of these identifiers as input. Applica- removes the need for a third party discovery service, how- tion 2 can either take the any subset of dot identifiers but it ever it is now up to the publisher to keep the links to the can also take any subset of square identifiers as input. Sim- other applications consistent with the current state of the ilarly Application 3 can take subsets of square and triangle application. identifiers. These groups of URI identifiers are assigned by the application registering to the discovery service. 5. DISCUSSION In this Section we discuss open issues, challenges and impli- cations in adopting mashpoint as a framework. Discovery service 5.1 Interaction Challenges A number of interaction challenges need to be investigated App 2 and addressed in order to mitigate any usability issues. First, App 1 unlike a generic browser where data is viewed, browsed and manipulated within the context of a single application, mash- App 3 point proposes an approach to data browsing where views of 1 the data are provided by distributed applications that can be Send URIs in contributed by many publishers. Evaluating how well users Recieve apps that can combine and pivot data between different applications current view 2 can represent URIs in order to solve data-centric tasks remains to be explored and evaluated. Another issue is the implementation of the set-oriented op- erations in mashpoint. In the current implementation, when the discovery service is queried with a set of URIs, every ap- plication that can represent some subset of these URIs is retrieved. For example, if an applications state is currently App 1 App 2 App 3 focused on three countries e.g. France, Germany, and Brazil, and another application can show data only about European countries, that application will also be retrieved when ap- plications will be requested for those three countries, even though it will only be able to show information on two out of the three countries. This means that in some cases not 3 Pivot to other apps all URIs will be able to be represented in the application to which the user will pivot. Such information needs to be sur- faced to the user, or ideally, enable users to filter and browse Figure 5: Architecture of the mashpoint framework. particular types of applications according to the content or size of the subset they can take as input. 4.3 Pivoting Across Applications In order to enable pivoting across applications, they need to Another problem that might hinder usability is the lack communicate and request information based on the current of context between pivoting steps in applications. Some- state of the application. Each application therefore commu- times the data in two linked applications will follow a one- nicates its state to the discovery service i.e. it sends the to-one mapping e.g. two applications both showing data URIs that currently represent the data which is viewed in about countries. This corresponds as navigation through the application, and retrieves back a list of applications that resources that are linked through a owl:sameas relation. As are able to receive those URIs as input. we’ve seen in our examples, however, pivoting can take place between applications that contain data on diverse topics, In order to facilitate this communication, each application for example pivoting from an application about ”Countries” in mashpoint incorporates a small JavaScript widget that to an application about ”Currencies”. This corresponds to is able to parse the URL for the URI identifiers and send navigating through resources with arbitrary links between them to the mashpoint discovery service (Figure 5-1) The them and often times the relationships between them will discovery service then retrieves which applications can take be many-to-many. In our example, the application show- the URIs as input and sends them as a response with their ing currency data might not explicitly state which countries states reflecting the identifiers in the request (Figure 5-2). are using that currency. Thus a user would find it difficult The widget in each application is a third party code that figuring out which country shown in the first application adds a mashpoint button, facilities the communication with corresponds to which currency in the second one. Several the discovery service and pops up the dialog that suggests solutions to this problem are possible. First, either publish- appropriate applications to users. We note that the discov- ing practices will compound users to normally include labels ery mechanism and widget may be omitted from an appli- or representations of the items of input, or second, the state cation. For example, cases may exist where a publisher of of an application encoded in the URL can include additional contextual information that will be sent alongside the URIs. is useful by itself. As a publishing recommendation mash- At present, however, this remains future work. point acts in a very similar way. Applications can be viewed as contributions which are useful by themselves - they allow some value over the data they were initially designed for. By 5.2 Social Contribution Factor linking them up, and enabling pivoting to other data-centric applications, the original application can only increase the value of the original application. In fact, this attribute may provide incentive for publishers of data-centric applications on the Web to link their data using frameworks such as mashpoint. Application 2 5.3 Low Barrier for Entry Although none of the applications we have presented in this Application 3 paper directly operates over live Linked Data, or directly use RDF data directly (although we extracted some of the Area size data from Linked Data sources), we believe this fact to be Image_file an added strength to the framework, since it only lowers the barrier for linking new applications - it does not mandate or Population impose any particular data model on the user. This is not areaSize Currency image to say that the applications using this framework cannot code GDP use standard data-models such as RDF. In fact, as the title popSize currency code our our paper suggests, we view the applications as high- hasGDP level lenses over graphs of data, as depicted in Figure 6. Currency Countries In Figure 6 we can see the connections between the data hasCurrency items used by the mashpoint-enabled applications earlier. birthRate The applications encapsulate views over the data, and the deathRate Birth Rate relationships between the data are just hidden within the individual applications. Thus applications are can chose to use either RDF or any other data model and pivoting takes Death place where these lenses overlap. Rate Application 1 5.4 Incentives for Publishing and Linking During the last 2 years, the Linked Data community has been advocating data publishing using Linked Data stan- dards, and has promoted the use of these standards as a quality indicator for data available on the Web15 . However, the benefits of publishing Linked Data and linking to other remote data sources remain elusive for most data publishers and consumers outside the community. Often the results are data repositories that are rarely used and provide sparse Figure 6: Model of data and it’s relationships en- linkages to other remote datasets. This lack of immediate capsualted . value for the effort of converting ones data as Linked Data can thwart many potential adopters of these technologies. With mashpoint we hope to target this problem, particularly By design, mashpoint sets forward a paradigm that has in- in providing incentives for linking data. As we already men- herently a social factor of contribution, which is similar to tioned, publishers of data-centric applications would only the social nature of publishing and linking in the original increase the value of their applications by allowing users to Web. The reason why applying data mapping tools such as find useful, related data without changing the original ap- Exhibit [7] have seen much wider acceptance than generic plication. By requiring publishers to reconcile their data browsers such as Tabulator [3] is because a publisher of an we already promote the use of URIs in their datasets, while Exhibit [7] can control the look and feel of the data and im- showing the immediate benefit of being able to pivot and mediately see value of providing a rich data-centric interface suggest related data to the users of the application. over data. The original Web followed a similar pattern; a published Web site offered a custom made document and a presence on the Web - linking to other web sites only im- 6. CONCLUSION proved the quality of the web site by providing connivence of In this paper we presented mashpoint, a framework which finding relating information. For example a web page about aims to promote the value of a Web of Linked Data by en- events in Southampton is by itself a useful contribution to abling interactions that take advantage of links between re- the Web, and the publisher can increase the value of informa- mote datasets while remaining usable and familiar as brows- tion by providing links to other pages (e.g. the Wikipedia ing the Web itself. As a publishing framework, we view page for Southampton or other related web pages offering mashpoint as an extension to the current landscape of tools events information about Southampton). However it is im- 15 http://inkdroid.org/journal/2010/06/04/the-5-stars-of- portant to note that even without the links, the web site open-linked-data/ providing end user access access to the Web of Data (Figure 2010), volume 6088 of LNCS, pages 288–302, 7). While we’ve communicated the overall idea of having Berlin/Heidelberg, 2010. Springer. data-centric applications serve as lenses over Linked Data, [5] M. Hildebrand, J. van Ossenbruggen, and the work presented here is still work in progress and many L. Hardman. /facet: A browser for heterogeneous open challenges remain. Our future work include evaluating semantic web repositories. In International Semantic the initial prototype with users allowing them to complete Web Conference, pages 272–285, 2006. data-intensive task by navigating thorough a Web of tens [6] D. Huynh and D. Karger. Parallax and Companion: of mashpoint-linked applications. We believe that the study Set-based Browsing for the Data Web. 2009. will provide many insights into the overall design and im- [7] D. F. Huynh, D. R. Karger, and R. C. Miller. Exhibit: plementation of the framework. If mashpoint achieves wide lightweight structured data publishing. In WWW ’07: adoption, our long term plan will be to study the ecology of Proceedings of the 16th international conference on inter-linked applications it will create. World Wide Web, pages 737–746, New York, NY, USA, 2007. ACM. Configureable Simple, [8] D. R. Karger, S. Ostler, and R. Lee. The web page as Data Exploration Tools a wysiwyg end-user customizable database-backed (Exhibit, mSpace, \facet etc.) information management application. In UIST ’09, Usability mashpoint pages 257–260, New York, NY, USA, 2009. ACM. [9] G. Kobilarov and I. Dickinson. Humboldt: Exploring Custom linked data. In Linked Data on the Web (LDOW2008), Configureable Graph made apps Exploration Tools 2008. (Visor, Parallax etc.) [10] E. Oren, R. Delbru, and S. Decker. Extending faceted navigation for rdf data. In ISWC, pages 559–572, 2006. Generic Data Data-mapping approaches [11] E. Pietriga, C. Bizer, D. Karger, and R. Lee. Fresnel - Browsers a browser-independent presentation vocabulary for rdf. In In: Proceedings of the Second International Ease of access Workshop on Interaction Design and the Semantic Web, pages 158–171. Springer, 2006. [12] I. O. Popov, M. C. Schraefel, W. Hall, and Figure 7: Landscape of data-centric tools and appli- N. Shadbolt. Connecting the dots: a multi-pivot cations. The Figure shows the tools usability agains approach to data exploration. In Proceedings of the the ease of access to the Web of Data. Ease of ac- 10th international conference on The semantic web - cess relates to how scalable is a tool with respect to Volume Part I, ISWC’11, pages 553–568, Berlin, accessing diverse datasets from the Web of Data. Heidelberg, 2011. Springer-Verlag. [13] m. c. schraefel, D. A. Smith, A. Owens, A. Russell, 7. ACKNOWLEDGMENTS C. Harris, and M. Wilson. The evolving mspace This work was supported by the EnAKTing project, funded platform: leveraging the semantic web on the trail of by EPSRC project number EI/G008493/1. Many thanks the memex. In HYPERTEXT ’05: Proceedings of the to Manuel Salvadores for providing useful feedback for this sixteenth ACM conference on Hypertext and work. hypermedia, pages 174–183, New York, NY, USA, 2005. ACM. 8. REFERENCES [14] D. A. Smith, I. Popov, and mc schraefel. Data picking [1] S. Araujo, D. Schwabe, and S. Barbosa. linked data: Enabling users to create faceted browsers. Experimenting with explorator: a direct manipulation In Web Science Conference 2010, March 2010. generic rdf browser and querying tool. In Workshop on Visual Interfaces to the Social and the Semantic Web (VISSW2009), February 2009. [2] S. Auer, C. Bizer, G. Kobilarov, J. Lehmann, R. Cyganiak, and Z. Ives. Dbpedia: a nucleus for a web of open data. In Proceedings of the 6th international The semantic web and 2nd Asian conference on Asian semantic web conference, ISWC’07/ASWC’07, pages 722–735, Berlin, Heidelberg, 2007. Springer-Verlag. [3] T. Berners-lee, Y. Chen, L. Chilton, D. Connolly, R. Dhanaraj, J. Hollenbach, A. Lerer, and D. Sheets. Tabulator: Exploring and analyzing linked data on the semantic web. In In Procedings of the 3rd International Semantic Web User Interaction Workshop (SWUI06, page 06, 2006. [4] P. Heim, T. Ertl, and J. Ziegler. Facet graphs: Complex semantic querying made easy. In Proceedings of the 7th Extended Semantic Web Conference (ESWC