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 of 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 off. 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 of 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 object. 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 objects, 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 other 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
Recommend
More recommend
