ELA - technical report

1 Project Overview

1.1 Goals

The ELA (Esoteric Language Explorer) application wants to give to anyone who thinks that has a uncommon way of thinking a challenge by providing all the possible information about esoteric programming languages.

Our progress can be followed here, on the blog: ELA blog


1.2 Structure

The application consists of a 1-page web interface and a public SPARQL endpoint. The web page is designed for the human users, and the API can be accessed by other applications.

The main pages is for completing a form where the user can decide what criteria should be fulfilled by an esoteric language. For example, the user wants to know about difficult esoteric languages, or esoteric languages that are based on Brainfuck. The list of criteria is dynamic, this means that the user will be able to select/unselect items from the criteria list that is sent to the application.

The main page also has the option to generate random data to be sent to be web application in order to receive random languages.

For a received language, the interface will display in the first phase a summary of the language, like the name. The user will have access to extend the information displayed in the interface.

The SPARQL component represents a public endpoint that can be accessed by anyone. This endpoints provides two functionalitites:

  1. Retrieve a list of esoteric languages that meet all the criteria/ requirements
  2. Retrieve information for a specific esoteric language

A generic view of the application is as followed:

c4_first_level


2 Projet Implementation

2.1 ELA-UI

The web pages will be implemented using HTML5, CSS and vanilla Javascripts.

The page will be divided in 2 section:

The below section will represent a list of the following items:

The requests called by the Javascript to the application server will be done using the Fetch API.

2.1.1 Criteria page

The page for getting a suggested esoteric language on criteria will have a static desgin. The criteria will be represented by fields in a form with predefined values. The user can select a value, meaning that they want the condition to be taken into account when retrieving languages, or not.

2.1.3 Handling responses

Once the response is received from the server, if the HTTP reponse code is success (200), then the page will render a new HTML element that will contain information about the retrieved esoteric languages.

There can also be the scenarion when the application cannot find an esoteric language and an HTTP error code (404) is returned. In this scenarion, the UI will render an empty HTML object.

A visual flow of the application where the UI intervine can be viewed in the following diagram:

c4_third_level_ui

The following image shows the layout of the page:

2.2 ELA-SPARQL

The ELA-SPARQL will represents the main endpoint used by the whole application. This endpoint will be public to the world, this means that it can also be accessed by other means than using the web pages.

2.2.1 Tools

The following technologies are going to be used in the development of the web application:

  • Java - as the main programming language
  • Springboot - as the framwork used in generating the template for the endpoint and further development
  • Maven - as the tool to manage the dependencies of the project
  • Apache Jena - as the framework for extracting information from the ontology
  • Tomcat - as the web application server host

2.2.2 Description

The web application will provide two endpoints:

  • Retrieve a set of summary about esoteric languages based on given criteria
  • Retrieve a specific esoteric language

Note: By esoteric language, in the above list, it was referred to all linked information. To see what information is related to such a resource, see Ontology

2.2.2.1 Criteria language

This endpoint will receive an object will requested criteria to be processed. Using the selected criteria, the web application will build the SPARQL query using the Jena framework to execute it on the ontology. Here are 3 scenarios that must to be handled accordingly:

  1. The query returns at least one language: the return code is 200 and the list of the languages is returned with the number of found languages
  2. The query returns no language: the call returns the HTTP return code 404 - Not Found
  3. For any error encountered by the server: the call returns the HTTP return code 500 - Server Error

More tehnical details about the API can be consulted here: Get languages by criteria

2.2.2.2 Esoteric language by name

This API uses the GET method in order to return the required language. By using the REST approach, someone will need the name of the language in order to retrieve all the date.

The name of the language is extracted from the IRI, which is present in the body of the languages retrieved by the Criteria Endpoint API.

More tehnical details are presented here: Get languages by name

The return situations are similarly with Criteria Endpoint, with the exception that if no language is found, the criteria is re-generated and the query is executed again.

A visualisation of how the API's works together can be seen in the following image:

2.2.3 API Specification

At the following link it is presented the OpenAPI specification of the SPARQL endpoint: API documentation

2.3 ELA-Ontology

The ontology will be created as a base for the languages, their properties, and related concepts, such as compilers, editors, authors, program examples etc. These will be added as classes into the ontology with the aforementioned specific properties and relations.

Below is an example of an RDF graph for one of the esoteric languages:

Brainfuck RDF graph

2.3.1 Tools

To develop the ontology, the following tools were used:

  • Protégé - open source ontology editor and a knowledge management system from Standford

    Home page

In this section are presented images from the ontology. The images represents a structure of the implemented classes and what languages were added to it.

3 Use cases

3.1 Human use case

3.2 Robot use case

4 Linked data principles

In this section, it is motivated why out system follows the linked data principles.

A definition will be:

Every information provided about a concept will come along with specific metadata from the ontology and the ontology will have references for the properties to other relevant ontologies.
Further details will be added as the solution will be developed.

The four rules:
1. Use URIs as names for things
2. Use HTTP URIs so that people can look up those names.
3. When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)
4. Include links to other URIs. so that they can discover more things.

Our model follows those principles because:

5 Resources

Resources used in the processes of research, development and documentation:

  1. WADe
  2. Protege tutorial
  3. Jena
  4. SpringBoot initializer
  5. SPARQL introduction
  6. Introduction to Javascript