Search
  • Gábor Csepregi

Chapter 5 - Turning the Semantic Way

Fifteen years ago I got introduced to the world of the semantic web. Without getting into the details - there are lots of great resources around the web on the subject - let me just show you how it can improve your planning and estimation issues.


Semantic Web Basics


Let's see a few definitions first. A semantic statement is a triplet of subject, predicate and object and can be represented as:



These statements connect into a nice directed graph if we expand on them:



If we go further, we can use inferencing engines. It means we can create rules like the following, and use these to identify information, that is not directly present in the graph. The following statements tell us, that if a resource 'X' and a resource 'Z' both have a shape 'Y', then we're safe to deduct that 'X' is similar to 'Z'.



Which leads us to an extended version of the graph, where some statements are added by the inferencing engine. We can use this feature for solving different kinds of problems we face. We can use this to identify hidden information in our graph, like:



The semantics of an application


How does this help us? Great question. Let's take a look at how we can represent the application we just created in the previous posts. We can nicely separate the different semantic layers like having the application at the top, the data structures on the second line, some abstract groups on the third, and the actual code representations on the fourth.



When we were discussing the requirements of the second iteration, we spotted some duplications. We agreed that this is a POC so we don't need to normalize yet. To be honest, I had another reason too. There is another pattern usually hidden from sight until you look from the right angle.


We debated on whether to merge or not to merge tasks and projects on the code level. The main reason not to do so is that they represent semantically different concepts. We can have similar discussions on other things as we will expand the codebase. What we haven't discussed though are the abstract elements of the code we create.


To make it clear, let's look at the following image where I have highlighted the four key elements of a data-driven application:



What can we observe if we forgot about the labels and just concentrate on the coloured nodes? It says that every application handles some number of data structures through mechanisms of 'create', 'list', 'update'. Yes, we are missing some parts like details, but we can imagine that these will require some UI and Function components and will connect to some DB objects.


We defined the difference between tasks and projects. But there are some other things repeated throughout the code without recognizing it. Take a look at the Task model for example. Can you notice something strange? We learnt that we create a model interface on the UI side, we create the model class on the function side and create the table in the database.


We have three different definitions of the same concept! Why?


Also, though we generously skipped the validation on the server-side and haven't implemented too complicated constraints on the database, we have some form of validation in all three places. Why?


This will generate extra complexity. I guess most of you would have agreed with me if the tasks and projects share the same properties then they should be represented with a class hierarchy. Just to remove duplication and make the code maintainable.


Why are you duplicating the model and the validation then? Is there no way to simplify things on this level? I know the simple answer is because you are targeting different frameworks. But is this just an excuse?


Are there other features that are repeated throughout the code? I can assure you that there are.


For fifteen years, since I met the semantic web I studied every project I was part of and I can tell you that every project is made of four simple shards behind the scenes:


  1. Data Structures

  2. Forms

  3. Create: Data Collection

  4. Update: Data Collection

  5. Details: Data Presentation

  6. Lists: Data Presentation

  7. Flows: Data Flow

No matter what application you take you will find only these four elements under the hood and it's present in every layer. How gets manifested is what the actual code represents. But yes, even the API in our example has features that are forms and lists.


Next time we will dive deeper into the 4Shards concept to enable anyone to identify them in their applications. Until then try to analyze your current project. How does the above apply to your code?

13 views

©2020 by Gabor's blog. Proudly created with Wix.com