Notis

Notarial info smart tool

Notis

Authors:

Insuratelu Madalina

Macariu Camelia

Abstract

Notis, short for Notarial Info Smart Tool, is an application with the purpose of providing support for locating offices and services for public notary entities. This Web system will use the official data regarding public notary entities and authorized translators and interpreters which will locate offices according to user preferences, geographical places, fees, restrictions, schedules and so on. This website uses the power of semantic web to model translators and notaries knowlege.

Features

Some big features that our website will provide are the following:

Architecture

The architecture and the main goals of the application will be presented in this section. The architecture has two main components: the Front-End component, which will provide an user-friendly interface for the client and the Back-End component, which will handle the business logic and data storage of the application.

UML Architecture Diagram (figure 1)

We considered that the best approach for this system would be the layered architecture pattern. Each layer of the architecture has a specific role and responsibility within the application. The presentation layer is responsible for handling all user interface and browser communication logic, whereas business layer is responsible for executing specific business rules associated with the request.
One of the reasons we choose the layered architecture pattern is the separation of concerns among components feature. The components within a specific layer deal only with logic that pertains to that layer. This type of component classification makes it easy to build effective roles and responsibility models into our architecture, and also makes it easy to develop, test, govern, and maintain the application using this architecture pattern due to well-defined component interfaces and limited component scope.

Class Diagram

We created a class diagram for the application which describes the structure of the system (with the classes), their attributes and methods, and the relationship among objects.

UML Class Diagram (figure 2)

Back-End Component

The back-end application will be written in C# using .NET Core 3.0. Also, for working with RDF triple stores we will use dotNetRDF. It's a complete library for parsing, managing, querying and writing RDF.
We will use ASP.NET Web API, to implement a RESTful Web API. This has great flexibility in terms of separating the service layer from the controllers allowing you to use several of the available Dependency Injection frameworks fairly easy. For the database we'll be using the GraphDB, which is a graph database. The reasons for using these technologies and libraries are:

Also, for the database we will use SPARQL - which is is a RDF query language, a semantic query language for databases, able to retrieve and manipulate data stored in Resource Description Framework (RDF) format. SPARQL allows users to write queries against what can loosely be called "key-value" data or, more specifically, data that follow the RDF specification of the W3C. Thus, the entire database is a set of "subject-predicate-object" triples. This is analogous to some NoSQL databases' usage of the term "document-key-value", such as MongoDB. Thus, SPARQL provides a full set of analytic query operations such as JOIN, SORT, AGGREGATE for data whose schema is intrinsically part of the data rather than requiring a separate schema definition. However, schema information (the ontology) is often provided externally, to allow joining of different datasets unambiguously. In addition, SPARQL provides specific graph traversal syntax for data that can be thought of as a graph.
One way to interact with the API is with the Swagger specifications from: NotisAPi. Also, for the services data we discovered some legal papers and procedures used in the public notary domain and can be found at legal papers.

Front-End Component

For the user experience of the Front-End component, we'll be using Material UI, which has good looking components, the design will be consistent, and considering the development part, we can say that is very easy to use and the documentation is very good.
In the following images, we have some sketches of the application. In the first image, we can see the Welcome page with some filters, that the user needs to fill in order to display the map(image 2), which is the first view that the user will see when enters the website. After completing the filters, a map will appear, with the marked places returned from the response. On hover, the user will see the schedule of the notary/translator and some other important informations. Clicking on the mark it will open a drawer/popup with some more informations about the notary, such as: reviews, the prices, entire schedule and so on. Also, the user can leave a review (ratings from one to five) after his experience with that notary/translator.

Image 1

Image 2

The technologies that we'll use for the Front-End component are:

React and Redux Architecture

Also, we'll be using TypeScript over these frameworks, because it has the potential to bring type safety for reducers, state, action creators, and UI components, as well as easy refactoring of typed code. So, Typescript is in its strongest position for making our application more stable, readable and manageable.

Data access layer

RDF consists of triples. These triples are based on an Entity Attribute Value (EAV) model, in which the subject is the entity, the predicate is the attribute, and the object is the value. Each triple has a unique identifier known as the Uniform Resource Identifier, or URI. URI’s look like web page addresses. The parts of a triple, the subject, predicate, and object, represent links in a graph. Multiple triples link together to form an RDF model. The graph below describes the realtion between the client and the service via RDF schema. We can easily identify triples such as "Translator worksIn Translations", and we also found out that the Address has Longitude.

RDF Diagram (figure 3)

Service (figure 4)

Type of service (figure 5)

Address (figure 6)

Use case

The figure below shows a use case diagram for our web system, with some possible interactions between the Actor(user) and the system.

Use case Diagram (figure 7)

Activity Diagram

The activity diagram describes the dynamic aspects of the system, representing the flow from one activity to another.

Activity Diagram (figure 8)

Project progress

Based on our initial goal, we implemented almost all the functionalities. The project still has its main purpose to display all the offices for the type of service wanted and also based on some filters(ex: price, schedule, city).

The hierarcy of classes:

As a final implemented APIs we have endpoints to get all the notaries, to get all the translators, to get services per office and to make a request based on some filters.

The ontology

The ontology consist of the following classes: notis:service, which can be notis:notary or notis:translation, notis:notary-type-of-service, notis:translation-type-of-service, notis:necessary-papers. To create the ontology, we used Protege to create classes and some individuals. Based on xml files with some details about the notaries and translators, we created a python script to convert data to RDF type which we added at the ontology.

GraphDb

GraphDb

We used sparql to interogate the graph.

SPARQL Query

We used Place schema.org concept to display city, latitude and longitude. On frontend we used them to create markers on a GoogleMap. When you click on one of them, more details are shown.

Protege

Protege

Conclusions

This web system can be a valuable tool for anyone who is in search of notary offices and services, based on the user's preferences, geographical places and the others mentioned above. It also provides an interactive user interface, with material UI components and simple steps to configure the needed offices or translators.
To conclude the technical paper, Notis takes advantage of modern technologies mentioned above ( i.e : OWL ) in order to create a smart web application.

References