UMBEL Web Services Endpoints Released

Frederick Giasson
After some delay, we are pleased to finally release the UMBEL Web services endpoints to the public. We have re-organized the Web services we introduced three months ago to add coherency and flexibility to the model.

The goal remains the same, but with a different flavor: these tools let ontologists and Web developers search, discover and use the UMBEL subject concept and named entity structures. The added flavor is that these Web services now fully embrace the HTTP 1.1 protocol and are provided via a series of well established data and serialization formats.

We now have RESTful Web services to add to our RESTful linked data. Pretty cool combination!

We are introducing two kinds of Web services: (1) atomic Web services and (2) compound Web services. An atomic Web service only performs one action: It takes some inputs and then outputs a resultset of the action. A compound Web service takes multiple atomic Web services, plugs them together in a pipeline model, and then takes some inputs and outputs a resultset arising from the compound action.

The communication between each of these Web service instances and the external World is the same: communication is governed by the HTTP 1.1 protocol. HTTP is generally RESTful and used to establish the communication, to determine mime type and serialization, to get inputs, to return status of the communication and possible errors, and to send back the resultset of the computation of the Web service.

That way, we can easily, within hours, programmatically pipeline these atomic Web services together to create new Web services. We can integrate external Web services endpoints into the same pipeline without modifying anything to the architecture. Status, errors and resultsets are propagated along the line, directly to the data consumer. This is the flexibility part of the story.

Now, how cool is that?

Overview of the UMBEL Web Services Endpoints

We are today releasing a couple of these atomic and compound Web service endpoints to the public, but others will follow in the coming weeks and months. Four families of Web services have been released that total seven Web service endpoints:

If you don’t know what UMBEL is, I would suggest you read a background information page that talks about the project.

The most important reading related to this blog post is the API philosophy documentation page that talks about the details of the design of this Web services architecture.

For Web developers that want to integrate these Web services endpoints within their application, an API documentation page explains how to communicate with these endpoints for each of the services.

Example of an Atomic Web Service

The Inference: Lister Web service is a good example of an atomic Web service. It takes a subject concept URI as the input and outputs a series of super-class-of, sub-class-of or equivalent-class-of classes for that concept. As an atomic service it does one thing and one thing only: Inferring relationships of a given subject concept URI.

Example of a Compound Web Service

The Reporter: Named Entity Web service is a good example of a compound Web service. This Web service displays full of information about a UMBEL named entity URI. However, not all the information returned by this Web service is directly computed by it. In fact, the information about broader and equivalent classes and subject concepts come from the Inference: Lister Web service. Results coming from this Web service are immediately integrated in the Reporter’s resultset. This is easily done considering that they share the same communication language (HTTP 1.1) and the same data and serialization formats (XML, RDF+XML and RDF+N3). This flexibility is priceless to quickly create resourceful compound Web services.

Conclusion

After some months to get the design right, we have finally released some of the UMBEL Web services to the public. These Web services can easily be integrated in current software architectures to leverage UMBEL’s vision of the World. The architecture underlying what we have released today will help to easily integrate UMBEL’s principles and concepts within new and existing projects. This will ultimately help people to quickly react to the changing World of needs and expectations of data users and consumers.

I hope you will enjoy using these new Web services, which Zitgist is freely hosting. The data you get from the Web service is open data and can be used freely with attribution.

Please do report any issues you may encounter. We also welcome any advice or suggestions that you would care to provide to enhance the overall system.

Exploding DBpedia’s Domain using UMBEL

Frederick Giasson

A couple of challenges I have found with DBpedia is that it is hard for a system to interact with the dataset and it is hard to figure out how to interpret information instantiated in it. It is hard to know what properties are used to describe individuals; and hard to know what the classes refer to. It is also hard for standalone and agent software to understand the nature of the individuals that are instantiated by DBpedia because the classes they belong to are generally unknown or poorly defined.

In the following blog post I suggest to use a method known as “exploding the domain” to try to overcome these difficulties of using and understanding DBpedia. This adds still further usefulness to DBpedia’s considerable value. This demonstration is based on the UMBEL subject concept structure.

As I will demonstrate below, this method consists of contextualizing classes in a coherent framework to explode their domains. By exploding the domain of a class, we link it to other classes that are defined by external ontologies. By exploding the domain of a class by linking it to externally defined classes, we also help standalone and agent software to understand the meaning for that class (at least if they understand the meaning of the classes that have been linked to it). Note that we are able to explode the domains by linking classes using only three properties: rdfs:subClassOf, owl:equivalentClass and umbel:isAligned.

First of all, let me give some background information about how DBpedia individuals and UMBEL named entities have been created, and how both datasets have been linked together.

How DBpedia individuals are instantiated

DBpedia is a dataset that is based on the well known Wikipedia encyclopedia. Basically DBpedia creates one individual for each Wikipedia page. Most of the individuals that are instantiated in this way are what we call a “named entity” in UMBEL’s parlance.

But to be instantiated, an individual has to belong to a class. DBpedia chooses to use Yago‘s classification system (that is based on WordNet) to instantiate those DBpedia individuals. This means that all DBpedia individuals belong to at least (theoretically) one Yago class. This means that all DBpedia individuals are instances of Yago classes (and in some rarer cases, they are also instances of classes defined in external ontologies).

How UMBEL named entities have been created

For its part, UMBEL’s named entities dictionaries come from different data sources. Currently, most all public UMBEL named entities also come from Yago (example: Aristotle), but many also come from the DBTune dataset (example: Pete Baron) or others. (UMBEL’s design allows more named entities to be plugged into the system as additional dictionaries at will.)

However, unlike DBpedia, we do not use Yago’s classification system to instantiate these named entities. And unlike Yago, we do not use the WordNet classes to instantiate the named entities either.

The current UMBEL subject concept structure is based on OpenCyc. This means that the relations between the classes that instantiate the UMBEL named entities come from the Cyc knowledge base.

So while we use Yago’s named entities (from Wikipedia) as a starting basis, we instantiate them using the UMBEL subject concept classes instead of the WordNet classes. So, basically, we have switched the WordNet conceptual framework for the UMBEL (or OpenCyc) one.

But, how did we create these UMBEL named entities, instantiated using UMBEL subject concept classes and based on Yago? Here is the linkage path:

Yago classes –> WordNet synsets <– Cyc collections <– OpenCyc classes <– UMBEL subject concept classes

Et voilà !

How UMBEL named entities are linked to DBpedia individuals

OK, so now how do we link UMBEL named entities to DBpedia individuals? It is simple. Remember that DBpedia individuals have been created from Wikipedia pages. Also remember that Yago individuals come from the same Wikipedia pages. We can then make the link between the individuals from DBpedia and the individuals from Yago based on Wikipedia URLs.

Exactly the same logic applies for linking DBpedia individuals to UMBEL named entities.

The end result of this linkage is that we have UMBEL named entities that are the same as DBpedia individuals. The difference is that the UMBEL named entities are now instances of UMBEL subject concepts: a totally different conceptual structure.

Remember that these named entities are contextualized in a coherent conceptual framework. And this characteristic means a lot for what is yet to come.

Web services to search and visualize these named entities

We created two new web services on the UMBEL web services home page (the user interface to these web services; the endpoints will be released later) to help people interact with these named entities:

  1. The “Search Named Entities Dictionaries” web service
  2. The “Named Entity Detailed Report” web service

The first web service lets you search amongst all publicly available UMBEL named entities dictionaries.

The second web service lets you visualize detailed information about any named entity.

This information page shows you the full scope of information about a named entity: which class it belongs to (subject concept classes as well as external classes); which other individuals, from other datasets, are identical to them; examples of web services that get queried with information about this named entity; etc.

Exploding the domain of Plato

Now that this background information has been established, let’s take a look at what is happening when we link DBpedia individuals to UMBEL named entities: how that actually works to explode the domain.

Let’s take the example of dbpedia:Plato. This individual is currently defined in DBpedia as:

  • yago:AncientGreekPhysicists
  • yago:PhilosophersOfLanguage
  • yago:PhilosophersOfLaw
  • yago:PoliticalPhilosophers
  • yago:AncientGreekVegetarians
  • yago:AcademicPhilosophers
  • yago:Philosopher110423589

Fine, but what does this mean? What if my system doesn’t know any of these classes? We, as humans, know that Plato is a person, a human being. But it is totally another story for a software agent.

What we want to do here is to explode Plato’s domain to try to find a meaning that my software system can understand.

In UMBEL, the “Plato” named entity is defined as an umbel:Person and an umbel:Intellectual. If you take a look at the detailed report for these two subject concepts, you will be able to see in the section “Broader Subject Concepts” the super-classes that Plato belongs to. So we know that Plato is a social being, a homo sapiens, etc. This is basically what happens with Yago too, except that the conceptual structure (the way to describe the entity) differs.

However one thing that is happening is that we exploded Plato’s domain with classes defined in external ontologies. As you can notice in the sections “Broader External Classes” and “Equivalent External Classes”, Plato is also a: foaf:Person, a foaf:Agent and a cyc:Person.

This means that if my software agent doesn’t know what a “yago:Person100007846” means; it alternatively may know what a foaf:Person or a foaf:Agent means. And if it knows what it means, then it will be able to properly manipulate it: to display it in a special way; to refer to it as a person; so to do whatever it can with information about a “person”.

This exploding the domain works because these external ontologies classes have been referentially linked to a coherent conceptual structure.

The inference path

Let’s take a look at the fundamental reasons why the scenario above works.

First, you, and your system, have to trust the UMBEL named entities dictionaries and the UMBEL subject concept structure to perform the inference that I will explain below. If you and your system trust these linkage assertions, then you will be able to act according to the knowledge that has been inferred.

DBpedia individuals are linked to UMBEL named entities using the owl:sameAs property. This means that DBpedia individual A is identical (same semantic meaning) as the UMBEL named entity B. They both refer to the same individual.

This means that if B is defined as being of rdf:type sc:Person (“sc” stands for Subject Concept), then we can infer that A is defined as being of rdf:type sc:Person too.

If sc:Person is owl:equivalentClass with foaf:Person, we can infer that umbel:B is a foaf:Person, so that dbpedia:A is a foaf:Person too!

We can see similar examples for exploding the domains:

Exploring ConceptualWorks, PeriodicalSeries and NewspaperSeries

In my “UMBEL as a Coherent Framework to Support Ontology Development” blog post from last week, I showed how UMBEL subject concepts acted to create context for linked classes defined in external ontologies. Since DBpedia individuals are instances of classes, and that some of these classes are linked to UMBEL, these subject concept classes also give context to those individuals!

As some examples, go ahead and take a look at the “Named Entities for …” section of these detailed report pages:

The partial list of named entities that are returned by the detailed report viewer shows named entities that mainly come form Wikipedia (so that have links to DBpedia). These subject concepts gives a coherent context to those DBpedia individuals.

You should quickly notice, for example, that dbpedia:Kansas_City_Times is not only a sc:NewspaperSeries, a sc:PeriodicalSeries and a sc:ConceptualWork. You also notice that it is a frbr:Work, a bibo:Periodical and a bibo:Newspaper.

The context created by these UMBEL subject concepts gives not only new power to linked external classes, but also to their instances, such as these DBpedia individuals!

Conclusion

Contexts created by UMBEL subject concepts emerge by the power of linkage that exists between all the subject concepts, and the linkage between those subject concepts classes with classes defined in external ontologies. These contexts are consistent because of the coherence of the structure that is powered by OpenCyc (Cyc).

So far, most Linked Data has been about the “things” or named entities of the world, organized according to either Wikipedia categories or WordNet. These structures may have some internal structural consistency, but were never designed to play the role as a coherent reference framework. The coherence of UMBEL (based on the coherence of Cyc) is a powerful contextual lever for bringing order to this chaos.

Once information gets linked to a coherent framework such as UMBEL, things start to happen; powerful things. And, with each new linkage and relation to additional external ontologies, that power increases exponentially.

I wrote this blog post to show again the power of exploding the domain using DBpedia as an example, and how UMBEL can help to use and to leverage such big datasets.

UMBEL as a Coherent Framework to Support Ontology Development

Frederick Giasson

There are multiple ways to represent the World we live in. Someone will think about something in a way, where someone else next to him will think about the same thing in another way. They will think about it in different ways: different characteristics, different ways to interact with it, different ways to use it, different ways to think about its composition, its relations with other things, and so on.

What is nice is that probably all of these different ways to think about this thing are good: after all, there are many ways to think about the same thing. It is this characteristic of thinking about things in different ways that leads to innovation.

But innovation is also not a game where anything goes. Things that work in the real world and in real ways need to adhere to certain rules, concepts, principles and theories. Continued innovation requires working within these coherent frameworks of natural relationships and order.

So, while a beautiful thing is that we can create new frameworks to think about things differently, not all of those frameworks work as well as others or make sense.

While it is conceivable that one could suppose any new framework or to think about things differently, frameworks that are actually useful should, among other things:

  1. Make sure the development of innovations within the framework is coherent
  2. Make sure the development of innovations within the framework is in context
  3. Help coordinate the development of projects and the cooperation of agents that work on these projects in order to achieve (1) and (2).

What seems clear to me is that the lack of any of (1), (2) or (3) makes innovations difficult and/or less powerful and less useful.

Why Would the Development Of Ontologies be Different?

The Semantic Web is often seen as a place where people describe things in multiple ways and where these things are more or less magically related together. For example, if you can’t properly describe something, you only have to create a new ontology, or to extend an existing one, and to publish it, et voilà!

The more I work in this field, the less I believe in this.

Remember my first point? People tend to think about things in different ways. The same logic applies to the development of ontologies (particularly in the development of ontologies!). Two ontologies, intended to describe the same things, can describe them in totally different ways. So, while some of the magic is that both ontologies can perfectly describe these things but only in different ways, there are other aspects that are not magical at all.

The problem here is to have at least one framework that helps people to develop ontologies such that the:

  1. Developed ontologies remain coherent
  2. Developed ontologies are in context
  3. Coordination of the development of ontologies and the cooperation of the agents working on these ontologies projects is effective to achieve goals (1) and (2).

This construct looks familiar, doesn’t it?

What I am proposing here is to use UMBEL as a coherent framework for ontology development. I am not saying that other frameworks can not play a guiding role in ontology development. But I am saying two things. First, some form of reference framework is necessary. And, second, truly useful frameworks must also be consistent and coherent.

What I am stressing here is the importance of conceptual frameworks to develop ontologies that can be used by people, companies and systems to properly and efficiently exchange data; and at some level, to reason over this data, too.

I think that the only way to do this in an efficient way is by grounding ontologies in such conceptual frameworks.

The ultimate goal is to make data exchange and data reasoning effective to people, organizations and systems that consume this sea of data. And I believe that it is not possible to achieve without grounding these efforts in a coherent, conceptual framework.

An Example at Work

Nothing is better than an example to shows the potential of UMBEL as a coherent framework to develop, and cross-link, ontologies.

Let’s take the Bibliographic Ontology as an example, which we just cross-linked to UMBEL in yesterday’s version 071 release. (Among a dozen other key ontologies; the list is getting pretty cool!)

The goal is to link BIBO classes to UMBEL subject concepts. The linkage is done using three properties: owl:equivalentClass, rdfs:subClassOf and umbel:isAligned.

But firstly, what is the goal here? We try to do two things when linking such ontologies to the UMBEL framework:

  1. To make sure the ontology (BIBO) is coherent and consistent with other existing ontologies that are linked to the framework (other such ontologies could be FOAF, SIOC, etc.)
  2. To make sure that the design choices of the developed ontology are consistent with the design choices of the framework, and the other ontologies that are linked to that framework.

Both points try to help achieve a grander vision: trying to make the semantic Web a little bit more coherent and easy to use and understand.

The BIBO Linkage

This figure shows how BIBO classes have been linked to UMBEL subject concepts in a set-like schema (click to enlarge the schema):

This schema shows what set belongs to what other set. That way, we can quickly notice that bibo:Patent is equivalent to umbel:Patent. We can also see that both classes belongs to (sub-class-of) bibo:Document, umbel:PropositionalConceptualWork and umbel:ConceptualWork, etc.

We have to keep one thing in mind that we made clear in the UMBEL technical documentation: UMBEL has its own view of the World. UMBEL’s subject concept structure is its view of the World. So these linkages are consistent within the UMBEL framework. Now, let’s continue.

The Context

Remember the three points above? What we have done here is to put BIBO in context. The context is created by the UMBEL conceptual framework. Once this is done, we can check for the coherence between BIBO, UMBEL and all the other ontologies that are linked to the framework.

The figure below shows the context created by UMBEL for BIBO, FOAF and SIOC (click to enlarge the schema):

Considering the current description of these three ontologies, we know that bibo:Document is equivalent to foaf:Document. But there exists no relationship between these two classes and sioc:Item and sioc:Post.

Intuitively we know that there are some relationships between all these classes (at least based on their label). We also have to keep in mind that it is not because a description is not defined (in RDF) that this description doesn’t exist (this is the open world assumption).

That being said, the figure above shows how UMBEL can help us to find such “non-described” relationship between classes of different ontologies. By contextualizing these three ontologies we now find that all these classes are sub-classes of umbel:ConceptualWork. We also know that some sioc:Post belongs to umbel:PropositionalConceptualWork (things written), just like some bibo:Document and foaf:Document stuff.

This means that this linkage — this contextualization — of external ontologies now gives us a common ground to play with: umbel:ConceptualWork. By querying this subject concept we can come up with a full range of related things: BIBO, SIOC and FOAF stuff.

For example, take a look at the section “Narrower External Classes” of the umbel:ConceptualWork detailed report and extend the list of external classes (click on the ‘All Classes . . .‘ link). All these things are conceptual works. This fact is explicated by UMBEL even if no relations, or a small number, is described in these ontologies, related to the other ontologies. Also take a look a the list for umbel:PropositionalConceptualWork.

This also shows the coherence of the design of each ontology.

The Coherence

So, once we have the context in place, we are on our way to achieve coherence. UMBEL is 100% based on OpenCyc and Cyc, which are internally consistent and coherent within themselves. We thus use these coherent frameworks to make the mappings to external ontologies coherent, too.

The equation is simple:

“a coherent framework” + “ontologies contextualized by this framework” = “more coherent ontologies”

This context and this coherence helps us to develop ontologies in two ways:

  1. It helps us to make sure the design of an ontology is good
  2. It helps us to make sure the designed ontology is coherent with other existing external ontologies

For example, when I linked BIBO classes to UMBEL subject concept classes, I found that a bibo:Series was a sub-class of umbel:ConceptualWorkSeries. Then I found that bibo:Periodical was the same thing as a umbel:PeriodicalSeries. However I had an issue: a bibo:Series was a sub-class of bibo:Collection and bibo:Periodical was also a sub-class-of bibo:Collection. Then I found that umbel:PeriodicalSeries was a sub-class of umbel:ConceptualWorkSeries. Then the question arose: why bibo:Periodical is not a sub-class of bibo:Series instead of bibo:Collection? This is what I will propose for the next iteration of BIBO.

Now, what about this helping to increase the coherence between external ontologies?

One good example I have is related to SIOC and FOAF. When I linked SIOC to UMBEL, Kingsley asked me why I didn’t link sioc:Item. My answer was simple: I can‘t do this since if I make this linkage, the coherence of UMBEL will be disturbed. The problem was that sioc:Item was a sub-class-of foaf:Document. But considering sioc:Item‘s definition, and foaf:Document‘s definition and linkage to UMBEL, by making the linkage of sioc:Item to UMBEL would create some incoherence in the framework because of its relationship with foaf:Document.

From this discussion with Kingsley, this thread appeared on the SIOC mailing list, and the link from sioc:Item to foaf:Document has been removed.

These are the two general cases where UMBEL, as a coherent framework, can help the development of ontologies.

So, by achieving points (1) and (2), we are on the way to achieve point (3): the coordination of the development of ontologies and the cooperation of the agents working on these ontologies projects is effective to achieve goals (1) and (2).

The Final Mapped Relations

So, after application of this process and thinking, here are the UMBEL-BIBO mappings:

You can look at Appendix A to the UMBEL technical document (PDF or online); additionally you will see similar mappings for the existing dozen or so ontologies presently mapped to UMBEL. In combination, these give us the ability to ‘Explode the Domain‘!

Descriptive Subject Concepts: Icing on the Cake

All of the description above relates to the mapping between the BIBO and UMBEL ontologies (and therefore other external ones). But, of course, we also now have the full scope of UMBEL subject concepts that we can also now apply to describe what the actual BIBO citations are about.

So, while we have structural ontology relationships that can be leveraged, we also now have a common vocabulary to describe the subject matter of what these citations are about. Use of these UMBEL subject concepts now allow us to cluster and retrieve citations by subject matter.

In this manner, UMBEL becomes a consistent tagging vocabulary for describing what citations and references are about. Want everything about weaving or galaxies or opera or anything, for example? Simply characterize your citations by appropriate UMBEL subjects and then use them as part of your retrieval filters.

This makes clear that UMBEL is some kind of Hydra: it can be used as a conceptual framework to help make ontologies (vocabularies) coherent and consistent, and at the same time, it can act as a conceptual description framework that describes the “matter” of things. This means that a subject concept can describe the “nature” of a thing and the “matter” of another thing at the same time.

Conclusion

UMBEL is becoming a wonderful tool that can be used in many ways. It is a vocabulary that is instantiated in a subject concept structure. It can be used not only to categorize things and to help find things, but also to define things, and to develop ontologies that define other things. We are on our way to achieve these three goals:

  1. Develop ontologies that are in context
  2. Develop ontologies that remain coherent
  3. Coordinate the development of ontologies and the cooperation of the agents working on these ontologies projects sufficient to achieve goals (1) and (2).

As usual, I’d like to thank my UMBEL co-editor and colleague, Mike Bergman, for his discussions and assistance on this material.

UMBEL version 071 Released

Frederick Giasson

We have just released a new version of UMBEL (v 071).  This new version is based on a new version of OpenCyc that has been updated with the latest knowledge base version 5014. This is the latest version of OpenCyc they released after we met Cycorp and the Cyc Foundation a couple of weeks ago in Austin. In the meantime we also fixed some things and enhanced the UMBEL concept structure.

Here is the list of changes and fix:

  • The UMBEL subject and abstract concept structure is based on OpenCyc kb5014
  • The UMBEL namespaces changed
  • UMBEL subject concepts now link to OpenCyc classes and individuals
  • The UMBEL generation scripts now uses the OpenCyc external IDs
  • Duplicated lines in the file umbel_cytoscape_vXYZ.csv have been removed
  • The linkage of BIBO to UMBEL has been completed
  • The linkage of FOAF and SIOC to UMBEL has been revised
  • The encoding of the character “%” in the named entities dictionaries N3 files has been fixed
  • The UMBEL technical documentation has been updated according to this list of changes.

Now lets talk about some major changes of this new release.

New UMBEL namespaces

We changed the UMBEL namespace URIs to be more consistent moving forward. Here is the fuller rationale:

“Here are the URIs of the namespaces used to describe the UMBEL Ontology, the subject concepts structure, the named entities defined in UMBEL and the semsets for both the subject concept classes and named entities.

The folder structure of these classes of URIs has been generalized to meet the design goals of using UMBEL with domain extensions. The portion “/umbel/” in the URIs is a placeholder for the name of these extensions. Each extension, including UMBEL itself, will share the same identification structure. An example for a ‘Foo’ domain ontology at an alternative example.com domain using the “/foo/” folder extension is shown in the table below.

The UMBEL Ontology vocabulary URI uses a “hash URI” for convenience purposes. This facilitates the retrieval of the document of the descriptions of the vocabulary for tools that consume such documents. However considering the size of the subject and abstract concepts descriptions files, the named entities and semset files, we choose to use “slash URIs” so that consumer tools do not have to download the description of all subject and abstract concepts, named entities and semsets descriptions when they request the description of one of these resources.”

The new namespaces are defined as:

Name

Abbreviation

URI
UMBEL Ontology

umbel:

 http://umbel.org/umbel#
Subject Concepts

sc:

 http://umbel.org/umbel/sc/
Abstract Concepts

ac:

 http://umbel.org/umbel/ac/
Named Entities

ne:

 http://umbel.org/umbel/ne/
Semsets

semset-xyz

 http://umbel.org/umbel/semset/xyz/
Example, English semset

semset-en

 http://umbel.org/umbel/semset/en/
FOO Ontology (a domain ontology based on UMBEL)

foo:

 http://example.com/foo#

We now consider these new URIs as “frozen”. So please update your application with these new URIs.

UMBEL subject concepts that link to classes and individuals

In some edge cases, UMBEL considers that an OpenCyc individual is a subject concept or an abstract concept. This means that not only OpenCyc classes can be selected to be UMBEL subject concepts, but OpenCyc individuals can be as well. The definitions of UMBEL subject concepts, abstract concepts and named entities guide how the corresponding OpenCyc collection (“class”) or individual is treated. If an UMBEL subject concept is related to a OpenCyc collection (“class”), then the linkage between these two resources will be done with the property owl:equivalentClass. If an UMBEL subject concept is related to a OpenCyc individual, then the linkage between these two resources will be done with the property owl:sameAs. Check the volume 2 to know what we consider as subject concept, abstract concepts and named entities.

Use of OpenCyc classes’ external IDs

UMBEL subject and abstract concepts names have been used for convenience only. When a new version of UMBEL is created, the “external IDs” of the OpenCyc classes are used to link these classes to UMBEL subject and abstract concepts. That way, if their naming conventions change from an OpenCyc version A to a version B, then we are still able to update the proper UMBEL concepts according to their new OpenCyc definitions. Note that the OpenCyc external IDs are only used when we create a new version of UMBEL. Otherwise the URIs of the UMBEL subject and abstract concepts use the “human readable” labels to refer to the concepts.

Linkage between OpenCyc and UMBEL

We have to note that OpenCyc added linkage from the OpenCyc classes to the UMBEL subject concepts classes. This means that if someone dereferences OpenCyc classes URIs, they will have a reference to UMBEL subject concept classes via the property owl:sameAs.

Still to come

While much progress has been made in this new version 071, there are some pending issues and tasks not in the current release:

  • Complete Web service and endpoints release (forthcoming in a few days)
  • Re-inclusion of company provinces, states and territories
  • Automatic instance checks to ensure better coverage of more specific concepts in the ontology.

We are continuing to work out test and automation procedures with Cycorp and will incorporate these improvements as well in subsequent releases.

Conclusion

This new release is one more step in the good direction. UMBEL is getting more and more stable. Its relation to OpenCyc is stronger and stronger. And its linakge to external ontologies is bigger and bigger. Please report any issues, comments or suggestions on the mailing list.

Starting to Play with the UMBEL Ontology

Frederick Giasson

 

I am really proud to announce the first public release of the UMBEL Ontology and its subject structure after one year of hard work with Mike.

As UMBEL is introduced in the UMBEL Technical Documentation:

“UMBEL (Upper-level Mapping and Binding Exchange Layer) is a lightweight ontology for relating external ontologies and their classes to UMBEL subject concepts. UMBEL subject concepts are conceptually related together using the SKOS and the OWL-Full ontologies. They form a structural ‘backbone’ comprised of subject concepts and their semantic relationships. By linking external ontologies to this conceptual structure, we explode the domain of the linked classes by leveraging this conceptual structure.

UMBEL defines “subject concepts” as a distinct subset of the more broadly understood concept such as used in the SKOS/OWL-Full controlled vocabulary, conceptual graphs, formal concept analysis or the very general concepts common to many upper ontologies. We define subject concepts as a special kind of concept: namely, ones that are concrete, subject-related and non-abstract.

UMBEL contrasts subject concepts with abstract concepts and with named entities. Abstract concepts represent abstract or ephemeral notions such as truth, beauty, evil or justice, or are thought constructs useful to organizing or categorizing things but are not readily seen in the experiential world. Named entities are the real things or instances in the world that are themselves natural and notable class members of subject concepts. More detailed distinctions are provided under Terminology and Definitions below.”

Mike Bergman wrote a really good introduction blog post about UMBEL that lists all the supporting material and services that exists to get starting with UMBEL.

In this blog post I will write about one example that shows how to leverage UMBEL in two different ways: (1) how to use UMBEL to “explode the domain” of an existing ontology and (2) how to use UMBEL when an ontology doesn’t exist to describe a certain domain. I will also write other blog posts in the coming days to show more ways to leverage UMBEL in different settings and how to use it to solve other kind of real world problems.

Some of this new material will begin to hint at Zitgist’s own plans for using UMBEL.

Linking FOAF to UMBEL to explode its domain

How many times have people tried to use FOAF to describe organizational entities? In the end, everything ends up being assigned to foaf:Organization. A company, a NGO, or any other kind of organizations were all foaf:Organization(s) or foaf:Group(s). In most cases the result was unsatisfactory and everything ended up being the same “classification”.

But I don’t want to describe a business as an “Organization”, or a NGO as another “Organization”. They are two quite different concepts, even if the upper concept that links them is an “Organization”. However, there are no ontologies (that I know of) that describe businesses and NGOs; and FOAF is not expressive enough to do that distinction. However, is it FOAF’s goal to be that expressive? Possibly; but not in its current state. So what we want here is to extend it: to explode its domain!

And, it is what we will do with UMBEL.

The goal is to link FOAF classes to UMBEL subject concepts so that we can extend FOAF’s classes with more general and more specific concepts such as Business and NGO.

If you take a look at how the FOAF ontology has been linked to UMBEL, you will notice that a foaf:Organization is equivalent to an sc:Organization. Note: the linkage of external ontologies classes is consistent within UMBEL. It is UMBEL’s view of the World.

Let’s take an example to show what I mean. What I want is to describe the Zitgist LLC business; to describe it as a business, and not an organization. However I want to be able to re-use properties described in other ontologies to describe this business. So, here is an example of how I can describe this company using a UMBEL subject concept and external ontologies properties:

<http://zitgist.com/about/> a sc:Business ;

foaf:name “Zitgist LLC.” ;

foaf:birthday “2006-10-20” ;

foaf:logo <http://zitgist.com/imgs/zitgistlogo2_110_55.gif> ;

foaf:fundedBy <http://www.openlinksw.com> ;

bio:olb “””Zitgist provides quality Linked Data products and services. Linked Data is based on open standards to interconnect any form of relevant information on demand and in context. Zitgist’s capabilities range from the consumer Web plug-in zLinks to enterprise linked data transformation and deployment. Our expertise spans from data, standards and protocols to tools, user interface design, and scalable architectures. Zitgist innovation helps make the connections that matter. Let us show you how our approach to Linked Data can bring the power of the network effect to your data assets and global information.”””@en ;

foaf:based_near [ geo:Point [geo:lat “42.455”, geo:long “-71.218”] ] ;

foaf:homepage <http://zitgist.com> ;

foaf:made <http://umbel.org/about/> ;

foaf:made <http://browser.zitgist.com/about/> ;

foaf:made <http://pingthesemanticweb.com/about/> ;

foaf:made <http://musicontology.com/about/> ;

foaf:made <http://bibliontology.com/about/> ;

foaf:made <http://talkdigger.com/about/> .

As you can notice with this example, Zitgist is defined as a sc:Business. Well, you are probably wondering what is a sc:Business? Let’s take a look at the subject concept’s detailed report: sc:Business.

The next question is: why can I use all these properties to describe a sc:Business? The quick answer is because foaf:Organization is linked (equivalent to) sc:Organization and that sc:Business is a sub class of sc:Organization. You can read the proof here; and check the figure below that shows the inference path that leads us to this result.

(Note: this is what we refer to: exploding the domain of FOAF)

Analyzing a SC with the Detailed Report

The Detailed Report web service tool helps users to check which external class is linked to which subject concept and the nature of the linkage. Additionally it helps people to know what properties can be re-used to describe an individual of that class. Here is a quick overview of what information can be accessed when using this detailed report tool. Let’s take the sc:Business detailed report page:

Named Entities

The Named Entities section lists a couple of named entities that belong to this subject concept class. These are direct, or inferred, Yago named entities that belongs to this subject concept.

More General External Classes
The More General External Classes section lists the external super-classes linked to this subject concept. So we can quickly notice that a sc:Business is a foaf:Organization, a foaf:Group and a foaf:Agent.

In-domain-of and In-range-of
The in-domain-of and in-range-of sections list the properties, defined in some external ontologies, that can be used to describe that subject concept. So most of the properties that I used to describe the Zitgist business above should appear in this list (except if the ontology hasn’t yet been linked to UMBEL; but a dozen are already so as shown in Appendix A of the main technical document).

More General and Specific Subject Concepts

The More General Subject Concepts and the More Specific Subject Concepts sections list the super-concepts and the sub-concepts of the current subject concept (sc:Business in that case). So, we can use UMBEL to describe an even more specific kind of business, for example: an Airline Company. Or we can use UMBEL to describe a more general kind of business: a Commercial Organization.

Finally this Detailed Report Web Service helps people to put a given subject concept into context: how it is related to external ontologies classes; how we can use properties to describe individual of these concepts; how is it related to other subject concepts? It is the tool to answer these questions.

Conclusion

In this blog post we saw how external ontologies classes can be linked to UMBEL to explode their domain: so to enhance their expressiveness. Additionally we saw how to use UMBEL web services to analyze a subject concept and to see its relations with other subject concepts, external classes and properties.

However this is just the beginning of our exploration of UMBEL. Many things are waiting for us at the corner. I am starting to write a series of blog posts that will show you different uses and characteristics of UMBEL. All of them will be explained using real world use cases and challenges. We will see how named entities are related to UMBEL subject concepts. We will see how named entities data sources such as Yago and the John Peel Sessions have been linked to UMBEL. We will see how the UMBEL Vocabulary can help people to describe subject relationship between: a RDFS class that can be linked to a subject concept (using umbel:isAligned and owl:equivalentClass); a named entity to a subject concept (using umbel:isAbout and umbel:linksEntity); and a named entity to another named entity (using umbel:isLike and owl:sameAs).

As you can notice, this is just the beginning. In meantime you can read the technical documentation to have a better understanding of UMBEL. And additionally you can read all the volumes that have been written to explain UMBEL’s evolution and the steps that lead to the creation of this of this first public release of the ontology.

Finally, you can now start using UMBEL in your own applications. I would suggest you to revisit the UMBEL web services by reading my previous blog post: Exploding the Domain: UMBEL Web Services by Zitgist. Additionally I would suggest you to try to dereference subject concepts URIs such as: http://umbel.org/ns/sc/Project and http://umbel.org/ns/sc/Organization. All UMBEL Vocabulary’s classes and properties are dereferencable. All UMBEL named entities are also dereferencable along with all subject and abstract concepts.

Enjoy!