Tag Archives: RDF

Apps Break Data

Information is not a first-class citizen in corporate information systems. Worse, it is neglected. Then why do we still call them information systems? We don’t. We call them applications. And applications, quite appropriately, are built or purchased with an application-centric mindset. Consequently, data is broken into diverse fragments, tightly coupled with applications, and expensive to reassemble into coherent information entities. Software engineering and procurement practices work in sync with market forces to maintain this trend.

How does this happen? And what can be done about it?

This essay is about the corporate management of data. If an essay about corporate data management had been written a decade ago and mentioned Artificial Intelligence, that would have been a weird essay. It’s the opposite today. A weird essay is a data management essay that’s not about AI. And this will be such a weird essay. I think that AI, more concretely LLMs, came too early, before we managed to solve problems with data quality and interoperability.

Speaking of AI and weird, a recent paper1Atari, M., Xue, M. J., Park, P. S., Blasi, D., & Henrich, J. (2023). Which Humans? OSF. https://doi.org/10.31234/osf.io/5b26t reported that all LLMs have WEIRD bias. They are trained on data coming exclusively from countries that are W.E.I.R.D: Western, Educated, Industrialized, Rich, and Democratic. For LLMs, WEIRD is the norm.

In large organizations, weird is the norm as well, and here is one manifestation:

Information systems are not about information.

Now, the question is, of course,

How could that be?

Continue reading →

Linked Data uptake

Linked Data is a universal approach for naming, shaping, and giving meaning to data using open standards. It was meant to be the second big information revolution after the World Wide Web. It was supposed to complement the web of documents with the web of data so that humans and machines can use the Internet as if it is a single database while enjoying the benefits of decentralisation1This is the balance between autonomy and cohesion – essential for any socio-technical system..

Today, we have 1495 linked open datasets on the web, according to the LOD cloud collection. Some among them, like Uniprot and Wikidata, are really big in volume, usage, and impact. But that number also means that today, 15 years after the advent of Linked Data, LOD datasets are less than 0.005% of all publicly known datasets. And even if we add to that the growing amount of structured data encoded as JSON-LD and RDFa in the HTML, most published data is still unavailable in a self-descriptive format and is not linked.

That’s in the open web. Inside enterprises, we keep wasting billions attempting to integrate data and pay the accumulated technical debt, only to find ourselves with new creditors. We bridge silos with bridges that turn into new silos, ever more expensive. The use of new technologies makes the new solutions appear different, which helps us forget that similar approaches in the past failed to bring lasting improvement. We keep developing information systems that are not open to changes. Now, we build digital twins, still using hyper-local identifiers, so they are more like lifeless dolls.

Linked Enterprise Data can reduce that waste and dissolve many of the problems of the mainstream (and new-stream!) approaches by simply creating self-descriptive enterprise knowledge graphs, decoupled from the applications, not relying on them to interpret the data, not having a rigid structure based on historical requirements but open to accommodate whatever comes next.

Yet, Linked Enterprise Data, just like Linked Open Data, is still marginal.

Why is that so? And what can be done about it?

I believe there are five reasons for that. I explained them in my talk at the ENDORSE conference, the recording of which you’ll find near the end of this article. I was curious how Linked Data professionals would rate them and also what I have missed out on. So I made a small survey. My aim wasn’t to gather a huge sample but rather to have the opinion of the qualified minority. And indeed, most respondents had over seven years of experience with Linked Data and semantic technologies. Here’s how my findings got ranked from one to five:

Continue reading →

  • 1
    This is the balance between autonomy and cohesion – essential for any socio-technical system.

Buckets and Balls

Linked Data is still largely unknown, misunderstood and undervalued. Often, people find it too difficult. So I keep looking for new ways to make Linked Data more accessible. And with some success. In my training courses so far, over 60% of the participants had no IT background.

What seems to be most challenging is writing SPARQL queries. The specification is written for IT people. There are some great courses and books, but they also target people with some or more IT experience. If anything, that scares the rest and keeps SPARQL away from the masses.

I continue to learn what is challenging. A recurring, and somewhat unexpected, problem is understanding the concept of variables.

What is a variable in SPARQL? Just a placeholder, some technical texts say. But how can you imagine a placeholder? It’s abstract. We have no way of grasping abstract things unless we associate them with something physical and concrete. It’s difficult to imagine time, but once we draw it in space it gets easier. We can’t picture furniture, but we have no problem with chair.

The other issue is how a SPARQL query looks. While working with SPARQL helps to understand how a knowledge graph works, a SPARQL query doesn’t look like one. It is like with symbols in mathematics. “5 doesn’t look like five, while ||||| is five”. The problem with SPARQL is similar:

You want to query knowledge graph.
You want to learn new things.
But your query doesn’t look like knowledge graph.
It looks like lines of strings.

So, how to handle together the problems with grasping variables and with the look of SPARQL?

My suggestion is to imagine every SPARQL query as a graph of linked buckets and balls.

Variables are placeholders but abstract. We need a physical container1The idea of using containers is very powerful. The whole arithmetic and algebra can be done using only the concept of container as demonstrated by William Bricken. to fill with things. We need buckets. And nodes are like balls. So, think of running2“Running” is also a metaphore and what it stands for can be communicated more gracefully. And that’s important. As you know, language shapes the way we think. a query as filling buckets with balls.

A graph pattern then will look like this:

A bucket ?A should be filled with those balls which have a relation R to ball B.

But it looks nicer when we abbreviate it like this:

This is a graph pattern in Buckets’n’Balls notation. The direction of the relation R is not shown but it’s always from left to right.

The process of writing and running a SPARQL query would then go through the following steps: Continue reading →

  • 1
    The idea of using containers is very powerful. The whole arithmetic and algebra can be done using only the concept of container as demonstrated by William Bricken.
  • 2
    “Running” is also a metaphore and what it stands for can be communicated more gracefully. And that’s important. As you know, language shapes the way we think.