1 Overview Welcome to my presentation of my master thesis, A - - PDF document

1 Overview

Welcome to my presentation of my master thesis, A JavaScript API for accessing Semantic Web. Here are an overview of what I’ll try to go through during this presentation. Problem descriptions In this part, I’ll talk about the prob- lem descriptions of the thesis. Theories & Methods In this part, I’ll talk about the theories and methods applied whilst working with the thesis. Implementation As part of the thesis, I implemented a frame- work named GraphiteJS. Here I’ll showcase some of the decisions I’ve made as part of the design, explain the alternatives, and go through why I chose as I did. Results Here I’ll talk about the results, showcasing some code examples that highlights some of the features that GraphiteJS’ve made possible. A demonstration I’ll also show a demo I made as part

• f the thesis, and will use that as foundation for explaining the

results. Conclusion In this part, I’ll explain my conclusions 1

Related work Concluding this presentation, I will present some related work, both academical and within the JS-community 2

2 In the beginning...

But before I begin going through the content of the thesis, I want to show you this. Who would be interested in working on a standard very cool jqery-like RDF API for Javascript? This quote by Tim Berners-Lee was cited me by Kjetil Kjernsmo, and was the beginning of this master thesis. I had been look- ing for a thesis that involved web-related technologies, and as I was experienced with JS and jQuery, I thought I could make a contribution to this question. 3

3 Problem Descriptions

In order to research what our framework should look like, we needed to have some good questions that could show us the way. This is what we came up with. What are the components required for the framework? With this question, we wanted to explore functionality our frame- work should support, and how they should be modularized. Which SDPs are applicable for the components? Design Patterns are wellknown and a lot of experience is amassed in using them, and we wanted to see which were applicable for our framework. Which features in JS are of use for the framework? Is there something about JS that makes it a good match with SW? With this question, we wanted to explore the possibilities. How should the API be designed? With all the questions above in mind, how should the API reflect our solution? Are there design features that are more prevalent to the purpose of this framework? 4

4 Purpose of application

As a continuation of the problem descriptions, we asked our- selves: What is the purpose of this application? What is it that we want to solve? Here are some of the alternatives we thought

• ff.

A generic LOD-browser The thinking was to build a we- bapplication that you could serve a LOD-endpoint, and get back an overview of the data returned. This could help users getting to an idea of the data available, and the relations they could use in further queries. A visualizer of data in RDF Again working the angle of helping users getting to know the data, but expanding upon it to help developers create graphic visualizations of data expressed in RDF. A "loader" of one or more sources of RDF One of the prominent features of jQuery, is the ease it brings in loading re- sources asynchronously. We believe this to be an important feature in JS in more general, and thought of a framework that could ease the work of loading and processing one or more sources of RDF. (Show next slide) As you can see, we went for the last point. Although the two previous projects are interesting, they didn’t grasp what we though would be interesting for developers. 5

5 Semantic Web

Now I’ll go through some of the theories and methods that make the foundation of this thesis, starting with SW. RDF RDF is the foundation of SW, specifying a formalized data model that asserts information with statements that to- gether naturally form a directed graph. Each statement consists

• f one subject, one predicate, and one object, and are hence of-

ten called a triple. An example is Arne knows Bjarne, where Arne is the subject, knows is the predicate, and Bjarne is the

• bject.

The terms described by RDF are very important to Semantic Web, but so is the fact that more terms can be ex- pressed by including other vocabularies. That means that RDF is extensible. RDFS One important extension is RDFS. It extends the se- mantic expressiveness of RDF, formalizing taxonomies through classifications and ordering of these. OWL Another important extension is OWL. This vocabulary introduces richer semantics by defining terms for expressing for- mal logic, such as cardinality. Serializations RDF doesn’t define one serialization. It does name RDF/XML as one way of doing it, but this is probably due to historic reasons, as XML and RDF was developed side- by-side, historically, and its communities connected. Other seri- 6

alizations of RDF that are highlighted in this thesis are Turtle, N3, N-Triples, RDF JSON, JSON-LD, and RDFa. SPARQL As a collection of data, SW also needs to support ways of query that data. Come SPARQL, which is a power- ful query-language that supports many forms of queries. Most prominent of these are ASK, CONSTRUCT, DESCRIBE and SELECT, that reads data. There are also forms that enables manipulating data, defined by SPARQL Update Language, but I don’t have time to go through them here. Suffice to say, with SPARQL we can ask a lot of questions, and manipulate a lot of data. (Entailment) Although it didn’t became part of GraphiteJS, entailment is important to note, as it is one of the prominent features of SW, namely the possibility to reason over data, infer- ring knowledge. Some terms are designed to help this process, such as owl:sameAs. We did chose to exclude this feature from GraphiteJS because of we felt that we didn’t have the time to do it properly, but I believe that the framework can support it in future versions. 7

6 JavaScript

JS was created in 1995, and has been a programming language for the web since the beginning. Although designed for the browser first and foremost, it now also has found its way into the serverside of web applications, and is gaining popularity as a versatile programming language, even making its way into robotics. Object-Oriented A familiar feature that JS supports is the notion of object-oriented terms. In fact, JS is centered around

• bjects, albeit a bit different than most other programming lan-

guage. Prototypical Inheritance The first thing to note is that JS is classless. It’s based on prototypical inheritance, meaning that objects are based on other objects. Dynamic Properties Another feature is that all objects are dynamic, meaning properties can be appended and removed in run-time. Functional Features Even functions are objects in JS, actually being first-class objects. This means that functions can be passed as variables. A popular pattern is to serve a function, lets call it function A, as a parameter to another func- tion, lets call it function B. Now, this is handy if function B is 8

asynchronous, as it enables us to say that function A should be called whenever the result is ready. Scope A feature that is hard to grasp for many, is the no- tion of scope in JS. But handled properly, this is yet another source of power when programming with JS. Basicly, the way JS handles scope enables you to handle asynchronous function calls with data outside the function being called. This can be very useful, as it allows us to make better use of the variables in our application. Asynchronous Features As mentioned, one of the promi- nent features of jQuery, is its ability to load resources asyn-

• chronously. This is often known as AJAX. Although the X at

the end denotes XML, it’s very often used to fetch resources in

• ther forms, such as HTML or JSON. In most browsers, this is

available through the object called XmlHttpRequest, abbrevi- ated XHR. Module Patterns As a dynamic language, JS supports many different approaches to modularize code. I will return to this later in the presentation. 9

7 Design Patterns

As part of the thesis, I found quite a lot of design patterns useful for designing the modules. I also used them to analyze existing components, as I integrated code from third party libraries. I’ll come back to this libraries later in the presentation. Adapter "Convert the interface of a class into another inter- face clients expect." Bridge "Decouple an abstraction from its implementation so that the two can vary independently." Builder "Separate the construction of a complex object from its representation so that the same construction process can create different representations." Composite "Compose objects into tree structures to repre- sent part-whole hierarchies." Decorator "Attach additional responsibilities to an object dynamically." Facade "Provide a unified interface to a set of interfaces in a subsystem." 10

Interpreter "Define a representation for its grammar along with an interpreter that uses the representation to interpret sen- tences in the language." Observer "Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically." Prototype "Specify the kinds of objects to create using a pro- totypical instane, and create new objects by copying this proto- type." Proxy "Provide a surrogate or placeholder for another object to control access to it." Strategy "Define a family of algorithms, encapsulate each

• ne, and make them interchangeable."

11

8 TDD

Test-driven design was crucial in my development of GraphiteJS... Buster.JS ... and Buster was a very good testing framework I used to help my work. 12

9 Internal representation of RDF

As part of the implementation, I had to dwell upon some choices, and I want to highlight these now. The first was the question of how to represent RDF internally in GraphiteJS. Basicly, I had two choices: A serialization of RDF Use one of the serializations, e.g. RDF/XML og Turtle. JSON-LD would probably be the best choice Even better then these, is probably JSON-LD. There is also RDF JSON, which is a simple, one resource-per-level representation

• f RDF, but JSON-LD is much more mature, and has the great-

est possibility of gaining traction within the JS-developer com- munity. A tree-structure of JS-objects The other choice of repre- sentation is to simply have a tree-structure, and have objects with methods and try to utilize the Composite pattern. (Next slide) In the end I ended up using a third-party library, which represented RDF in a tree-structure. It also indexed resources, speeding up the engine. 13

10 Query-language

Another choice was what kind of approach I would support to query the data loaded. I had three choices: Expose the datastructure (e.g. as JSON), allowing the user to navigate objects The first would have been prudent if the internal representation was RDF JSON, perhaps enhanc- ing it by indexing CURIEs. Support SPARQL The second approach requires more ef- fort, as SPARQL is a very powerful and versatile query lan- guage. Develop a new query-language The third approach needs another take on how to query RDF, or perhaps simply offer a variation on the SPARQL-syntax, like jSPARQL tried (jS- PARQL is a JSON-based emulation of the SPARQL-syntax). (Next slide) I ended up supporting SPARQL partly. This was also driven by the fact that a third-party library featured it, and I figured: why not try to enable the power of SPARQL to the users. 14

11 Module pattern

A choice I dwelt upon for quite a while, was which module pattern I should go for. The choices were: Contained module A simple pattern emulating private vari-

• ables. In fact, this pattern is often used in combination with the
• ther patterns.

Namespaces As JS is dynamic, we can easily append objects upon other objects, and thereby creating namespaces. But it doesn’t handle dependencies, and inclusion of code in wrong

• rder will break our framework. With larger frameworks, this

can become tedious. AMD Asynchronous module definition handles dependencies, well, asynchronously. It focuses on one global function, namely define (and also require, exports and module, if we want), that enables us to define modules, and describe which modules should be loaded before this one. This approach is favored by the JS- community focused on browsers, and popular libraries are Re- quireJS (which I used in the demo) and curl. CJS Module The CJS Module standard is developed by Com- monJS, which is a community of developers that want to create standards that built upon the excisting standard of JS, and which can be used by library developers. Actually, AMD is also developed by CJS, but it has been disfavored for the CJS 15

Module. Node, which is a popular run-time environment for backend development, embraces the CJS Module approach, and is generally favored by the CS-community focused on backend development. Harmony Harmony is a codename for JS.next, or ECMA-262 6th edition. It defines a module pattern, which introduces some new syntax for JS. But this syntax will probably not be widely available in many years. (Next slide) As we can see, I chose to go for AMD. I did this because we wanted to focus on developing for the browser, and so it seemed more prudent to make use of the browser-favored solution. Note that loading modules asynchronously increases the over- head of a framework, especially if there are many modules (as GraphiteJS has). But there are ways to optimize this, e.g. by bundling all the code into one file. 16

12 GraphiteJS

To summarize the implemented code, I present here some facts: 32 modules A lot of modules. 15 modules integrated code from third-party libraries A lot of reused code. rdfQuery The first library integrated, amongst other gave me a parser for RDF/XML and Turtle. rdfstore-js The biggest library integrated, included an en- gine and representation of RDF. Underscore.JS A popular library with many utility-functions making it much easier to handle data in JS. when.js A library that implements the Promise Pattern, which is very useful when working with asynchronous functions. 430 tests w/1 413 assertions (29 modules covered) A lot of tests. I was above 2 000 tests at some point, until I realized some of them were redundant. 17

13 Branches

In order to express better what code I contributed, and what code was integrated from third party libraries, I use the term

• branches. The biggest branch is Graphite, which is code written

100% by me. The rest are modified to some degree by me, but in function is true to its original libraries. 18

14 Demo

(Show the demo, do some things)

14.1 JavaScript examples

(Explain the code) 19

15 Conclusion

I’ve made some conclusion as part of this thesis, which are: Loading resources should be done asynchronously JS supports asynchronous loading very well, and it does not make sense stalling the entire application while resources are being fetched. Processing large queries should be done asynchronously My code is flawed in that it didn’t distinct between queries. This resulted in a synchronized series of executions, which halts the application. Some queries will take long time, and care should be taken to assess this, even perhaps making use of Web Workers, which enables threading in JS. A framework working with Semantic Web will have to be big There are a lot of components required to handle RDF and query the data. A good dividing of functions are necessary to keep a clean code This requires proper modularization, and I believe Graphite is a good example of this. One-size-fits-all is not probable But Graphite is one API, and may not suit all developers. 20

Reuse of modules should be promoted by standard- izing components Care should be taken to allow multiple approaches on handling RDF, and a standardization of modules would be preferable in this regard, as it may speed development amongst several approaches. Design Patterns can help structure and communication To this regard, communicating the internal structure of modules is important, and Design Patterns may help. Some considerations need to be taken when com- bined with JavaScript But design patterns must be mod- ified somewhat in JS, as there are some features lacking (e.g. classes and interfaces). TDD are tremendously useful when developing large frameworks Nuff said. 21

16 Related Work

Not much related academic work No findings of the combination JS and SW Some open-source work 113 findings of libraries supposedly related to Se- mantic Web Only 54 were available (either dead links, not open- source, or easily available) Of these, only 42 were actually related to SW Of these, 22 were JavaScript-related Of these, 11 were interesting considering reusability 22