Linked Data Reactor: a Framework for Building Reactive Linked Data Applications Ali Khalili Knowledge Representation and Reasoning Research Group Deptartment of Computer Sciences Vrije Universiteit Amsterdam a.khalili@vu.nl Abstract. This paper presents Linked Data Reactor (LD-Reactor or LD-R) as a framework for developing flexible and reusable User In- terface components for Linked Data applications. LD-Reactor utilizes Facebook’s ReactJS components, Flux architecture and Yahoo’s Fluxible framework for isomorphic Web applications. It also exploits Semantic- UI framework for flexible UI themes. LD-R aims to apply the idea of component-based application development into RDF data model hence enhancing current user interfaces to view, browse and edit Linked Data. Documentation: http://ld-r.org Demo: http://demo.ld-r.org Code Repository: https://github.com/ali1k/ld-r 1 Introduction With the growing number of structured data published, the Web is moving towards becoming a rich ecosystem of machine-understandable Linked Data. Semantically structured data facilitates a number of important aspects of in- formation management such as information retrieval, search, visualization, cus- tomization, personalization and integration [1]. Despite all these benefits, Linked Data Applications (LDAs) are not yet adopted by the large community of Web developers outside the Semantic Web domain and, causally, by the end-users on the Web. The current communication gap between Semantic Web developers and User Experience (UX) designers, caused by the need to bear Semantic Web knowl- edge, prevents the streamlined flow of best practices from the UX community into Linked Data user interface (UI) development. The resulting lack of adoption and standardization often makes current LDAs inconsistent with user expecta- tions and impels more development time and costs on LDA developers. In this situation, more time is spent in re-designing existing UIs rather than focusing on innovation and creation of sophisticated LDAs. In [3], We performed an elaborate study on the current pitfalls of LDA UI design and proposed Adaptive Linked Data-driven Web Components and its open source implementation called Linked Data Reactor1 as a solution to tackle those issues. This paper serves as a more technical description of that idea. 2 Adaptive Linked Data-driven Web Components In order to streamline the process of UI development in LDAs, we propose an architecture of adaptive LD-R Web components – Web components enriched by the RDF data model. As shown in Figure 1, the proposed architecture addresses LDA UI reusability and flexibility by incorporating RDF-based Web components and scopes. In the following sections, the main elements of the architecture are described: 2.1 LD-R Web Components As depicted in Figure 2, there are four core component levels in an LD-R Web application. Each core component abstracts the actions required for retrieving and updating the graph-based data and provides a basis for user-defined com- ponents to interact with Linked Data in three modes: view, edit and browse. Interaction Mode View Edit Browse Scopes Configurations Component-specific Configurations Core Configurations LD-R Web Components User-defined Components Semantic Core (RDF) Components Markup Fig. 1. Main elements of the adaptive LD-R Web components architecture. 1 http://ld-r.org 1 Dataset Data Flow 2 Resource 3 Property 4 Value Viewer Browser Editor Fig. 2. Core LD-R Web components. The data-flow in the system starts from the Dataset component which han- dles all the events related to a set of resources under a named graph identified by a URI. The next level is the Resource component which is identified by a URI and indicates what is described in the application. A resource is described by a set of properties which are handled by the Property component. Properties can be either individual or aggregate when combining multiple features of a resource (e.g. a component that combines longitude and latitude properties; start date and end date properties for a date range, etc.). Each property is instantiated by an individual value or multiple values in case of an aggregate object. The value(s) of properties are controlled by the Value component. In turn, Value components invoke different components to view, edit and browse the property values. Viewer, Editor and Browser components are terminals in the LD-R sin- gle directional data flow where customized user-generated components can be plugged into the system. User interactions with the LD-R components are con- trolled by a set of configurations defined on one or more selected component levels known as scopes. 2.2 Scopes and Configurations LD-R Web components provide a versatile approach for context adaptation. A context can be a specific domain of interest, a specific user requirement or both. In order to enable customization and personalization, the LD-R approach exploits the concepts of Scope and Configuration. A scope is defined as a hier- archical permutation of Dataset, Resource, Property and Value components (cf. Figure 3). 1 2 3 4 5 6 7 8 D R D D P R D V R P P R V V V V P V V V V Value 9 10 11 12 13 14 15 D R D P D R D R P P R P Property Resource Dataset Fig. 3. LD-R scopes based on the permutation of dataset, resource, property and value identifiers. 1 InitialConfig = { initial application configuration } 2 Context = [ array of scopes with the corresponding configuration objects ] 3 Config = InitialConfig 4 for ( i = 1 5 ; i < 1 ; i - -) { 5 Config . compareWith ( Context [ i ] ) { 6 Config . addMissingAttributes () 7 Config . o v e r w r i t e E x i s t i n g A t t r i b u t e s () 8 } 9 } Code 1. Algorithm for the LD-R UI adaptation. Each scope conveys a certain level of specificity on a given context ranging from 1 (most specific) to 15 (least specific). Scopes are defined by using either the URIs of named graphs, resources and properties, or by identifying the resource types and data types. A configuration is defined as a setting which affects the way the LDA and Web components are interpreted and rendered (e.g. render a specific component for a specific RDF property or enforce a component to display Wikipedia page URIs for DBpedia resources). UI adaptation is handled by traversing the configurations for scopes, populating the configurations and overwriting them when a more specific applicable scope is found. As shown in Code 1 below, in the worst case when the DRPV scopes are used and the UI is App C1 C8 C2 D1 C5 D2 C3 C9 R1 R2 R3 R4 C10 P1 P2 P3 P4 P5 C6 C7 C4 C11 Fig. 4. A sample LD-R configuration hypergraph. supposed to render the Value components, all 15 scopes need to be traversed for the adaptation: Figure 4 demonstrates an example of the LD-R configuration hypergraph containing scopes with the maximum depth of DRP. The graph defines a generic configuration for the application as C1 . There are configurations defined for the dataset scope D1 as C2 , for the resource scope R2 as C3 and for the property scope P2 as C4 . There are also configurations for the RP scope R2 P2 as C5 and for the DRP scope D1 R2 P2 as C6 . Let’s suppose we have a setting with the following values for the scopes and configurations: – D1 = – R2 = type foaf:Person – P2 = rdfs:label – C1 ={{viewer:‘basic’},{attr1 :1},{attr2 :3}} – C2 ={{attr1 :0},{attr3 :2}} – C3 ={{attr3 :1},{attr4 :4},{attr5 :1}} – C4 ={{attr5 :2},{attr6 :1}} – C5 ={{viewer:‘contact’},{attr3 :5},{attr7 :6}} – C6 ={{attr3 :8},{attr7 :1},{attr8 :3}} With the above settings, when a property component for rdfs:label is ren- dered without the dataset and resource context, the configuration will be: {{viewer:‘basic’},{attr1 :1},{attr2 :3},{attr5 :2},{attr6 :1}} When the property component gets rendered within the resource context of type foaf:Person, the settings for viewer and attr5 are overwritten and new settings for attr3 , attr4 and attr7 are added: {{viewer:‘contact’},{attr1 :1},{attr2 :3},{attr3 :5},{attr4 :4}, {attr5 :1},{attr6 :1},{attr7 :6}} When the additional context of dataset as is given, attr3 and attr7 get overwritten and a new setting for attr8 is added: {{viewer:‘contact’},{attr1 :0},{attr2 :3},{attr3 :8},{attr4 :4}, {attr5 :1},{attr6 :1},{attr7 :1},{attr8 :3}} Scopes can also be defined on a per user basis, facilitating the versioning and reuse of user-specific configurations. User-Specific configurations provide different views on components and thereby data, based on the different personas dealing with them. In addition to the fine-grained component customization, LD-R Web applica- tions provide a fine-grained access control over the data through the component scopes. For example, an application developer can restrict access to a specific property of a specific resource in a certain dataset and on a specific interaction mode. 2.3 Semantic Markup for Web Components The innate support of RDF in LD-R Web components enable the automatic creation of semantic markup on the UI level. Lower semantic techniques such as RDFa, Mircodata and JSON-LD can be incorporated in the core LD-R com- ponents to expose structured data to current search engines which are capable of parsing semantic markup. For example, an LD-R component created based on the Good Relations2 or Schema.org ontologies, can automatically expose the product data as Google Rich Snippets for products3 which will provide better visibility of the data on Web search results (i.e. SEO). In addition to automatic annotation of data provided by the LD-R Web components, the approach offers semi-automatic markup of Web components by creating component metadata. Component metadata consists of two categories of markup: – Automatic markup generated by parsing component package specification – metadata about the component and its dependencies. It includes general metadata such as name, description, version, homepage, author as well as technical metadata on component source repository and dependencies. – Manual markup created by component authors which exposes metadata such as component level (dataset, resource, property, value), granularity (indi- vidual, aggregate), mode (view, edit, browse) and configuration parameters specification. 2 http://www.heppnetz.de/projects/goodrelations/ 3 https://developers.google.com/structured-data/ CRUD dispatch Actions Dispatcher RESTful Services action update render communicate LD-R Stores Components Flux unidirectional data flow Data Endpoint Fig. 5. Data flow in the LD-Reactor framework. Similar to content markup, Component markup can utilize commonly-known ontologies such as Schema.org in order to improve the visibility of LD-R com- ponents and enable application assemblers to better understand the intended usage and capabilities of a given component. 3 Implementation In order to realize the idea of adaptive Linked Data-driven Web components, we implemented an open-source software framework called Linked Data Reactor (LD-Reactor) which is available online at http://ld-r.org. LD-Reactor uti- lizes Facebook’s ReactJS4 components, the Flux5 architecture, Yahoo!’s Flux- ible6 framework for isomorphic Web applications (i.e. running the components code both on the server and the client) and the Semantic-UI7 framework for flex- ible UI themes. The main reasons we chose React components over other Web Components solutions (e.g. Polymer8 , AngularJS9 , EmberJS10 , etc.) were the maturity and maintainability of the technology, the native multi-platform sup- port, the number of developer tools/components/applications, and the efficiency of its underlying virtual DOM approach11 . As shown in Figure 5, LD-Reactor follows the Flux architecture which es- chews MVC (Model-View-Controller) in favour of a unidirectional data flow. 4 https://facebook.github.io/react/ 5 https://facebook.github.io/flux 6 http://fluxible.io/ 7 http://semantic-ui.com/ 8 http://www.polymer-project.org/ 9 https://angularjs.org/ 10 http://emberjs.com/ 11 Elaborating on all these factors is beyond the scope of this paper. When a user interacts with a React component, the component propagates an action through a central dispatcher, to the various stores that hold the ap- plication’s data and business logic, and updates all affected components. The component interaction with SPARQL endpoints to retrieve and update Linked Data occurs through the invocation of RESTful services in actions. In order to allow the bootstrapping of LDA UIs, LD-Reactor provides a comprehensive framework that combines the following main elements: – A set of RESTful Web services that allow basic CRUD operations on Linked Data using SPARQL queries12 . – A set of core components called Reactors which implement core Linked Data components (see Figure 2) together with their corresponding actions and stores. – A set of default components which allow basic viewing, editing and browsing of Linked Data. – A set of minimal viable configurations based on the type of data and prop- erties from commonly-used vocabularies on the Semantic Web (e.g. foaf, dcterms and SKOS). – A basic access control plugin which allows restricting read/write access to data. LD-Reactor implementation is compliant with Microservices Architecture [4] where the existing ReactJS components can be extended by complementary Linked Data services. In contrast to the centralized monolithic architecture, the microservices architecture allows placing the main functionalities of the LDA into separate decoupled services and scale by distributing these services across servers, replicating as needed. This architectural style also helps to minimize the redeploying of the entire application when changes in components were re- quested. There are three modes of interactions within LD-R components namely view, browse and edit. These modes work with two types of value granularity: indi- vidual and aggregate. As shown in Figure 7, components can target individual values or interact with aggregate values when users want to show/update multi- ple values at once. Figure 6 depicts the browse mode where individual (e.g. item lists with check boxes) and aggregate data browser (e.g. data sliders or maps) components can be employed. Semantic markup of data (as discussed in Section 2.3) is supported natively within the framework by embedding Microdata annotations within the LD-R Web components. Additionally, in order to facilitate the creation of compo- nent metadata, we developed a tool13 which automatically generates the general 12 the framework is compliant with the SPARQL 1.1 standard. However, we have iden- tified certain inconsistencies between OpenRDF Sesame and OpenLink Virtuoso RDF stores, which did not allow the execution of syntactically identical queries across both systems. Thereby, specific adaptors have been implemented for each of these two RDF stores. 13 https://github.com/ali1k/ld-r-metadata-generator Fig. 6. A screenshot of LD-Reactor browse mode. metadata about the components in JSON-LD, using Schema.org’s SoftwareAp- plication schema14 . Code 2 presents a sample LD-R config which is already in-use within the RISIS project15 : – The UI should be able to render metadata properties in different categories (Code 2 line 3, 4). – The labels for properties should be changeable in the UI especially for tech- nical properties (e.g. RDF dump) that are unknown to researchers outside the Semantic Web domain (Code 2 line 18, 26, 40). – There should be a hint for properties to help metadata editors to understand the meaning of the property (Code 2 line 20, 28, 41). – Instead of showing the full URIs, the output UI should render either a short- ened URI or a meaningful string linked to the original URI (Code 2 line 6). – Whenever a DBpedia URI is provided, display the corresponding Wikipedia URI enabling users to retrieve human readable information (Code 2 line 33, 45). – When a dropdown menu is provided, there should be the ability to accom- modate user-defined values which are not listed in the menu (Code 2 line 57). 14 https://schema.org/SoftwareApplication 15 http://datasets.risis.eu Fig. 7. A screenshot of LD-Reactor view and edit mode for individual (top) and ag- gregate (bottom) values. 1 resource : { 2 ‘ generic ’ : { 3 usePropertyCategories : 1, 4 p r o p e r t y C a t e g o r i e s : [ ‘ overview ’ , ‘ legalAspects ’ , ‘ technicalAspects ’ ] , 5 r es ou r ce Re ac t or : [ ‘ Resource ’ ] , 6 shortenURI : 1 7 } 8 }, 9 property : { 10 ‘ generic ’ : { 11 p ro pe r ty Re ac t or : [ ‘ IndividualProperty ’ ] , 12 objectReactor : [ ‘ IndividualObject ’ ] , 13 objectIViewer : [ ‘ BasicIndividualView ’ ] , 14 objectIEditor : [ ‘ BasicIndividualInput ’ ] 15 }, 16 ‘ http : // purl . org / dc / terms / language ’ : { 17 allowNewValue : 1 , 18 label : [ ‘ Dataset Language ’ ] , 19 category : [ ‘ overview ’ ] , 20 hint : [ ‘ The language of the dataset . Resources defined by the Library of Congress ( http : // id . loc . gov / vocabulary / iso 6 3 9 -1 . html , http : // id . loc . gov / vocabulary / iso 6 3 9 -2 . html ) SHOULD be used . ’ ] , 21 objectIViewer : [ ‘ LanguageView ’ ] , 22 objectIEditor : [ ‘ LanguageInput ’ ] , 23 defaultValue : [ ‘ http : // id . loc . gov / vocabulary / iso 6 3 9 -1 / en ’ ] 24 }, 25 ‘ http : // purl . org / dc / terms / spatial ’ : { 26 label : [ ‘ Geographical coverage ’ ] , 27 category : [ ‘ overview ’ ] , 28 hint : [ ‘ The geographical area covered by the dataset . ’ ] , 29 allowNewValue : 1 , 30 objectReactor : [ ‘ AggregateObject ’ ] , 31 objectAViewer : [ ‘ DBpediaGoogleMapView ’ ] , 32 objectIViewer : [ ‘ BasicDBpediaView ’ ] , 33 asWikipedia : 1 , 34 objectAEditor : [ ‘ BasicAggregateInput ’ ] , 35 objectIEditor : [ ‘ DBpediaInput ’ ] , 36 lookupClass : [ ‘ Place ’ ] 37 }, 38 ‘ http : // purl . org / dc / terms / subject ’ : { 39 category : [ ‘ overview ’ ] , 40 label : [ ‘ Keywords ’ ] , 41 hint : [ ‘ Tags a dataset with a topic . ’ ] , 42 allowNewValue : 1 , 43 objectIEditor : [ ‘ DBpediaInput ’ ] , 44 objectIViewer : [ ‘ BasicDBpediaView ’ ] , 45 asWikipedia : 1 46 }, 47 ‘ http : // purl . org / dc / terms / license ’ : { 48 category : [ ‘ legalAspects ’ ] , 49 label : [ ‘ License ’ ] , 50 allowNewValue : 1 , 51 objectIViewer : [ ‘ BasicOptionView ’ ] , 52 objectIEditor : [ ‘ BasicOptionInput ’ ] , 53 options : [ 54 { label : ‘ Open Data Commons Attribution License ’ , value : ‘ http : // www . op e nd at ac o mm on s . org / licenses / by / ’}, 55 { label : ‘ Creative Commons Attribution - ShareAlike ’ , value : ‘ http : // c re at i ve co m mo ns . org / licenses / by - sa / 3 . 0 / ’} 56 ], 57 allowUserDefinedValue : 1 58 } 59 } Code 2. An excerpt of the LD-Reactor configuration file. 4 Related Work We have brought an elaborate analysis of the related work in [3]. In this section, we only summarize the main related work. UI Frameworks. WYSIWYM (What You See Is What You Mean) [2] is a generic semantics-based UI model to allow integrated visualization, exploration and au- thoring of structured and unstructured data. Our proposed approach utilizes the WYSIWYM model for binding RDF-based data to viewer, editor and browser UIs. Uduvudu [5] is another approach to making an adaptive RDF-based UI en- gine to render Linked Data. Instead of adopting Web components, Uduvudu em- ploys a set of flexible UI templates that can be combined to create complex UIs. Even though the static templates do not provide enough interactions for editing and browsing data (in contrast to Web components), we believe that algorithms for automatic selection of templates employed in Uduvudu can be reused in the LD-Reactor framework for automatic generation of configurations. Another sim- ilar approach is SemwidgJS [10] which brings a semantic Widget library for the rapid development of LDA UIs. SemwidgJS offers a simplified query language to allow the navigation of graph-based data by ordinary Web developers. The main difference between LD-R and SemwidgJS is that LD-Reactor suggests a more interactive model which is not only for displaying Linked Data but also for providing user adaptations based on the meaning of data. LD-Viewer [6] is another related Linked Data presentation framework particularly tailored for the presentation of DBpedia resources. In contrast to LD-Reactor, LD-Viewer builds on top of the traditional MVC architecture and its extensions rely heavily on the knowledge of RDF which is a burden for developers unfamiliar with Semantic Web technologies. Tools and Applications. In addition to the LDA UI frameworks, there are sev- eral ad-hoc tools for Linked Data visualization and exploration such as Balloon Synopsis [8] and Sgvizler [9] which can be utilized as Web components within the LD-Reactor framework. [7] provides an extensive list of these tools aiming to make Linked Data accessible for common end-users who are not familiar with Semantic Web. Overall, what distinguishes Linked-Data-Reactor from the existing frame- works and tools is its modern isomorphic component-based architecture that addresses reactive and reusable UIs as its first class citizen. 5 Conclusion We argue that bridging the gap between Semantic Web Technologies and Web Components worlds brings mutual benefits for both sides. On one hand, Semantic Web technologies provide support for richer component discovery, interoperabil- ity, integration, and adaptation on the Web. On the other, Web Components bring the advantages of UI standardization, reusability, replaceability and en- capsulation to current Semantic Web applications. This paper presented Linked Data Reactor as a component-based LDA de- velopment framework which aims to bring a better communication between UX designers and Semantic Web developers in order to reuse best UI practices within Linked Data applications. References 1. A. Khalili and S. Auer. User interfaces for semantic authoring of textual content: A systematic literature review. Web Semantics: Science, Services and Agents on the World Wide Web, 22(0):1 – 18, 2013. 2. A. Khalili and S. Auer. Wysiwym – integrated visualization, exploration and authoring of semantically enriched un-structured content. Semantic Web Journal, 2014. 3. A. Khalili, A. Loizou, and F. van Harmelen. Adaptive linked data-driven web components: Building flexible and reusable semantic web interfaces. Semantic Web Conference (ESWC) 2016, 2016. 4. J. Lewis and M. Fowler. Microservices, 2014. http://martinfowler.com/ articles/microservices.html. 5. M. Luggen, A. Gschwend, A. Bernhard, and P. Cudre-Mauroux. Uduvudu: a graph- aware and adaptive ui engine for linked data. In C. Bizer, S. Auer, T. Berners-Lee, and T. Heath, editors, Workshop on Linked Data on the Web (LDOW), number 1409 in CEUR Workshop Proceedings, Aachen, 2015. 6. D. Lukovnikov, C. Stadler, and J. Lehmann. Ld viewer - linked data presenta- tion framework. In Proceedings of the 10th International Conference on Semantic Systems, SEM ’14, pages 124–131, New York, NY, USA, 2014. ACM. 7. S. Ojha, M. Jovanovic, and F. Giunchiglia. Entity-centric visualization of open data. In J. Abascal, S. Barbosa, M. Fetter, T. Gross, P. Palanque, and M. Winckler, editors, Human-Computer Interaction INTERACT, volume 9298 of Lecture Notes in Computer Science, pages 149–166. Springer, 2015. 8. K. Schlegel, T. Weißgerber, F. Stegmaier, M. Granitzer, and H. Kosch. Balloon synopsis: A jquery plugin to easily integrate the semantic web in a website. In R. Verborgh and E. Mannens, editors, ISWC Developers Workshop, volume 1268 of CEUR Workshop Proceedings, pages 19–24. CEUR-WS.org, 2014. 9. M. G. Skjveland. Sgvizler: A javascript wrapper for easy visualization of sparql result sets. In 9th Extended Semantic Web Conference (ESWC2012), May 2012. 10. T. Stegemann and J. Ziegler. Semwidgjs: A semantic widget library for the rapid development of user interfaces for linked open data. In 44. Jahrestagung der Gesellschaft für Informatik, Informatik 2014, Big Data - Komplexität meistern, 22.-26. September 2014 in Stuttgart, Deutschland, pages 479–490, 2014.