This paper presents Linked Data Reactor (LD-Reactor or LD-R) as a framework for developing exible and reusable User Interface 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 SemanticUI framework for exible 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
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
information management such as information retrieval, search, visualization,
customization, personalization and integration [
The current communication gap between Semantic Web developers and User Experience (UX) designers, caused by the need to bear Semantic Web knowledge, prevents the streamlined ow 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 expectations 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 [
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 exibility by incorporating RDF-based Web components and scopes. In the following sections, the main elements of the architecture are described: 2.1
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-de ned components to interact with Linked Data in three modes: view, edit and browse.
Interaction Mode
Scopes
Configurations
LD-R
Web Components
1 http://ld-r.org Resource Property
Value
Browser Viewer
Editor
The data- ow in the system starts from the Dataset component which handles all the events related to a set of resources under a named graph identi ed by a URI. The next level is the Resource component which is identi ed 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 di erent components to view, edit and browse the property values. Viewer, Editor and Browser components are terminals in the LD-R single directional data ow where customized user-generated components can be plugged into the system. User interactions with the LD-R components are controlled by a set of con gurations de ned on one or more selected component levels known as scopes. 2.2
LD-R Web components provide a versatile approach for context adaptation. A context can be a speci c domain of interest, a speci c user requirement or both. In order to enable customization and personalization, the LD-R approach exploits the concepts of Scope and Con guration. A scope is de ned as a hierarchical permutation of Dataset, Resource, Property and Value components (cf. Figure 3). Value 15
D Property
Resource
Each scope conveys a certain level of speci city on a given context ranging from 1 (most speci c) to 15 (least speci c). Scopes are de ned by using either the URIs of named graphs, resources and properties, or by identifying the resource types and data types. A con guration is de ned as a setting which a ects the way the LDA and Web components are interpreted and rendered (e.g. render a speci c component for a speci c RDF property or enforce a component to display Wikipedia page URIs for DBpedia resources). UI adaptation is handled by traversing the con gurations for scopes, populating the con gurations and overwriting them when a more speci c applicable scope is found. As shown in Code 1 below, in the worst case when the DRPV scopes are used and the UI is P1 C7
R1
C6
D1 P2 C4
C5 C2 C3 R2
P3 C11
C1
C8
D2 R3
C10 P4
C9 R4 P5 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 con guration hypergraph containing scopes with the maximum depth of DRP. The graph de nes a generic con guration for the application as C1. There are con gurations de ned 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 con gurations for the RP scope R2P2 as C5 and for the DRP scope D1R2P2 as C6. Let's suppose we have a setting with the following values for the scopes and con gurations: { D1= <http://ld-r.org/users> { R2= type foaf:Person { P2= rdfs:label { C1=ffviewer:`basic'g,fattr1:1g,fattr2:3gg { C2=ffattr1:0g,fattr3:2gg { C3=ffattr3:1g,fattr4:4g,fattr5:1gg { C4=ffattr5:2g,fattr6:1gg { C5=ffviewer:`contact'g,fattr3:5g,fattr7:6gg { C6=ffattr3:8g,fattr7:1g,fattr8:3gg
With the above settings, when a property component for rdfs:label is rendered without the dataset and resource context, the con guration will be:
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:
ffviewer:`contact'g,fattr1:1g,fattr2:3g,fattr3:5g,fattr4:4g, fattr5:1g,fattr6:1g,fattr7:6gg
When the additional context of dataset as <http://ld-r.org/users> is given, attr3 and attr7 get overwritten and a new setting for attr8 is added: ffviewer:`contact'g,fattr1:0g,fattr2:3g,fattr3:8g,fattr4:4g, fattr5:1g,fattr6:1g,fattr7:1g,fattr8:3gg
Scopes can also be de ned on a per user basis, facilitating the versioning and reuse of user-speci c con gurations. User-Speci c con gurations provide di erent views on components and thereby data, based on the di erent personas dealing with them.
In addition to the ne-grained component customization, LD-R Web applications provide a ne-grained access control over the data through the component scopes. For example, an application developer can restrict access to a speci c property of a speci c resource in a certain dataset and on a speci c interaction mode. 2.3
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 components 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 o ers 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 speci cation { 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 (individual, aggregate), mode (view, edit, browse) and con guration parameters speci cation. 2 http://www.heppnetz.de/projects/goodrelations/ 3 https://developers.google.com/structured-data/
dispatch
Dispatcher RESTful Services action update communicate Endpoint
Data
LD-R Components render
Stores
Flux unidirectional data flow
Similar to content markup, Component markup can utilize commonly-known ontologies such as Schema.org in order to improve the visibility of LD-R components and enable application assemblers to better understand the intended usage and capabilities of a given component.
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 utilizes Facebook's ReactJS4 components, the Flux5 architecture, Yahoo!'s Fluxible6 framework for isomorphic Web applications (i.e. running the components code both on the server and the client) and the Semantic-UI7 framework for exible 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 support, the number of developer tools/components/applications, and the e ciency of its underlying virtual DOM approach11.
As shown in Figure 5, LD-Reactor follows the Flux architecture which eschews MVC (Model-View-Controller) in favour of a unidirectional data ow. 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 application's data and business logic, and updates all a ected 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 con gurations based on the type of data and properties 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 [
There are three modes of interactions within LD-R components namely view, browse and edit. These modes work with two types of value granularity: individual and aggregate. As shown in Figure 7, components can target individual values or interact with aggregate values when users want to show/update multiple 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 component metadata, we developed a tool13 which automatically generates the general 12 the framework is compliant with the SPARQL 1.1 standard. However, we have identi ed certain inconsistencies between OpenRDF Sesame and OpenLink Virtuoso RDF stores, which did not allow the execution of syntactically identical queries across both systems. Thereby, speci c adaptors have been implemented for each of these two RDF stores. 13 https://github.com/ali1k/ld-r-metadata-generator metadata about the components in JSON-LD, using Schema.org's SoftwareApplication schema14.
Code 2 presents a sample LD-R con g which is already in-use within the RISIS project15: { The UI should be able to render metadata properties in di erent categories (Code 2 line 3, 4). { The labels for properties should be changeable in the UI especially for technical 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 shortened 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 accommodate user-de ned values which are not listed in the menu (Code 2 line 57). 14 https://schema.org/SoftwareApplication 15 http://datasets.risis.eu g, `http : // purl . org / dc / terms / license ': f category : [ ` legalAspects '], label : [ `License '], allowNewValue : 1, objectIViewer : [ ` BasicOptionView '], objectIEditor : [ ` BasicOptionInput '], options : [ flabel : `Open Data Commons Attribution License ', value : `http : // www . opendatacommons . org / licenses / by /'g, flabel : ` Creative Commons Attribution - ShareAlike ', value : `http : // creativecommons . org / licenses /by - sa /3.0/'g g g
Code 2. An excerpt of the LD-Reactor con guration le.
We have brought an elaborate analysis of the related work in [
UI Frameworks. WYSIWYM (What You See Is What You Mean) [
Tools and Applications. In addition to the LDA UI frameworks, there are
several ad-hoc tools for Linked Data visualization and exploration such as Balloon
Synopsis [
Overall, what distinguishes Linked-Data-Reactor from the existing frameworks and tools is its modern isomorphic component-based architecture that addresses reactive and reusable UIs as its rst class citizen. 5
We argue that bridging the gap between Semantic Web Technologies and Web Components worlds brings mutual bene ts for both sides. On one hand, Semantic Web technologies provide support for richer component discovery, interoperability, integration, and adaptation on the Web. On the other, Web Components bring the advantages of UI standardization, reusability, replaceability and encapsulation to current Semantic Web applications.
This paper presented Linked Data Reactor as a component-based LDA development 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.