Silver Oliver

Data Graphs [https://datagraphsa.com] is a product we have designed to lower the
barrier of entry for organizations to launch a knowledge graph platform. We have
shortened the time to launch from months down to hours (in a recent event, we
built a Netflix knowledge graph from scratch with Data Graphs in just 12
minutes).

In Gartner's recent report
[https://www.gartner.com/en/articles/the-4-trends-that-prevail-on-the-gartner-hype-cycle-for-ai-2021] 
on the significance of knowledge graphs, they listed some obstacles that many
companies encounter when trying to implement and maintain them successfully. In
this piece, we'll be explaining how our new knowledge graph product, Data Graphs
handles each of these obstacles.

Gartner's Obstacle 1:

Data Graphs Solution:

Lowering the barrier of entry to knowledge graphs will make it easier for
businesses to see value quickly, and therefore pushing them higher up the
priority list. Specifically, this means speeding up the ability to do proof of
concepts, and do simple but informative demos that allow organizations to
realise early value at low cost and low risk. 

Gartner's Obstacle 2:

Data Graphs Solution:

Data Graphs is an out-of-the-box product. All the engineering and system
integration expertise, that Gartner points out as an obstacle to most companies,
is already taken care of. Data Language has already addressed the main
engineering challenge and initial setup within the product, and engineered the
knowledge graph capability. Integrating with Data Graphs is light, easy, and
based on common web standards and well constructed, robust APIs which saves you
having to wrestle with complicated graph data standards.

Gartner's Obstacle 3:

Data Graphs Solution:

This is a slightly more nuanced obstacle that in summary deals with the fact
that there are many different types of knowledge graph. Any one product,
including Data Graphs, is not a one-size-fits-all solution so companies must be
careful to choose the right knowledge graph for their use-case. 

Data Graphs, for example, is not trying to be an RDF Triple Store, which will
provide the infrastructure for a great knowledge graph for some use-cases, but
less suitable for others. 

In Data Graphs we’ve distilled-down what we’ve seen as the most useful
attributes of a knowledge graph and vastly simplified their use for businesses
that don’t want/don’t have the resources to engineer a full RDF triple store or
a property-label  graph solution.

Over our 10-15 years experience in implementing knowledge graph solutions in the
enterprise, we find that a large percentage of solutions don’t need RDF based
platforms. Instead, we have tried to create the perfect cocktail of enough
semantics to deal with the use cases that most businesses have, but at the same
time keeping it simple enough so as not to get bogged down in complexities that
the majority will never need. Data Graphs does provide RDF interoperability
through its JSON-LD APIs, and Data Graphs does not preclude you from using an
enterprise-scale graph database too. Data Graphs can also be used as a graph
entity editing tool, that can be integrated with an RDF or property graph
database, and this is a soluiton pattern used by some of our customers. 

Gartner's Obstacle 4:

Data Graphs Solution:

To tackle this obstacle we have to go back to the main lesson we always try to
impress on our knowledge graph clients: preparation is key. You have to
understand your data and design it well, solid domain modelling is always the
imperative first step. We often see projects get distracted by the technology
when in reality some of the most important work when creating a knowledge graph
is the preparation, making sure your data is described, structured and
understood clearly. Desgining a quality domain model/ontology for your own
use-cases is critical to unlock the value in sharing linked-data. Data Graphs
allows you to construct your domain model and visulize it within the tool, and
also allows you to export the domain model as an RDF/OWL ontology. Data Graphs
uses linked-data at its heart, to enable interoperability through JSON-LD and
JSON-LD APIs.

Find out more about Data Graphs and our knowledge graph experience below.

Data Graphs [https://datagraphs.com/] | Knowledge Graph Engineering
[https://datalanguage.com/knowledge-graph-engineering]

A knowledge graph is a collation of information and data typically within the domain of your business context. The information is stored in a database, often a graph database such that it can be queried, maintained, and interacted with by humans or machines. We have exceptional experience in the design, implementation and deployment of knowledge graphs. We have been working with graph databases since our inception and have delivered knowledge graphs solutions for global organisations.

We have exceptional experience in the design and implementation of knowledge graphs and have delivered knowledge graphs solutions for global organisations.

Knowledge Graphs - our Work, Features, News and Updates

Knowledge Graphs

How Data Graphs addresses Gartner’s obstacles to Knowledge Graphs

An introductory guide to tagging: part 4

In the previous post I talked about the challenges of tagging
[https://datalanguage.com/features/why-tagging-tends-to-be-bad-on-websites].
Here I will start to look at some approaches that can help.

One technique that I will always come back to is domain-driven design (DDD). The
principles behind domain-driven design go back to Eric Evans and his book 
Domain-Driven Design: Tackling Complexity in the Heart of Software
[https://www.oreilly.com/library/view/domain-driven-design-tackling/0321125215/]
.  The starting point for domain-driven design has similarities to domain
analysis in Library Science. 

In domain analysis Albrechtsen and Hjørland make the case for domain knowledge
being given greater importance in the role it plays in Information Science.

> Many approaches to information science and Knowledge Organisation may be
understood as attempts to pass over subject knowledge (or at least not make
subject knowledge explicit in their methodologies). Domain analysis, on the
other hand, makes subject knowledge an explicit and important part of the
methodologies of information science and knowledge organization.
Towards a new horizon in Information Science
[https://www.researchgate.net/publication/220434297_Toward_a_New_Horizon_in_Information_Science_Domain-Analysis]

DDD, though aimed at software developers, comes to a similar conclusion.  This
is that many software projects fail due to passing over subject knowledge and
not making understanding the domain a central part of the process. The problem
being that everyone on a team goes away and builds according to their private
view of the domain. Then when it comes to putting the design pieces together
they don't fit.

DDD ensures a team spend time together at the outset of a project to align their
understanding.  This is before they design or build anything.  The success of
this approach is that it supplements existing expertise with a strong and shared
knowledge of the domain.

The aligning of language during these sessions is crucial.  Participants talk to
each other, draw for each other and do everything they can to understand where
differences of understanding or terminology are lurking. 

Diagrams and word documents have the habit of hiding our differences as opposed
to surfacing them. True shared understanding is something that can only really
be achieved by talking about the domain from as many angles as possible. 

It is as simple as that. 

When starting on a project to design and build anything, I would suggest the
following principles:

 * Recognise that caring about and understanding the subject domain is
   important.
 * Domain experts are a critical part of the team.
 * Everyone will have different views, preconceptions, simplifications they
   bring to a domain and this manifests itself in the language they use.
 * Learning where these differences are will be expensive if learnt through
   writing code,  building a taxonomy or designing a user interface. Better to
   learn this cheaply in front of a whiteboard.
 * The best way to surface these differences and align language is in talking, a
   lot, together as a team.
 * Simple domain model diagrams are a great way to share and challenge
   understanding of the domain.
   

The main outcome of all this is the shared language during conversations and in
design decisions.  There will likely also be some domain model diagrams.  An
example of this is the classic Polar Bear presentation
[https://www.slideshare.net/reduxd/beyond-the-polar-bear/22-stadiumbr_competitionbr_teambr_matchbr_roundbr] 
by Mike Atherton of a sports website. 


Credit Mike Atherton [https://twitter.com/mikeatherton] and Paul Rissen
[https://twitter.com/r4isstatic] (model design)This represents the project
team's shared understanding of the domain and consensus regarding how to talk
about it. In this model are all the types of tags we might need. As we
understand more about the website's goals and the plan for which pages are to be
built first we can ensure tagging will support them.

For example we might decide we want to capture tags for teams and matches. Why
not stadiums? If we tag with a match we already have the stadium from the model.
 So we can reduce the burden on taggers to that which is absolutely necessary.
We can also see we get competition round from the model as well. Each tag is
part of a larger model and we adjust our tagging strategy based on our
understanding of the model.

Why not tag with player?  Analysis may show that there is little value in
including players. For example we have seen little use of player pages in other
parts of the site. Then there is no justification in tagging them. Some might
argue that we need to preempt any possible use of the system in the future, so
we should tag players even though this doesn't add value now.  In my experience
this is where we get into trouble.  Keeping a tight focus on the value and the
tagging needed to create that value is crucial. The domain model will help us
map out possibilities but an understanding of our goals helps up pick the right
path through that map.

To continue this example, if we identify that tagging with teams and matches
will  support the objectives of the site then we have an idea of what good looks
like. This informs how we develop the tools, vocabularies and guidelines to
support this goal. An understanding of the domain, the websites goals and its
evolving scope have defined how we design our tagging.

That is a simple example but there are a whole range of more complex case
studies to support this from Wellcome
[https://stacks.wellcomecollection.org/building-a-free-and-unrestricted-digital-museum-and-library-6cdf28784068] 
, BBC [https://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml] 
and Parliament
[https://pds.blog.parliament.uk/2016/09/09/modelling-parliaments/].

I often get asked if this goes against user-centred design philosophies? Yes and
no. 

When working at its best DDD is complementary and works hand in hand with user
centred approaches.  At its core is the idea that the domain as a key organising
principle.  This can still sit within a user-first approach.  However, on the
whole I feel a team aligning its understanding and language within a domain
before engaging with users can only be a good thing.

In summary, one part of the solution to better tagging is to design with a
collective understanding of your systems domain. 

Part 1: Why the web turned its back on the librarians. And why we need them
back.
[https://datalanguage.com/features/why-the-web-turned-its-back-on-the-librarians]

Part 2: The importance of tagging when publishing on the web
[https://datalanguage.com/features/the-importance-of-tagging-when-publishing-to-the-web]

Part 3: Why good subject tagging is hard
[https://datalanguage.com/features/why-tagging-tends-to-be-bad-on-websites]

We use Domain-Driven Design (DDD) as our fundamental foundation for most projects. The skilled facilitation of domain modelling workshops is used to reach a domain model. This helps teams understand core business entities, relationships, and to target areas of crucial strategic value and corresponding pain points.

Domain-Driven Design is a collaborative process that leads to a Domain Model – a point of reference to inform all strategic data and technology decisions.

Domain-driven Design (DDD) - Creating the map of your business

Domain-driven Design

How to use domain modeling to improve subject tagging

An introductory guide to tagging: Part 3

It has been my experience that many organisations struggle with high quality
tagging. In this post I am going to reflect on some of the causes of this
problem. 

As discussed in earlier posts, the value of tagging is often not properly
understood
[https://datalanguage.com/features/the-importance-of-tagging-when-publishing-to-the-web]
.  Most often it is considered to be there to support keyword search alone.
 Even the taggers themselves are not aware of how the tags are going to be used,
or why they need to be of good quality to add value.

The next issue is around the guidelines given to taggers.  Typically they are
extremely poor, and go along the lines of “tag what the content is about”.  This
question of “what is it about?” is harder than it seems at first glance and not
very helpful. It usually results in a different answer from each tagger.  To get
good quality tagging you need to ask good quality questions.

As the tagging quality goes down, the ability to drive useful features from the
tags also diminishes. This in turn does nothing to reassure people of the
importance of good tags and you end up in a vicious cycle of ever decreasing
quality and value. 

What good guidance on tagging looks like should be the point where Library
Science can come to the rescue.  But the challenge of how to identify the
subject of a work is a surprisingly under represented topic in Library Science
literature. 

Back in the the 1970s, Hutchins observed:

> THE LITERATURE OF INDEXING AND CLASSIFICATION contains remarkably little
discussion of the processes of indexing and classifying...we find very little
about how indexers and classifiers decide what the subject of a document is, how
they decide what it is 'about'.
The concept of 'aboutness' in subject indexing:
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.584.8116&rep=rep1&type=pdf] 
 W. J. Hutchins

Little has changed.  Taggers are often told to imagine "how might the user
search for this piece of content" or "take the author's view and characterise
what they are trying to say".  Neither is very useful as a framing question. 

Hutchins, in his paper, tackles this problem and introduces a distinction
between summarisation and aboutness. Summarisation is the representation of the
total subject content of a document and the statements made therein. While
aboutness is about capturing the thing that has been written about.

A very simple example might be a sport story about a player and whether they
will move clubs, their struggles with injury and their performance this year.
Many arguments are developed, making up the narrative of the story.
Summarisation would capture not only the player as a tag but also attempt to
capture something about the claims made about the subject of fitness,
performance and likely future at a club.  On the other hand, aboutness only
attempts to capture the thing being talked about and not what claims are made
about them. In this case just the player.

This distinction is rarely made in tagging guidelines and the tagger is left to
balance the level of summarisation and aboutness on gut feel.

Hutchins goes on to characterise this distinction in another interesting way.
The aboutness represents those things that are expected to already be part of
the readers knowledge. Every piece of content assumes a level of knowledge of
the reader with which the narrative then builds. Summarisation on top of this
attempts to capture what is new and builds on that existing knowledge in the
narrative of the content.  The readers are familiar with the player, but not
about the subtle changes in his fitness and future prospects.

With this in mind, the questions we might ask a tagger to answer are: What is
the thing being talked about? What claims or facts are made about a thing in the
content? What might the reader be presumed to know before reading this?

Whether we choose to do summarisation or capture aboutness is a decision related
to the desired outcome of the system. But we should be clear about which one it
is.

A more recent analysis by Birger Hjorland (The concept of subject in
Information
Science [https://www.emeraldinsight.com/doi/abs/10.1108/eb026895]) revisits the
problem.  He cites many examples of Guidelines expecting taggers to do little
more than perform "mind reading" on prospective future consumers of the content.

Instead, he argues, we must think about tags as a tool in enabling the full
potential of the document within the context of the overarching system.  The
desired outcomes of this system should then dictate the tagging strategies and
guidelines. 

It is this domain and system that must be crystal clear in taggers' minds as
opposed to the idea of aligning subject to a theoretical searcher.  They need to
also understand the value that they are creating and how.

Sadly, this is the opposite of what we see in many tagging tools and guidelines
today.

I would argue that tagging should be a contract between taggers and the system
 much in the way we see in the design of data services
[https://medium.com/@diogo.lucas/https-medium-com-diogo-lucas-contract-breaks-are-kinda-of-deal-breakers-447762de20c4]
.  Tagging guidance needs to be managed with a vision of the desired outcomes
combined with asking clear and simple questions of the taggers. This is as true
for humans as machines.

In summary, tagging outside of libraries and archives is often of poor quality.
Value is rarely understood, content creators are often asked to tag in ways that
are a chore and cognitively awkward. Worst of all, the question of what good
tagging looks like has rarely been asked.

In the next post I will look at some potential solutions to the challenge of
better tagging
[https://datalanguage.com/features/how-to-use-domain-modeling-to-improve-subject-tagging]
.

Part 1: Why the web turned its back on the librarians. And why we need them
back.
[https://datalanguage.com/features/why-the-web-turned-its-back-on-the-librarians]

Part 2: The importance of tagging when publishing on the web
[https://datalanguage.com/features/the-importance-of-tagging-when-publishing-to-the-web]

Part 4: How to use domain modeling to improve subject tagging
[https://datalanguage.com/features/how-to-use-domain-modeling-to-improve-subject-tagging]

Data Language is an industry leader in Information Architecture, ontology design and practical knowledge graph implementation. We use Domain Driven Design practises and user-centred design to focus information and data design on core business needs.

Find Information Architecture news and product innovation updates here, including ontology design, vocabulary management, domain & data modelling and more.

Information Architecture - News, Product Innovation and Technology

Information Architecture

Why good subject tagging is hard

An introductory guide to tagging: part 2

In the previous post we made the case for why organisations need to rediscover
fundamental library science skills
[https://datalanguage.com/features/why-the-web-turned-its-back-on-the-librarians]
.

Since the 1990s, library science has been written off by many as a relic of the
dark ages. The perception has been that the gap could be filled by search
engines, machine tagging or folksonomy
[http://shirky.com/writings/herecomeseverybody/ontology_overrated.html].  
However, increasingly organisations are starting to talk about the future in
terms of Knowledge Graphs and metadata. The skills of the librarians are back in
demand and needed more than ever.

There are a range of skills needed to support a comprehensive information
management strategy, but in this post I'm going to examine one:- Subject tagging
(more accurately subject indexing).

Why tag?
The first challenge is changing the perception about why to tag content. It is
often perceived as being about enabling better free text search.  However, this
is probably the least important outcome of tagging.

In fact there is nothing new here.

Since their inception 200 years ago, subject indexing in card catalogues has
been about more than keyword search. Instead these cards represent the domain of
knowledge to be explored providing many contextual entry points. Concepts (or
headings) are navigated rather than documents themselves.  This age-old context
based navigation was rapidly lost as library systems became computerised and
keyword search dominated.

Karen Coyle describes some of the problems of keyword search based catalogues:

> Once a keyword search is done the resulting items are retrieved without any
correlation to headings. It may not even be clear which headings one would use
to create a useful order. The set of retrieved bibliographic resources from a
single keyword search may not provide a coherent knowledge graph.
Karen Coyle Libraryland we have a problem
[https://kcoyle.blogspot.com/2018/08/libraryland-we-have-problem.html]

The situation still prevails today and results in massive lost opportunities for
organisations as they have unwittingly allowed this context to reside within the
search engines and not in their own publishing systems.

This misunderstanding of the value of subject indexing can mean organisations
miss out on the huge benefits.  Without structured subject metadata you limit
your options when publishing, using analytics and monetising content.

Clearly tagging content comes at a cost.  Is it outweighed by the benefits?  For
organisations spending large sums on producing articles, recording podcasts and
shooting video, the associated tagging and other structured descriptive data
often represents a tiny cost in percentage terms of creating the original asset.
 

This is perfectly illustrated by a push in the music industry for better music
metadata
[https://www.theverge.com/2019/5/29/18531476/music-industry-song-royalties-metadata-credit-problems]
.

> Metadata sounds like one of the smallest, most boring things in music. But as it
turns out, it’s one of the most important, complex, and broken, leaving many
musicians unable to get paid for their work.
Metadata is the biggest little problem plaguing the industry
[https://www.theverge.com/2019/5/29/18531476/music-industry-song-royalties-metadata-credit-problems] 
 

So what value can be derived from better tagging?  This clearly depends on the
specific business model of the organisation.  Some examples would be bringing
readers to your site and getting them to spend more time there. Others are
driven by analytics and user insight. Or it might be about revenue from better
targeted advertising or driving paid subscriptions.

In summary, subject tagging provides opportunities to increase the value and
impact of content and data. In the next post I am going to look at why subject
tagging is not as easy as it seems
[https://datalanguage.com/features/why-tagging-tends-to-be-bad-on-websites].

Part 1: Why the web turned its back on the librarians. And why we need them
back.
[https://datalanguage.com/features/why-the-web-turned-its-back-on-the-librarians]

Part 3: Why good subject tagging is hard
[https://datalanguage.com/features/why-tagging-tends-to-be-bad-on-websites]

Part 4: How to use domain modeling to improve subject tagging
[https://datalanguage.com/features/how-to-use-domain-modeling-to-improve-subject-tagging]

The importance of tagging when publishing on the web

An introductory guide to tagging: Part 1

This is the first in a series of short blog posts looking at the relationship
between information management and the web. 

This post looks at how developments in search technology between the late
eighties and today created the perception that good information management
practices were redundant. 

A conversation I had a few years ago with Edmund Weiner of the Oxford English
Dictionary has stayed with me ever since.  We talked about the 1980s and how,
during that decade, some publishers started to structure print for computers. He
recalled how questions began to be asked about what documents were really about
and how to represent that knowledge in a database.   

Then came the advent of search technologies. Edmund reflected on how this
resulted in us throwing away hard-won information management skills in favour of
black box technology we didn’t control:

> The march of progress swept us in a different direction, one that offered great
prizes in a much more immediate way. Our partners at the University of Waterloo
had developed one of the first rapid textual search engines, named Pat. It could
search simply-structured text of any kind almost instantaneously and with
well-tagged text it was miraculously powerful. As was said at the time, we
didn’t need to build the intelligence into the database as it could be built
into the search engine.
Modelling Lexical Structures in the Oxford English Dictionary  by Edmund Weiner
[https://brill.com/view/book/edcoll/9789004361133/BP000002.xml?lang=en]  [2008]

This situation still prevails today.  Intelligence resides within the search
engines and not in an organisation's own publishing systems.

The web followed the same path. Powerful search engines and poorly described
pages. Content would express its subject to bots through search engine optimised
copy and links. The abuse of meta tags with keyword stuffing only helped to give
subject tagging a bad name.

These technology developments removed the incentive to invest in doing your own
information management and many organisations unintentionally outsourced their
business intelligence and value creation to search providers. 

However, industry attention has recently shifted back towards subject metadata,
tagging and knowledge graphs as an area of investment. Google have long since
moved to advocating a more structured approach to publishing on the web using
schema.org to provide a baseline data model and Wikidata to provide a baseline
knowledge graph.

What is the reason for the change in perception and the renewed interest in
information management? Organisations are starting to wake up to the fact they
no longer want to outsource business intelligence to Google and other third
parties. To get the most value out of their content they need the ability to
query and aggregate content themselves.

Refitting the plumbing to tag content and manage controlled vocabularies is
potentially a large and complex investment. But there are principles and ideas
that information scientists have been practicing for years that can help,
regardless of the size of the organisation. These challenges will not be solved
by technology alone. Library skills are needed to fill these gaps in expertise. 

In the next post I am going to look at the  importance of subject tagging
[https://datalanguage.com/features/the-importance-of-tagging-when-publishing-to-the-web]
.

NOTE: If you want to learn more about Library Science and its the family of
associated disciplines ISKO UK [https://www.iskouk.org/]  and Taxonomy Bootcamp
[http://www.taxonomybootcamp.com/London/2019/Default.aspx]  is a great place to
start (UK focus). They run a brilliant series of events as well as bringing
together the community of practitioners.

Part 2: The importance of tagging when publishing on the web
[https://datalanguage.com/features/the-importance-of-tagging-when-publishing-to-the-web]

Part 3: Why good subject tagging is hard
[https://datalanguage.com/features/why-tagging-tends-to-be-bad-on-websites]

Part 4: How to use domain modeling to improve subject tagging
[https://datalanguage.com/features/how-to-use-domain-modeling-to-improve-subject-tagging]

Blogs by Silver Oliver