Page Comparison

This was spawned by JIRA issue: Use of SKOS Concepts in FIBO 

There are two separate but related issues:

1. How and when should skos:Concept be used in FIBO?
2. How to represent concepts that are used to classify things, when you do not want to use owl:Class, and what criteria can be used to decide which approach to use.

This started when I thought one way to answer the first part of question 2 is to use skos:Concept. It was decided to not do that, instead, to use 

• fibo-fnd-arr-cls:Classifier
  
• fibo-fnd-rel:isClassifiedBy

There are various ways to put things into buckets.   The table below give examples and is drawn from a blog article summarizing this:  Buckets, Buckets Everywhere, Who Knows What to Think?

...

If you are unsure, then start with Classifiers, since it keeps the class hierarchy tidy, and you can always go back and make a class if you need to.

A Tidy Class Hierarchy & Maintaining Facets 

One disadvantage of having a lot of classes, where there are sets of classes, each corresponding to a different facet, is that the information in the facets is lost and the class hierarchy gets large. Compare:

Image AddedImage Added

On the left, you have a flat list of subclasses with no information about underlying facets.  On the right, I manually added the colors to show that they belong together. Using classifier, the hierarchy is much simpler, and each facet is very explicit and easy to see, understand and evolve. 

Image Added

The restrictions on LoanContract tell you what the facets are.

Image Added

Then you can see the values of each facet:

Image Added

Image Added

All of this valuable domain information is hidden in the first approach. If there were just lots of classes, it would be harder to keep track of the facets. This makes the ontology harder to understand and thus to evolve. There is no place to go to add a new loan reason, say BoatLoanContract.   Perhaps there is a way to add it?

How to do it both ways

Let's say we decided to model LoanReason as a Classifier, and later we realize we really want it to be a class.  There will be a subclass of Classifier called LoanReason, and instances as we said above. Each instance corresponds to a type of loan, but now we will also create a class to represent the same thing.

...