dbdump.org - ontologies

Baking-in bibliographic references directly into RDF / OWL ontologies

warren — Mon, 22 Jul 2024 01:20:21 +0000

Not every part of an ontology is novel. Often enough we reuse existing works and standards to populate them. At other times the ontology implements policies and processes that are outlined in a document narrative but never before formalised into a data structure. To give credit where credit is due, and to ensure policy compliance, it can be worthwhile to integrate bibliographic citations and references directly within the ontology. Ontologies already exist to record bibliographic data. BIBO is one which has the added benefit that it provides a direct mapping for bibtex-style bibliography managers. Bibframe provides a comprehensive solution if you have a corporate document repository, but avoid using Dublin Core’s bibliographicCitation term as it was never standardised.

Bibliography as ontological objects, but why?

When the bibliographic reference for the documents used to create the ontology are themselves available as ontological terms, they can be directly referenced by other terms or queried directly. This isn’t an exercise in minutiae; it is a change management tool and an additional asset for application developers.

When a term represents a concept defined by a standard, you can directly link it to the specific edition of the document that defines it authoritatively. Besides avoiding the need for those pesky double quotes in the definition property, this also tracks which edition of the standard this term represents. This can easily be done with various levels of verbosity (hadPrimarySource) using the PROV ontology or by using a simple Dublin Core source annotation.

This is important not only for change management: it helps to differentiate terms that have the same labels and similar descriptions but whose context differs from one edition to another. Thus, datasets that record events using older specifications retain their integrity and newly generated data is kept up to date with current standards.

Keeping up with the Joneses

Things change and so does the paperwork. With citations as terms it becomes possible to link them to document management systems and to query them directly within the ontology or the knowledge graph. This allows for the monitoring of which documents are currently referenced by any ontology and whether these will need to be updated upon the publication of a new edition of a reference document.

From an application developer or end user perspective, consider that this allows for greater transparency of process and communication. Design decisions can be linked backed to the narrative of the original standards with minimal clerical effort since it is integrated to the ontology graph.

We often talk about AI explainability as if this was an algorithmic design problem, but this isn't completely true. There is no point explaining the workings of an algorithm if the underlying rules, facts and definitions that communicate with the outside world aren’t available. No amount of abstract logical proofs have value if you are unable to explain if the coded output means bi-annual interest or monthly interest.

Document, Document, Document

Writing documentation is a thankless task: everyone demands it in their preferred style, few will actually eventually read it and more often than not, the select few individuals that do write it have limited resources to do it properly. An ontology-based bibliography lets you automate some of the documentation generation, referencing and cross-referencing in whatever citation format is required.

Ontologies are primarily objects of communication and interoperability. Some schools of thought, "The Ontology Is The Documentation", fail to consider that no matter its logical coherence, an ontology is part of a bigger world. The ability to reference outside documents and terms ensures that the ontology functions within an operational contexts and adds to the value of the ontology and saves valuable time for its users.

Language English

Tags:

rdf

owl

owl2

bibo

ontologies

documentation

Ontologies, what are they good for really?

warren — Thu, 01 Feb 2024 15:46:50 +0000

Ontologies have a chequered past in the business arena, although many significant benefits have been realised over the past two decades in biological and medical research. Wrapped up in the AI hype and occasionally lumped in with knowledge management projects or taxonomy projects they are often shelved curiosities whose original purpose is lost by their champions. What is an ontology? Generally speaking, it is a set of concepts, their properties and the relationships that link the concepts together.

The power of Ontologies lies in the management of complex, and often overlooked, facts about an Enterprise. Which of your brands are specific to a market and a language? What is the trade name of this widget in some foreign language? What is its common name? Are shipping manifests linked to a single invoice or can they be composed from multiple invoices? Is this within a single division or across the entire enterprise? All of this data is somewhere within the company be it in employees’ minds, in software configurations or explicitly listed within a standards document.

The benefit of an ontology is that it becomes a single point of reference for all of these items in a format that is machine readable and writable, that permits multilingual documentation and labelling and that can differentiate between what an object is and what it is called. An important point is that while an ontology has to be consistent, it can represent multiple truths and perspectives at the same time. Not all parts of the organisation work the same way; this is perfectly normal and there is great value in documenting how they actually work.

It’s not just Taxonomies

People have a natural tendency to categorise and organise information. Taxonomies are one way to create simple hierarchical "trees" to organise concepts and values. One issue with this method is that different departments in the business have different taxonomy layering structures for the same concepts. This results in many taxonomies being used for some concepts (Products being a typical example) and trying to report or find product characteristics against these different taxonomies can become complex.

But ontologies go beyond this by adding the capacity to relate the concepts, instantiate the concepts and add labels and descriptions in multiple languages, thus decoupling the identifiers from the representation data. From an enterprise perspective, many applications and systems fail to differentiate between these and the result is that small changes trigger a complete reconstruction of the application’s database.

The separation of the identifier from the content and multilingualism means that data can be updated automatically within downstream software without having to navigate across what the “official translation” for a concept is: Who would you even ask to find out what the localised name of your corporation is in German or whether the description for a particular widget is the same in the German and Austrian markets are the same?

Master data management. Done right

Master data management often promotes the idea of capturing information as a single source of truth. This makes sense at first glance: everyone should be on the same page, using the same processes and nomenclatures across the enterprise. However, most businesses are more nuanced, with information viewed and used in multiple business perspectives. This becomes even more of a challenge with the common use of 3rd party applications that can embed different nuanced meanings depending on the degree of fit for the purpose of the business. Often this implied context, and how to handle the exception, is undocumented and lives on an ad hoc basis within the minds of company personnel. This creates an additional unreported business continuity risk.

A simple example is a list of office locations: some locations are plants with a shipping yard, multiple buildings, a mailing address for the front office and street addresses for all of the above. The fact that a parcel makes it to the right location will often require either local knowledge from the courier company or a few phone calls and false starts as the right destination is found.

The assignment of an identifier to each sub-location helps to differentiate them all from an ambiguous label “The Pittsburgh Plant”, but fails to record the relationship between them. This creates some concerns for downstream users of the data who have to track the identifier within their own system and attempt to identify the “right one” amongst the list while aggravating end users who just want to send something to “Bob at the Pittsburgh Plant”.

It is in these cases that ontological solutions shine because of their ability to handle complex data and handle ambiguity. An ontology can easily represent that the office space in building ‘D’ of the Pittsburgh Plant in Westmoreland has its mail routed through the main plant office at 567 Alpha Drive. Finding the “right” entry is left to the system integrators who have full knowledge of their context and who can query the right entry.

Interoperability

Lastly, ontologies can be designed to promote Interoperability. Enterprise information systems are made up of multiple pieces of software that look at data from different perspectives and with a specific focus. This often results in having various pieces of the same thing in different locations while making it prohibitively complex to resolve the meaning of the information.

Ontologies and their associated knowledge graphs allow for information that is redundant across different applications to be reconciled and loaded from a central point that can be used to link the data. While one application may only need to be aware of products name and description, another may need compliance information and a third may only be aware of product weight and dimensions for shipping purposes. Keeping all of this information in sync is difficult since applications have different ideas about object identity and identifiers; something that an ontology can easily keep track of.

Wrapping it all up

Ontologies and their associated knowledge graphs provide a useful mechanism for handling complex information and translating across different viewpoints of the same instances. Beyond their application to master data management, interoperability and harmonising multiple concurrent taxonomies ontologies are an effective tool to record complex enterprise information. They have been used with success by large companies such as the ‘Fargo’ and ‘Erica’ virtual assistants at Wells Fargo and Bank of America and Google Knowledge Graphs to drive effective business tools. In future posts we will be exploring what tooling, management structure and processes are required to ensure effective ontology use within the company.

This article was written as part of the Bizon Business Ontology project.

Language Undefined

Tags:

What is going wrong with the Semantic Web?

warren — Tue, 10 Apr 2018 17:15:34 +0000

The US Semantic Technologies Symposium was held at Wright State University a month ago where there were great discussions with Craig Knoblock about SPARQL servers reliability1, Eric Kansa about storing archeology data and Open Context, Eric Miller about the workings of the W3, mid West farmers and old bikes, Matthew Lange about tracking crops with LOD and a 'fruitful' talk with Evan Wallace about farm data storage standards.

Thinking through these conversations, I decided to outline what I think are the troubling conclusions for our area, namely that a) Semantic Web adoption is lagging, b) we keep rehashing old problems without moving on and c) our ongoing lack of support for our own projects after which I'll suggest a few solutions.

Semantic Web adoption is not where we'd like it to be

Very, very few people care about data management2. Even fewer people understand data management. I'd go so far to say that the majority of the IT community spends its time moving strings to the end-user's screen, focusing primarily on user communications and getting told what to communicate. Other developers may worry about analysis, networking stacks or storage, but the number of them that care about the data itself are few.

That leaves the database developer whose entire attention is on bread and butter issues. Why did we have the hubris to think that people would care about the Semantic Web when most of them have no data management problem to worry about? 31% of webpages are reported to contain schema.org 3, primarily because Web Developers believe it will help them with SEO issues, not because it helps them with data management or interoperability.

Reinventing the wheel. Again.

I regret I didn't note the speaker who said "If your developers care about JSON, I don't care about your developers", because it goes to the heart of the matter about poor Semantic Web training and education. At this stage arguments about serializations are about as relevant as debating whether submarines can swim4. The was a lot of talk at the meeting about creating new json standards to handle corner cases without knowledge or regards for previous standards because "it's not JSON and people want JSON". The Semantic Web stack translates the model to whatever serialization is needed, in most cases negotiated without programmer involvement. JSON is really nice for web developers, RDF/XML for XPATH, turtle for authoring, n3 for throughput, et al. David Booth also noted the panoply of standards and vocabularies. A number of them have been beautifully engineered by domain experts (GeoSPARQL 5, OWL-TIME, SOSA and PROV come to mind), it's an outright waste of everyone's time not to reuse them.

We expect research groups to act like service providers

The lack of reliable services and exemplars was also noted: the curated New York Times RDF dataset is no longer answering, the BBC has cut back on outward looking Semantic Web services and DBPedia, at the heart of the LOD cloud, is still running on a borrowed virtual machine with the DBPedia Association having a hard time raising funds. I would like to echo Juan Sequeda's post that we should set aside some grant monies for resources such as Linked Open Vocabularies, a great vocabulary/ontology location tool6 Getting operational funding is always a slog but we cannot advocate for a technology when the exemplars are not maintained and disappear overnight.

In the past we've gotten away with a lot by stuffing machines under graduate students's desks and getting them to write applications between course work and thesis submission. This is not sustainable and we need to make an effort on long term sustainability.

What we should be doing

The Semantic Web stack is annoyingly complex, not because of the technology but because of the problems that it is trying to solve. Its critics abound (even Hitler apparently) but there is no real alternative to deal with data at scale. Organizationally, it sits uncomfortably between two communities:

The first is the small group of developers that deal with web apis, mostly independently from each other. Integrations are done on an ad-hoc basis when the one-off business requirement presents itself. These are the people that came up with ideas like Swagger: simple documentation that focuses on programmatic operations with little semantics about the transaction itself. Want it in Orange? Set colour_id to 2. Why 2? Because that's the value some developer arbitrarily decided on at the time. Why is your self-evident use case not handled? Because no one has needed it before. Development is incremental. If an error occurs, put in a ticket into github, no harm done.

The second is the Enterprise Resource Planning crowd that has has been doing this for a very long time, albeit usually within a single organization and with massive amounts of corporate resources. Because they care deeply that orders of 5,000 sheets of 8.5x11 paper aren't interpreted as orders of 8,511 sheets of 5000in² paper, they tend to document everything (a single API document may run 100's of pages) and have a neurotic attention to change management. There have been spectacular failures when implementing these mammoth7 systems, but generally you can order something from across the world and it will show up on your doorstep next week.

The Semantic Web has a lot to offer to both these communities: a ready made semantic modelling language8 that is reusable by web apis, URL-based global identifiers and a unified multilingual documentation framework than fits corporate needs. Bridges need to be built with application domain experts and with existing data eco-systems. Logistics systems such as Global Trade Item Number are pushing the limits of what we can do with barcodes and relational databases. We want the Internet of Things, the Internet of Food, a smart power and transportation grid and a bibliographic system that isn't going to split it's seams. The only way that we can achieve all of this is to have the data that is being generated supported by content and the Semantic Web.

1. Short version, my experiences with the Muninn Project, CWRC, CLDI and Myra have been positive. Overall SPARQL servers have had less engineering calendar time than other comparable software: Apache and Mysql have been worked on since 1995, Postgresql since 1986. In contrast, Virtuoso has had SPARQL since 2005, Alleograph 2004 and ARC2 2010. 10+ extra years of development work helps. Furthermore, Mondeca's SPARQL endpoint monitor show that SPARQL servers do have good uptime. The often misquoted 63% of endpoints being offline applies to every SPARQL server ever seen since 2013. The statistic that should be worrisome is that only 13% of them have ever had a machine readable description!
2. Data management is the simplest redux of the semantic web and ontology. I'm setting the bar low on purpose...
3. It would be interesting to see how many of these triples are well formed, sensical and form a data structure that makes syntactically.
4. With apologies to Edsger Dijkstra.
5. The name is somewhat of a misnomer since the standard contains both an ontology to describe both feature and geometry, as well as SPARQL extensions meant to spatially reason over the data. It is based on previous OGC work and is rock solid.
6. Developed by Bernard Vatant and Pierre-Yves Vandenbussche .
7. Without putting Alessandro Oltramari on the spot, it took Robert Bosch over a decade to get everything running and it is considered a case-worthy installation.
8. Notwithstanding some early OWL missteps mentioned by Deborah McGuinness, the basic ontological framework underneath the semantic web is extremely powerful and a godsend for data integration.

Language English

Tags:

Français

Creating specialized ontologies using Wikipedia: The Muninn Experience.

warren — Mon, 25 Jun 2012 21:10:00 +0000

Creating specialized ontologies using Wikipedia: The Muninn Experience.

Wikipedia Academy 2012

Paper Session III, Saturday June 30, 10:30-11:30

Abstract:

This paper reports on the experiences of the Muninn project in creating specialized ontologies for historical governmental and military organizations using the Wikipedia data set and its linked open data companion DBpedia. The motivation for the ontologies and the extraction methods used are explained and their performances reviewed. Overall Wikipedia is a very accurate knowledge base from which multilingual concepts can be extracted. The caveat is that while the information is almost always present, it is not always straightforward to retrieve because of missing structures or categorization information. Hence, an iterative methodology has been found to work best in extracting information from Wikipedia.

Language Undefined

Tags: