Turtle- The language of Knowledge

Image courtesy- GFCLearnFree.org

In practice

We will dive directly into the heart of the topic – “In practice”. We assume the reader to have fair enough exposure to the topics of RDF and Triples and thereby to Turtle. In case you have stumbled upon this page without prior knowledge of these topics, we will entertain you with one liner of background on this topic –

RDF stands for Resource Description Framework which is a language to model metadata about data.

Triples is the basic structural unit of a language – Subject > Predicate > Object. i.e., a subject performs an action (described by predicate) on an object.

Turtle is minimalist syntax for representing the triples in textual format.

Using the definition above we are sure you have assimilated a vague relationship between the triple and turtle. However, the essence of this knowledge is that metadata is best presented as a directed graph of subject > predicate > object which is at the core of RDF and thereby connecting all the three core concepts. Curious minds can separately dive into the ocean of topic called RDF and Triples.

We return back to turtle and its practical application that we found very interesting. As spelled out in the title we position the metadata as knowledge. By that definition we found an easy way to trace requirements written in plain language to program written in a specific language. That was a peek into the road ahead for you.

Software requirements

Written in plain English it adorns multiple formats e.g., user story, use case, section indexed document etc. To illustrate our case let us take simple English statement that narrates a requirement and apply the semantics to it.

Let us assume we are in 2005 and have ambition to build a microblogging application. The key requirement for such ambition will be –

User will create a blog entry that is no larger than 140 words.

Let us keep this as reference requirement for the rest of the article. You could have written the requirement as

As a User of the platform, I want to create a blog entry in 140 words So that I could express my mind quickly and concisely.

There are already well-defined segments to this style of writing – i.e., subject identified by “As a” and the predicate and object are mixed within “I want to” with additional information of “So that”.Thus, expressing this in turtle will be easier than the previous one. Retaining the previous one we move into the actual work of defining knowledge in Turtle specification.

The pressing question in your mind could be why are we complicating the process which is currently an art of writing? Our ambition in the world of software development is to have traceability from right from thoughts that emerge in human mind to the software that is in the hands of users. This traceability is currently established part by tools in SDLC lifecycles and part by humans who interpret the creative copy written by humans as requirements.

Through, a structure representation of knowledge we could take a step closer to having the traceability built in right from the thought which are expressed as sentences and could be interpreted by machines as much as humans.

Turtle specification

Turtle is also known in long form Terse RDF Triple Language. This syntax was developed to write syntactically correct triples in textual manner instead of XML format which is easier to parse by machine instead of reading by a non-technical person.

One cannot start talking about metadata without referring to scoping URL’s. One of the simplest ways we settled in our mind about this URL’s is – URL is used to scope a concept (subject / predicate / object). They are very much like namespace in any programming language.

URL’s or more precisely in the language of RDF they are URI’s and are represented within angular brackets “< …  >”. These URI’s are to be used resolve the subject, predicate and object. Like URL, these URI’s can be long e.g.

https://example.org/user

Writing this every time concept of user is referred is not practical and hinders readability. Thus, we use another concept of turtle i.e., prefix. A prefix is a short-hand notation for a URI. A prefix is always bound to a URI and cannot be used for any different URI. The URI for user with a prefix notation will look like this –

@prefix usr:  http://example.org/user .

Notice the period “ . “ character at the end of the example above. That character is required to indicate that the line above is either a directive (which it is) or a triple. This is equivalent to the semi-colon character “ ; “ used in programming languages like Java and C#.

Interestingly the character “ ; “ is used in turtle as well but for a different purpose. It is used for separating multiple predicate and object combination applied to a subject. Don’t worry if you are lost in the previous sentence. Please continue moving ahead you can circle back to this concept once we lay down an example.

Returning our focus to the software requirement we could attempt following statements –

 

@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix mb:  <http://example.org/micro-blogging> .

@prefix op: <http://example.org/binary-operations> .

mb:user

   mb:creates     mb:blogEntry .

mb:blogEntry mb:characters [

       op:count [

               op:lessThan 140^^rdf:integer]

       ].

 

 

There are two short statements. The first says user can create blog entry and the next statement states that blog entry should have character count lesser than 140. It is essentially the same information but what makes this more traceable through the life cycle of SDLC is the schema which we are going to define for this vocabulary.

This is something which was missing in the vanilla statement written in English. We took for granted the reader of the requirement understands the meaning of the words (i.e., vocabulary) like user, blog entry, 140, characters etc.

In RDF when we define knowledge, we make that explicit. The following is a schema accompanied for the above requirement

 

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix mb:  <http://example.org/micro-blogging#> .

@prefix op: <http://example.org/binary-operations#> .

 

mb:user a rdfs:Class .

mb:blogEntry a rdfs:Class .

op:lessThan a rdfs:Class.

 

 

mb:creates a rdfs:Property;

   rdfs:domain mb:user;

   rdfs:range mb:blogEntry .

 

mb:characters a rdfs:Property;

   rdfs:domain mb:blogEntry.

 

op:count a rdfs:Property;

   rdfs:domain mb:characters;

   rdfs:range op:lessThan.

 

This schema can be merged with the turtle file which we can save as requirements.ttl file –

 

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix mb:  <http://example.org/micro-blogging#> .

@prefix op: <http://example.org/binary-operations#> .

 

mb:user

   mb:creates     mb:blogEntry .

mb:blogEntry mb:characters [

       op:count [

               op:lessThan 140^^rdf:integer]

       ].

 

mb:user a rdfs:Class .

mb:blogEntry a rdfs:Class .

op:lessThan a rdfs:Class.

 

 

mb:creates a rdfs:Property;

   rdfs:domain mb:user;

   rdfs:range mb:blogEntry .

 

mb:characters a rdfs:Property;

   rdfs:domain mb:blogEntry.

 

op:count a rdfs:Property;

   rdfs:domain mb:characters;

   rdfs:range op:lessThan.

 

This is just getting one statement converted to knowledge in the next dispatch we will address the topic of how do we scale up to real life system’s requirement specification.