Make your app smarter with a Domain Ontology
Every successful new business proposition sprouts from a deep understanding of the specifics of the target audience.
Translated to an App or SaaS service you want to launch: thorough knowledge of what makes potential users of your service tick is essential for success. This is why investing time in the definition of Personas, Agile User Stories and solid, User-Centric UX Design is so important.
Human intelligence
Now, all this is of course part of a creative process, led by intelligent people, applying their knowledge and experience to design an optimal solution. As an end-user, you can tell pretty quickly whether an app ticks the boxes: even if you aren’t able to describe the technicalities, you will see the difference between an app that simply works and one that, well, sucks.
But intelligence shouldn’t stop there, and I’m not talking about apps that show you more ‘relevant’ ads the more they know about you...
More and more apps intelligently react to usage patterns and by doing so, create an even better user experience. For instance, Spotify and Netflix both adapt their suggestions based on your behavior, and get better at it the longer you use them. They use a combination of Big Data Analytics and Deep Learning, and both are front runners in those extremely trendy areas of software development.
A little less trendy, but equally important, is the injection of human knowledge into software, and I’m not talking about premeditated conditional code programming, which makes up a big chunk of every apps code base. Instead, I’m talking about the use of an elaborate structure of interrelated concepts, which is called an Ontology (also known as a Knowledge Graph).
“[…] an ontology encompasses a representation, formal naming, and definition of the categories, properties, and relations of the concepts, data, and entities that substantiate one, many, or all domains.” — Wikipedia
Simply think of an Ontology as formalized and computer-readable knowledge
I will not dive into the scientific discourse about what distinguishes ontologies from thesauruses and taxonomies. There’s plenty of literature about that. Suffice to say here that in ontologies, concepts/terms can be related in all kinds of ways, because they can, in real life.
This image immediately conveys a lot of information about how ontologies work: concepts have multiple types of relations to other concepts, each relation type is described as a predicate.
Learning curve
Domain Ontologies try to capture as much as possible human knowledge about a given domain into a format that computer software can then read and leverage, in all kinds of ways.
Building up a domain ontology can look like a complex endeavor at first. There is a steep learning curve to really understand how they’re implemented, but there have been a number of efforts that have advanced the thinking quite a lot. The Semantic Web is one of the more prominent ones.
With well documented formats like RDF and OWL, and a wealth of sophisticated tooling and libraries in many programming languages, developers no longer have an excuse.
What can ontologies do for software?
Like I said, ontologies are meant for capturing and structuring knowledge, and making it machine-readable.
Query enrichment
Consider a marketplace SaaS app, where supply and demand come together. When someone searches for stuff, an ontology can make sure synonyms, acronyms, spelling variants and related terms are taken into account to do the matching, for instance by doing query enrichment.
Suggestion Engine
Take a shopping site. When putting articles into the shopping cart, the suggestion engine, which many e-commerce sites have, will suggest what others bought along with the item just added:
The image speaks for itself. With a good product ontology, this shop would probably come up with more relevant suggestions. It would probably filter out both items that classify as alternatives for the item selected and items that are completely unrelated.
Classification
Let’s assume we’re building a job site, and we implement a search feature.
Apart from the fact that one should be careful in querying “Job Title” and “Job Description” as if they were equals (!), it would really help if the application had a clue about what it actually tries to match.
Every human involved in IT immediately sees that Developer, Agile Coach and DevOps roles should not be presented to someone looking for Chief Technology Officer roles.
Building up a knowledge graph of job titles and related terms might be a giant undertaking, but it will certainly pay off. Also, your domain ontology might be a lot smaller depending on your niche, and if you’re working at the scale of a global career site, you probably have the resources to do your homework. And by the way, there are specialists, like Sovren, Textkernel and RChilli who can assist.
Conclusion
Although it is quite obvious that big players like Google and Microsoft use knowledge graphs for search these days, many others, including some pretty big ones, lack a good ‘understanding’ of their domain. In some cases, their software makes up for it by excelling in other areas, in others, the resulting user experience is so bad that I wonder why people still use them.
Thinking about structuring your domain knowledge into an ontology or knowledge graph, in order to make your software more intelligent, should be a lot more obvious than it is today.
