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:
- Discover where and when to find notarized documents, such as acknowledgments, oaths/affirmations, copy certification, signature witnessing and others legal procedures in one place.
- Accuracy of finding the right notarial office/translator with the desired filters.
- Support for foreign citizens.
- Map representation of the user's preferences.
- OpenAPI specification for developers.
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.
- Presentation layer - This is the top most level of the application. The presentation layer displays information related to such services as viewing/searching some filters, map visualization and displaying informations related to offices and translators. It communicates with other layers by which it puts out the results to the browser/client tier and all other tiers in the network. In simple terms, it is a layer which users can access directly.
- Business layer - The business layer is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing. This layer coordinates the application, processes commands, makes logical decisions and evaluations and it also moves and process the data between the two surrounding layers.
- Persistence layer - Usually, in this layer, the information is stored and retrieved from a database or file system. However, we will use ontologies, which express relationships and enable users to link multiple concepts to other concepts in a variety of ways. Ontologies enable database interoperability, cross-database search and smooth knowledge management. The processed information is then passed back to business logic and then back to the user.
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:
- .NET Core 3.0: brings plenty of benefits for desktop-based
applications. First, it will improve the overall app performances and bring more speed to runtime updates.
Second, it is an open-source platform that offers innovative BCL and APIs without resulting in compatibility
issues. Third, there are other significant benefits for .NET application development that include:
- Design that allows both, application-local and machine-global deployment of apps.
- Architected for testability.
- Integration of modern, client-side frameworks and development workflows.
- Built-in dependency injection.
- dotNetRDF: is a powerful and flexible API for working with RDF and SPARQL in .NET environments. Also, it contains the core libraries. This includes support for reading and writing RDF; and for managing and querying RDF data in-memory.
- GraphDB: GraphDB allows you to link diverse data, index it
for semantic search and enrich it via text analysis to build big knowledge graphs.
Some advantages of using this database are:
- Object-Oriented Thinking - explicit semantics for each query. There are no hidden assumptions such as relational SQL, where you have to know how the tables in the FROM clause will implictilty form cartesian products.
- Performance - superior performance for querying related data, big or small.
- Update Data in Real-Time and Support Queries Simultaneously - Graph databases can perform real-time updates on big data while supporting queries at the same time, which will be very useful in our API requests.
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: used for building the user interface, as it's
optimal for fetching
rapidly changing data that needs to be recorded. Some benefits of using React in our application are:
- It facilitates the overall process of writing components
- It boosts productivity and facilitates further maintenance
- It ensures faster rendering
- It guarantees stable code
- It is SEO friendly
- Redux used for managing the application state. Here are
some several benefits of using it:
- Predictable state updates make it easier to understand how the data flow works in the application
- The use of "pure" reducer functions makes logic easier to test, and enables useful features like "time-travel debugging".
- Centralizing the state makes it easier to implement things like logging changes to the data, or persisting data between page refreshes
React and Redux Architecture
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
SPARQL Query
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
- .NET Core 3.0 - free and open-source software framework developed by Microsoft.
- React - open-source JavaScript library for building user interfaces developed by Facebook.
- Redux - open-source JavaScript library for managing application state.
- GraphDB - semantic graph database.
- dotNetRDF - an open source .NET Library for RDF.