This page is intended to support the process of improving and validating the use and representation of values across FIBO. Values in this regard may be distinguished from “entities”; values are immutable and non-temporal, their identity is fully defined by their immutable content. Values includes xsd defined literals, FIBO “Business Facing Types” (BFT) and OWL classes representing values. A common abstraction and representation for value classes is defined in the ontology “Values.rdf”, however that ontology has issues that must be resolved. A process is required to make FIBO consistently follow current polices.

Factors to be considered

·        Maintaining (and improving) consistency and validity across all of FIBO

·        Changes impacting OMG specifications

·        Changes impacting current use of FIBO

·        Understandability & Simplicity

·        Capture & use of stakeholder terms and concepts

·        Consistency with referenced standards

·        Semantic precision

·        Technology and data representation independence

·        Business Facing Types is now thought to be undesirable and should be deprecated

·        Balancing consistency with ontologists preference

Related Issues

•                 FND-91

•                 FND-151

•                 FND-99

•                 FND-103

•                 FND-107

•                 FND-157

Current state of baseline (FIBO Master)

·        There is a lack constancy across FIBO in the use and representation of FIBO values.

·        The current Values.RDF redundantly defines concepts covered in established ontologies and has other issues previously documented.

·        It has been established that a repaired Values.RDF should be use as the foundation for FIBO classes representing values.

·        It has further been established that xsd literals and datatype properties may be used when there is insufficient semantic leverage in using value classes (noting that this is subjective)

·        Existing use of BFT was mechanically changed to use Values.RDF across much of FIBO (101 Ontologies) resulting in undesirable patterns – arbitrary use of classes where literals are sufficient and failure of existing classes to subclass “Value”.

Statistics to help evaluate scope and impact

(Some are approximate – raw data is available)

·        Types in Values.rdf are used 560 times across 101 ontologies

·        XSD data types are used 146 times across 102 ontologies

·        BFTs are used 64 times across 15 ontologies

·        There are also thousands of uses of XSD types in individuals and metadata

Recommended changes

·        Type substitutions as defines in the [Values Substitutions Page]

·        Consistent use of Values as defined in the [Values Review Page]

Process summary

·        Come to agreement on the changes to be made (this page). Note decisions are required for items marked “Choice”.

·        Branch from “Master” and validate that it passes all tests as-is

·        Ensure that CCM models are up to date with branch

·        Make the substitutions detailed in the Substitution List

·        Export impacted ontologies

·        Review and validate Values.RDF

·        Validate changes with Protégé

·        Check into branch to kick-off full validation

·        Inspect validation & review by FND team

·        Further validate with use of individuals per Elisa’s Suggestions for validation

·        Check-in any modifications

·        FND Team to review & modify each of the ontologies on the “Values Review Page”

·        Check in and repeat validations

·        Complete with pull request

Other Choices


·        To fold “Value” and “AtomicValue” into one class with an optional “hasValue” property.


·        Further review of ontologies using BFT


  • No labels

5 Comments

  1. Cory Casanave

    The following should be resolved prior to proceeding with changes. I suggest we try and resolve these issues here, without requiring another meeting. Can we get comments/consensus by 11/28?

    Value & AtomicValue - Atomic value is a subtype of Value that has exactly one hasValue. Pete suggested folding this into Value thus removing one subclass but weakening the semantics somewhat (or requiring each subtype to add a restriction). My preference is to leave it as-is but am open to consensus.

    Namespace for Values ontology: Currently in utilities-ext. Could move to utilities. Elisa suggested combining with business facing types. My preference is Utilities but am open to consensus.

    name of "hasValue" property: as suggested by Marcel (under values review).

  2. Mike Bennett

    Namespace: Utililties.

  3. Mike Bennett

    Atomic Value has more semantics. Elisa says it is not usual to have in an ontology though. Will not have been nailed down enough for people to know how to use this element. The range needs either to be RDF Literal or some top level datatype, otherwise the property becomes classified as an object property. It is the case that it is a datatype property. Needs some value otherwise reasoners classify it as OWL Thing making it an Object property. This relates to the class Atomic Value. There is also a property hasValue which is a datatype property whose range is the top level of the kinds of datatypes - however there is no a single top level thing we can sue, so we would need to create a union of datatypes. Datatype property with no explicit range does not have clear implications - it depends on the reasoner. Needs testing in OWL on target reasoners before we lock down either of the options. 

    This requires a further meeting (PR, EK and CC to schedule and meet). Either way it can't be left as it is. 

    Also the things Marcel was suggesting is not allowed in OWL (See 3rd issue)

  4. Mike Bennett

    The above discussion relates entirely to a 4th question. The question of Value v Atomic Value.

  5. Cory Casanave

    Elisa added another issue that where a datatype property has no range (hasValue has no range), some reasoners may incorrectly infer that the range is "Thing" and  that this property is an ObjectProperty.

    This was tested and resolved as not an issue.