SWOWS and Dynamic Queries to build Browsing Applications on Linked Data

Paolo BottoniSapienza, University of Rome

Department of Computer Sciencebottoni@di.uniroma1.it

Miguel CerianiSapienza, University of Rome

Department of Computer Scienceceriani@di.uniroma1.it

Abstract

The Linked Data Initiative is pushing dataset maintain-ers to publish data online in a highly reusable way througha set of open standards, such as RDF and SPARQL. Theamount and variety of available structured data in theWeb is increasing but its consumption is still quite limited.In particular applications used to explore linked data aremostly either generic linked data browsers or applicationswith hard-coded logic tailored for specific needs. SWOWSis a platform for declarative specification of applicationsconsuming linked data. In this paper we describe the use ofthe platform for creating browsing applications tailored tospecific contexts, and show how the declarative paradigmpreserves flexibility of the application. To this end, the plat-form has been extended to allow the dynamic generationof SPARQL queries. An example of a linked data browsercreated with the platform is given.

1. Introduction

In recent years the Web is evolving from an interlinkedset of documents to an interlinked web of data and services.The structured data available online is increasing both inquantity and diversity [7]. The comprehensive data modelproposed by the World Wide Consortium (W3C) is the Re-source Description Framework (RDF) [14]. Other de factostandards, e.g. the Freebase model [8], or HTML embed-ded formats, such as Microformats [25], Microdata [22]or RDFa [1], can be mapped to the Resource DescriptionFramework (RDF) model [14] for interoperability (for ex-ample using Any23 1).

One of the key advantages of the linked data model isthat it allows the serendipitous exploration and reuse of ex-isting data. Potentially, any expert of a specific domain canbuild a fully customized visualization from a set of possiblydifferent linked data sources.

1http://any23.apache.org/

In practice, building such a visualization currently re-quires advanced programming skills. Moreover it involvesa number of system choices that constrain the effectivereuse of a visualization. To mitigate this problem, wehave developed the Semantic Web Open datatafloW Sys-tem (SWOWS) [11, 10], a platform that allows the declar-ative construction of interactive linked data applications.Applications are built from a basic set of operators (basedon SPARQL, the standard query language over the RDFmodel [21]) adopting the pipeline metaphor.

In this paper we discuss the use of SWOWS to build ap-plications to browse specific sets of linked data. We showhow such applications can be built based purely on Web andSemantic Web standard technologies and how the declara-tive approach can help in organizing flexible visualizations.

The SWOWS platform has been extended to allow ma-nipulation of SPARQL queries as data. A developer usingSWOWS can thus write SPARQL queries which take asinput other SPARQL queries and/or produce new queriesin output. The queries written with SWOWS have therole higher functions have in other programming languages(Scala [30] being possibly the most popular nowadays). Theuse of this functionality (together with other extensions tothe original SWOWS platform) will be showcased throughan example application.

In the rest of the paper, Sect. 2 introduces the technol-ogy background and Sect. 3 discusses related work, whileSect. 4 specifically describes SWOWS. New features areshown in Sections. 5 and 6, where dynamic query gener-ation is illustrated.An example application is described inSect. 7 and Sect. 8 discusses conclusions and future work.

2. Technologic Background

The relational model is widely used to represent virtuallyany kind of structured information. The Resource Descrip-tion Framework (RDF) [14] generalises it to the universeof structured data in the World Wide Web, better known asthe Semantic Web [5]. In the RDF data model, knowledgeis represented via RDF statements about resources, where a

121

resource is an abstraction of any piece of information aboutsome domain. A RDF statement is represented by a RDFtriple, composed of subject (a resource), predicate (speci-fied by a resource as well) and object (a resource or a literal,i.e. a value from a basic type). A RDF graph is thereforea set of RDF triples. Resources are uniquely identified bya Uniform Resource Identifier (URI) [4], or by a local (tothe RDF graph) identifier if they have not meaning outsideof the local context (in which case they are called blanknodes). The resources used to specify predicates are calledproperties. A resource may have one or more types, speci-fied by the predefined property rdf:type. A RDF datasetis a set of graphs, each associated with a different name (aURI), plus a default graph without a name. We use RDFthrough the framework to represent any kind of informa-tion and its transformations. In RDF, prefixes can be usedin place of the initial part of a URI, representing specificnamespaces for vocabularies or set of resources.

We extensively use SPARQL2 [21], the standard querylanguage for RDF datasets. SPARQL has a relational alge-bra semantics, analogous to those of traditional relationallanguages, such as Structured Query Language (SQL). TheSPARQL CONSTRUCT, one of the SPARQL query forms,takes as input a RDF dataset and produces a RDF graph.While the SPARQL Query Language is “read-only”, theSPARQL Update Language [33] defines a way to performupdates on a Graph Store, the “modifiable” version of aRDF Dataset. A SPARQL Update request is composed of anumber of operations. The current version of the standardis SPARQL 1.1, but much of the existing work refers to theprevious version, SPARQL 1.0 [32]. SPARQL 1.1 algebraoffers an expanded set of operators, effectively allowing theexpression of queries that were not expressible before.

The ubiquity of Web browsers and Web document for-mats across a range of platforms and devices drives devel-opers to build applications on the Web and its standards.Requirements for browsers have dramatically changed fromthe first days of the Web. Now a browser is an interface to anever-growing set of client capabilities, exemplified by RichWeb Client Activity at W3C. All modern browsers nativelysupport the Scalable Vector Graphics (SVG) standard [15],a language representing mixed vector and raster content,based on Extensible Markup Language (XML) [12]. To-gether with the long established Document Object Model(DOM) Events [31, 23] and ECMAScript3 [16] support, itallows the realisation of complete interactive visualisationapplications. Indeed, ECMAScript libraries for interactivedata visualization are proliferating, from standard visuali-sations [19, 3, 9] to specialized visualisations for specificdomains [36], especially leveraging the SVG technology.

2Originally a recursive acronym SPARQL Protocol and RDF QueryLanguage, the extended form has then been dropped from W3C documents

3Commonly called JavaScript, the dialect from Mozilla Foundation.

3. Related Work

Several languages were proposed to define SPARQLviews in a way analogous to SQL views. A SPARQL viewis a graph intensionally defined by a SPARQL CONSTRUCT

query; the input dataset can be composed by both “real”(extensionally defined) graphs and views. RVL [28] isan early effort, using an imperative language for definingviews based on an independently defined query language(RQL [24]). vSPARQL [35] is an extension of SPARQL1.0 grammar allowing named views defined with CONSTRUCT

queries and reusable in other queries. Schenk and Staab,working on Networked Graphs [34], propose an RDF-basedsyntax to define views, which are graphs defined in termsof SPARQL 1.0 CONSTRUCT queries on explicitly definedgraphs and other views. Although powerful enough todefine read-only applications (possibly together with visual-ization tools described below), network of views do not eas-ily model interactive applications. In particular, they facethe problem of how to represent events and time-dependentinformation, including the application state.

Two pipeline languages have been proposed to defineRDF transformations, namely DERI Pipes [27] and SPAR-QLMotion [26]. They offer a set of basic operators on RDFgraphs to build the pipelines and they are both endowedwith a graphical environment to create the pipelines usingthe available operators (free in the case of DERI Pipes, in acommercial software for SPARQLMotion [13]). In SPAR-QLMotion, both pipelines and queries are represented inRDF (for queries using the SPIN-SPARQL [18] syntax).

Visualbox [20] and Callimachus [2] have been proposedfor linked data visualisation. In their two-step model/viewapproach, SPARQL queries select data and a template lan-guage generates the (XML-based) visualisation. SPARQLWeb Pages (SWP) is a RDF-based framework (to be usedwith SPARQL Motion or on its own) to describe and ren-der HTML+SVG visualisations of linked data. HTML andSVG are mapped to two corresponding vocabularies and to-gether with the UISPIN Core Vocabulary allow the associa-tion of a RDF resource with the description of its visualisa-tion. The description may be also statically associated witha class of resources, with each specific resource mappingdefined through a SPARQL query. In all these proposals theexecution model corresponds to managing a single HTTPrequest, as with typical application server technologies likeJava Servlet or PHP. Persistence and logical relationshipsbetween requests and client state must be managed explic-itly (e.g. saving/loading data related to a session and encod-ing parameters in requests)4.

Generation/manipulation of queries at runtime is widely

4Both Callimachus and SWP offer some aid for building interactiveapplications via special functions and syntaxes, but the execution modelremains request oriented.

122

used both in SQL and in SPARQL. Several systems (fora SPARQL example, see Jena [29]) provide basic supportthrough parameterized queries, in which some parametersare bound (through some external mechanism) to actual(scalar) values at execution time. This mechanism is notsufficient when the structure of the query must be changeddynamically (e.g. for multiple or complex search criteriaand/or ordering rules). Generic dynamic query genera-tion is usually achieved through string-based, semantically-unaware, manipulation or through a programmatic interfaceoffered by the host language. There have been efforts to rep-resent queries using semantically rich structures not tied toa specific host language [37], specifically for SPARQL thealready mentioned SPIN-SPARQL [18] vocabulary. Whilethis vocabulary potentially allows dynamic query genera-tion, its use for this purpose is documented only for a spe-cific case of query rewriting [17]5.

4. SWOWS

We set the following requirements for SWOWS: to bebased on a dataflow language in which data trasformationsare represented as pipelines; to use pipelines through cas-cading declarative views on the input or other views; to rep-resent data as RDF; to be able to connect to existing RDFsources; to exhibit interactivity through Web interface in-put/output; to represent pipelines as RDF to share and re-use; to support interoperability with XML; to use existingstandards whenever possible.

The platform we propose allows users to define linkeddata applications through a pipeline language based onRDF. Users create pipelines using a visual representation,through a Web-based editor, in turn interacting with apipeline repository. Other software, called the dataflowengine, executes the pipeline (after downloading the cor-responding RDF Graph from the repository) on a possiblyseparate server, with a Web-based interface as well. Fig-ure 1 shows a simplified lifecycle of the pipeline, from edit-ing and saving it in a directly controlled repository, to even-tually sharing it for use “as it is” or reuse in other pipelines.

A SWOWS pipeline is a side-effect-free dataflow pro-gramming module, taking as input an RDF Dataset and re-turning another RDF Dataset. The available components(shown in Figure 2) are: the default input graph and the(named) input graphs; the default output graph and the(named) output graphs; the transform processors, that ex-ecute a SPARQL 1.1 [21] query against a RDF dataset;the single graph stores, whose content is incrementallymodified during an execution of the pipeline by execut-ing a SPARQL 1.1 Update [33] on it each time one ofits input graphs changes (the update takes as input a RDF

5SPIN-SPARQL vocabulary is widely used as a way to attach SPARQLrules to RDF resources.

Figure 1. A schematic view of the platform

dataset composed by the previous snapshot of the store asdefault graph and a set of input named graphs); existingpipelines which can be used as components in the currentpipeline; file data sources, i.e. RDF graphs generated byloading local or remote files (serialized in one of the stan-dard RDF formats); another way to access data from outsidethe pipeline is through SPARQL Federated Queries used intransform processors or simple graph stores.

Figure 2. The pipeline base component types

A pipeline can be designed just for reuse by otherpipelines. If a pipeline has to be executed (i.e. it is a toplevel pipeline), its default output graph must comply withan XML DOM Ontology6 in RDF. It will represent a HTMLor SVG document, to be rendered by the user interface. Itsdefault input graph will receive the DOM Events generatedin the interface, described with a DOM Events Ontology7.

The main blocks of the implemented application arethe editor, the pipeline repository and the dataflow en-gine. The editor is a rich Web application with its clientside logic coded in HTML+CSS+JavaScript and embedded

6http://www.swows.org/2013/07/xml-dom7http://www.swows.org/2013/07/xml-dom-events

123

in the Callimachus Web application [2], used as pipelinerepository. The dataflow engine is a Java-based (usingApache Jena [29]) Web application maintaining the stateof each running pipeline instance; when a new instance islaunched (e.g., from the editor) the engine initialises thepipeline and returns its output to the client, along with apiece of JavaScript logic to report handled events back to theserver; each time an event is fired on the client, the dataflowengine is notified and answers with the changes to be exe-cuted on the client content. On the client side, any browsersupporting JavaScript can use both the editor and the gener-ated application. The software is freely available8.

5. Transform Processors

In the previous version of the platform the behaviourof a transform processor was always specified through aCONSTRUCT query. It has been changed to allow also for aSELECT query or a UPDATE request, maintaining the fact thatthe transform processor executes a stateless operation on aRDF dataset, resulting in a single RDF graph.

The SELECT queries are run according to the correspond-ing semantics, but the result set is represented as a RDFgraph, containing the bindings, their order and each valueassociated with a binding. This allows the derivation ofsome order (depending on the ORDER BY clause) over a set ofitems. Ordering could also be achieved through CONSTRUCT

queries but in a contrived and potentially inefficient way.The UPDATE requests are run considering the input dataset

as a Graph Store; the output is given by the content of thedefault graph after the UPDATE (the changes to the othergraphs are discarded). The UPDATE is useful if most of theinput default graph must be copied to the output, as usingUPDATE only the changes need to be expressed.

6. Dynamic Queries

One of the advantages of a declarative platform basedon a flexible model such as RDF is to easily generalisefunctions. For example if one wants to generalise an op-eration of filtering or aggregation on some property, onecan take the property from a configuration graph or as re-sult of another query: properties in RDF are resourcesand can be treated as such. In practice, due to some lim-itations in SPARQL expressivity (e.g., there is no directway to express a FORALL operator), it can be tricky tobuild generalised queries; moreover, due to current lim-its in SPARQL engines and protocol infrastructure, theycan be highly unefficient. For these reasons we pro-pose dynamic query generation, using a RDF vocabu-lary to represent any SPARQL query. The vocabulary

8http://www.swows.org/

reuses SPIN-SPARQL [18] classes and properties (names-pace http://spinrdf.org/sp#, prefix sp:). Some prop-erties (namespace http://www.swows.org/spinx#, prefixspx:) are added to avoid the use of lists when the or-der in the query structure is not important. As an ex-ample, whenever SPIN-SPARQL uses the sp:elements

property to associate a list of elements with a SPARQLoperator in a query (e.g., ex:op1 sp:elements (ex:el1

ex:el2)), we use the spx:element property to associateeach single element with the given operator (e.g., ex:op1spx:element ex:el1, ex:el2). This choice simplifieswriting queries that manipulate queries. The namespacehttp://www.swows.org/spinx/var/ (prefix var:) is fur-ther defined to contain all the used variables (e.g., variable?foo represented as var:foo) in order to simplify definitionand comparison of query variables.

7. An Example: Exploring Artworks

We will demonstrate in practice how a simple LinkedData browsing application can be built with the proposedplatform and methodology. Our aim is to build an interfaceto visually navigate through a set of world artworks. Thereare a number of contexts in which it is important to offer avisual navigation interface, reducing the need to use text tointeract with the application. One such context is a deviceavailable in a public space, that may be designed for casualuse and international audience. The data used comes fromFreebase, a community-curated (and derived from other on-line sources like Wikipedia) database of well-known peo-ple, places, and things. The data is rich enough to allow forfaceted navigation using different dimensions: author, artform (painting, sculpture, etc.), art genre (portrait, allegory,etc.), creation date (usually at least the year).

The usual approach for faceted navigation is to usethe different categories to build multi taxonomy filters forsearching items. This approach is indeed established andeffective; we want to experiment instead with the use ofdifferent dimensions to guide the user in free exploration ofdataset item by item. This kind of navigation can be usefulwhen the user has no previous complete knowledge of theused taxonomies and/or the user interface will be used forcasual exploration, wandering through a data set. Usuallythis is provided through related items links, that provide asingle dimension for this kind of exploration.9

The user interface for the application is composed of: amain area in which an image is shown together with infor-mation about the currently selected item; a variable numberof related artworks areas, in which links to related artworks

9In the present work we present the idea of multifaceted visual explo-ration just to show the feasibility of the proposed approach for design ofbrowsing applications. We think that the idea on its own deserves to bestudied and tested in future research.

124

(visually represented as thumbnails) are shown according todifferent axes (in Figure 3 one of the possible configurationsof the application is shown10). The pipeline design has beenbased on the separation between presentation elements (po-sition and sizes of the different areas) and content elements(different filters used for related artworks). A specific graphdefines the association between the two kinds of elements.

Figure 3. A screenshot of the example appli-

cation, here with the main area in the center

and related artwork areas at the four sides.

For this example we consider the Freebase dataset to beavailable from a SPARQL Endpoint, considering the stan-dard mapping defined by Freebase mantainers. It is pos-sible to use the public FactForce endpoint11 (aggregatingalso several other datasources [6]), or to install a cloud-based distribution as the Sindice Freebase Distribution12 fora more reliable access.

The pipeline, shown in Fig. 4, is composed by the fol-lowing components: some Data Sources corresponding toqueries: one for each available filter (here four, but couldbe any number) and one, filters-common.rq, to be used astemplate to dynamically build the query; Framing that rep-resents the wireframe of the user interface, both as SVGstructure and as specification of the areas for the other com-ponents; FiltersQuery that generates the dynamic query forthe areas based on AreaFilter, the association between ar-eas and filters; SelArtwork, that stores the selected artwork,setting the initial one and changing it when the thumbnailfor another one is clicked (events coming from Default In-put); RelatedArtwork, that runs the dynamic query to obtainthe sets of related artworks; View, that creates the dynamicpart of the Default Output (the SVG) to be merged with thestatic part of the visualization from Framing.

The “heart” of the pipeline is the generation and execu-tion of the query that retrieves the data of related artworksfor each area based on the defined areas, the defined filters

10Some images are not shown due to broken URLs in the dataset.11http://factforge.net/sparql12http://sindicetech.com/freebase

(the queries) and the association between them. The areasare defined like the following (Turtle syntax):

1 <#bot tomBarArea>2 a <#ImageArea>;3 <#svgElement> <#bot tomBar >;4 <#x> 2 0 ;5 <#y> 550 ;6 <#width> 800 ;7 <#h e i g h t> 7 0 ;8 <#c o l s> 7 ;9 <#rows> 1 .

The queries representing the available filters are definedin the following style (this is same-genre.rq):

1 PREFIX aw : <h t t p : / / r d f . f r e e b a s e . com / ns / v i s u a l a r t . a r t w o r k .>2

3 SELECT DISTINCT ? r e l a t e d A r t w o r k4 WHERE {5 ? s e l e c t e d A r t w o r k6 aw : a r t i s t ? a r t i s t ;7 aw : a r t g e n r e ? g e n r e ;8 aw : a r t f o r m ? form .9 ? r e l a t e d A r t w o r k

10 aw : a r t i s t ? d i f f A r t i s t ;11 aw : a r t g e n r e ? g e n r e ;12 aw : a r t f o r m ? d i f f F o r m .13 FILTER ( ? d i f f A r t i s t != ? a r t i s t ) .14 FILTER ( ? d i f f F o r m != ? form ) .15 }

Any kind of SELECT query will be accepted as long as itprojects the variable ?relatedArtwork and use the variable?selectedArtwork corresponding to the selected artwork.

Finally the association between areas and filters is de-fined through a graph like the following one:

1 <#topBarArea> <# f i l t e r > <same�a r t i s t . rq >.2 <#bot tomBarArea> <# f i l t e r > <same�genre�form . rq >.3 <#l e f t B a r A r e a> <# f i l t e r > <same�g e n r e . rq >.4 <#r i g h t B a r A r e a> <# f i l t e r > <contemp . rq >.

The FiltersQuery component generates the dynamicquery and has as inputs various named graphs: <#filters>,from the file data sources corresponding to the queriesdefining the filters (the RDF graphs, being connected to thesame input, are merged, but each query is still distinguish-able, as each query root element corresponds to the orig-inal query URI); <#common>, from a file data source cor-responding to <filter-common.rq>, a query used to holdconstraints that should be satisfied by any filter (e.g. hav-ing at least an image and a minimum set of information);<#areas>, from AreaFilters component, giving the associa-tion between areas and filters described above; <#framing>,from Framing component, holding the definition of the ar-eas, also described above. The default graph is given by theunion of <#common> and <#filters>. FiltersQuery is de-fined an Update request; it is useful to recall that the outputgraph is obtained from the default input graph, applying onit the Update request. The Update request is the following(prefix declaration omitted):

1 INSERT {2 <#F i l t e r s Q u e r y>3 a sp : S e l e c t ;4 spx : r e s u l t V a r i a b l e v a r : a r ea , v a r : r e l a t e d A r t w o r k ;5 sp : where <#f i l t e r U n i o n >;

125

Figure 4. The pipeline of the example application.

6 sp : o rderBy v a r : a r e a .7 <#f i l t e r U n i o n> a sp : Union .8 <#s e l e c t e d>9 a sp : T r i p l e P a t t e r n ;

10 sp : s u b j e c t <#g l o b a l >;11 sp : p r e d i c a t e <#s e l e c t e d A r t w o r k >;12 sp : o b j e c t v a r : s e l e c t e d A r t w o r k .13 }14 WHERE {} ;15

16 INSERT {17 <#f i l t e r U n i o n> spx : e l e m e n t18 [ a spx : ElementGroup ;19 spx : e l e m e n t20 <#s e l e c t e d >,21 [ a sp : S e r v i c e ;22 sp : s e r v i c e U R I <h t t p : / / f a c t f o r g e . n e t / s p a r q l >;23 spx : e l e m e n t24 [ a sp : SubQuery ; sp : que ry ? f i l t e r ] ] ] .25 ? f i l t e r W h e r e spx : e l e m e n t26 [ a sp : SubQuery ;27 sp : que ry < f i l t e r s �common . rq> ] .28 ? f i l t e r29 spx : r e s u l t V a r i a b l e30 [ sp : a s v a r : a r e a ; sp : e x p r e s s i o n ? a r e a ] ,31 v a r : s e l e c t e d A r t w o r k ;32 sp : l i m i t ? f i l t e r L i m i t .33 }34 WHERE {35 GRAPH <#f raming> {36 ? a r e a37 a <#ImageArea>;38 <#c o l s> ? a r e a C o l s ; <#rows> ? areaRows . } .39 GRAPH <#a r e a s> { ? a r e a <# f i l t e r > ? f i l t e r . } .40 BIND ( ? a r e a C o l s ⇤? areaRows AS ? f i l t e r L i m i t ) .41 GRAPH <# f i l t e r s > { ? f i l t e r sp : where ? f i l t e r W h e r e . } .42 } ;

The Update request is composed by two separate Up-date operations. The first one (lines 1–13) is constant (infact the WHERE clause is empty) and builds the fixed part ofthe query to be generated. The second Update request de-pends from the association between areas and filters (line38) to build the part of the query corresponding to each fil-ter and consisting of a common part (lines 16–21) and hav-ing as subquery the query corresponding to the filter (lines

22–24). That filter query is also enriched in some ways:the filter-common.rq query is added as a subquery (lines25–26); a LIMIT clause (sp:limit) is added to retrieve ex-actly the number of items that will be shown in each area(lines 34–37, 39, 31); the corresponding area is added tothe variables projected by each filter query (lines 28, 19);the queries are joined to the selected artwork through pro-jecting the variable for each query (line 31) and joining eachquery with a constant part that reads the selected artworkfrom the input of the generated query (lines 8–11, 19).

As the output of this component is connected to the inputnamed #query of RelatedArtwork, this query is executed inthat component, taking as input the selected artwork. Thepurpose of using a SELECT query is having the items or-dered. Even in the case the order of the related artworksin an area is undefined (the tuples are ordered only withrespect to ?area), the SELECT result gives an arbitrary or-der that can be used to draw the corresponding thumbnails.Finally, the CONSTRUCT query in the component View (notshown), builds the SVG page based on an image and infor-mation on the selected artwork and the thumbnails of relatedartworks organized by areas.

8. Conclusions and Future Work

We discussed the use of the platform SWOWS and dy-namic query generation to build interactive linked data ap-plications, especially in the case of flexible browsing appli-cations. Dynamic query generation and other extensions tothe platform as originally conceived were presented, justi-fied by application to concrete cases.

We want to keep experimenting in this direction, andpossibly also to leverage this experimentation to build

126

higher level interfaces, designed also for usage by non-expert users, as a way to flexibly interact with linked data.

References

[1] B. Adida, M. Birbeck, S. McCarron, and I. Herman. RDFaCore 1.1 - 2nd Edition. W3C Recommendation 22 August2013.

[2] S. Battle, D. Wood, J. Leigh, and L. Ruth. The CallimachusProject: RDFa as a Web Template Language. In Proc.COLD 2012, volume 905 of CEUR, 2012.

[3] N. G. Belmonte. JavaScript InfoVis Toolkit.http://philogb.github.io/jit/, 2011.

[4] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Re-source Identifier (URI): Generic Syntax. RFC 3986 (IN-TERNET STANDARD), Jan. 2005. Updated by RFC 6874.

[5] T. Berners-Lee, J. Hendler, and O. Lassila. The SemanticWeb. Scientific American, 284(5):34–43, 2001.

[6] B. Bishop, A. Kiryakov, D. Ognyanov, I. Peikov, Z. Tashev,and R. Velkov. Factforge: A fast track to the web of data.Semantic Web, 2(2):157–166, 2011.

[7] C. Bizer, T. Heath, and T. Berners-Lee. Linked data-thestory so far. Int. J. on Semantic Web and Information Sys-tems, 5(3):1–22, 2009.

[8] K. Bollacker, C. Evans, P. Paritosh, T. Sturge, and J. Tay-lor. Freebase: a collaboratively created graph database forstructuring human knowledge. In Proc. ACM SIGMOD’08,pages 1247–1250. ACM, 2008.

[9] M. Bostock, V. Ogievetsky, and J. Heer. D3: Data-drivendocuments. IEEE Trans. Visualization & Comp. Graphics,17:2301–9, 2011.

[10] P. Bottoni and M. Ceriani. A Dataflow Platform for In-silicoExperiments Based on Linked Data. In Proc. DNIS 2014,pages 112–131, 2014.

[11] P. Bottoni, M. Ceriani, and S. Valentini. A user interfaceto build interactive visualizations for the semantic web. InISWC 2013 (Posters & Demos), pages 165–168, 2013.

[12] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler,F. Yergeau, and J. Cowan. Extensible Markup Language(XML) 1.1 (Second Edition). W3C Recommendation 16August 2006, edited in place 29 September 2006.

[13] T. COMPOSER. TOPBRAID COMPOSER 2007 Featuresand getting Started Guide Version 1.0, created by TopQuad-rant, US, 2007.

[14] R. Cyganiak, D. Wood, and M. Lanthaler. RDF 1.1 Conceptsand Abstract Syntax. W3C Recommendation 25 February2014.

[15] E. Dahlstrom, P. Dengler, A. Grasso, C. Lilley, C. McCor-mack, D. Schepers, J. Watt, J. Ferraiolo, J. Fujisawa, andD. Jackson. Scalable Vector Graphics (SVG) 1.1 (SecondEdition). W3C Recommendation 16 August 2011.

[16] ECMA. Ecmascript language specification, standard ecma-262, 5.1 edition. http://www.ecma-international.org/ecma-262/5.1/, 2011.

[17] C. Follenfant, O. Corby, F. Gandon, D. Trastour, et al. Rdfmodelling and sparql processing of sql abstract syntax trees.In PSW-1st Workshop on Programming the Semantic Web,2012.

[18] C. Furber and M. Hepp. Using SPARQL and SPIN for dataquality management on the semantic web. In Business In-formation Systems, pages 35–46. Springer, 2010.

[19] Google. Google charts, 2010.[20] A. Graves. Creation of visualizations based on linked data.

In Proc. WIMS’13, page 41. ACM, 2013.[21] S. Harris et al. SPARQL 1.1 Query Language. W3C Rec-

ommendation 21 March 2013.[22] I. Hickson. HTML Microdata. W3C Working Group Note

29 October 2013.[23] G. Kacmarcik, T. Leithead, J. Rossi, D. Schepers,

B. Hhrmann, P. Le Hgaret, and T. Pixley. Document ObjectModel (DOM) Level 3 Events Specification. W3C Recom-mendation 13 November 2000.

[24] G. Karvounarakis, A. Magkanaraki, S. Alexaki,V. Christophides, D. Plexousakis, M. Scholl, and K. Tolle.RQL: A functional query language for RDF. In TheFunctional Approach to Data Management, pages 435–465.Springer Berlin Heidelberg, 2004.

[25] R. Khare and T. Celik. Microformats: a pragmatic path tothe semantic web. In Proc. WWW’06, pages 865–866. ACM,2006.

[26] H. Knublauch et al. SPARQLMotion Specifications, 2010.sparqlmotion.org.

[27] D. Le-Phuoc, A. Polleres, M. Hauswirth, G. Tummarello,and C. Morbidoni. Rapid prototyping of semantic mash-upsthrough semantic web pipes. In Proc. WWW ’09, pages 581–590. ACM, 2009.

[28] A. Magkanaraki, V. Tannen, V. Christophides, and D. Plex-ousakis. Viewing the Semantic Web through RVL Lenses.In Proc. ISWC 2003, volume 2870 of LNCS, pages 96–112.Springer, 2003.

[29] B. McBride. Jena: a semantic Web toolkit. Internet Com-puting, IEEE, 6(6):55–59, Nov/Dec 2002.

[30] M. Odersky, P. Altherr, V. Cremet, B. Emir, S. Micheloud,N. Mihaylov, M. Schinz, E. Stenman, and M. Zenger. TheScala language specification, 2004.

[31] T. Pixley. Document Object Model (DOM) Level 2 EventsSpecification. W3C Recommendation 13 November 2000.

[32] E. Prud’hommeaux and A. Seaborne. SPARQL Query Lan-guage for RDF. W3C Recommendation 15 January 2008.

[33] S. Schenk, P. Gearon, et al. SPARQL 1.1 Update. W3CRecommendation 21 March 2013.

[34] S. Schenk and S. Staab. Networked graphs: a declarativemechanism for SPARQL rules, SPARQL views and RDFdata integration on the web. In Proc. WWW ’08, pages 585–594. ACM, 2008.

[35] M. Shaw, L. T. Detwiler, N. Noy, J. Brinkley, and D. Su-ciu. vSPARQL: A view definition language for the semanticweb. Journal of Biomedical Informatics, 44(1):102 – 117,2011. Ontologies for Clinical and Translational Research.

[36] S. A. Smits and C. C. Ouverney. jsPhyloSVG: A JavascriptLibrary for Visualizing Interactive and Vector-Based Phylo-genetic Trees on the Web. PloS one, 5(8):e12267, 2010.

[37] J. Van den Bussche, S. Vansummeren, and G. Vossen.Towards practical meta-querying. Information Systems,30(4):317–332, 2005.

127