The following table identifies ontologies to be reviewed for proper and consistent use of values.

Ontology, Value Class or  property








Business Facing Types


  – review current usage

156 / 15


Not well  supported by OWL, insufficient net value



fibo-fnd-arr-id;TextIdentifier (Subclass of AtomicValue)




Current  IDs assume a text property, create this class to capture that assumption.



Subclass  of Value



Allows  for non-text ID. Issue:FND-91




Review  for subclasses and proper use of values






Review  for subclasses and proper use of values


456 / 61 



Review  for subclasses and proper use of values 



Subproperty  of hasValue or rename to hasValue







Subclass  of AtomicValue






Subproperty  of hasValue




Note Used in  individuals 

Choice:  Just rename to hasValue?




Review  for subclasses and proper use of values and relate to "indices"


287 / 22



Review  for subclasses and proper use of values


56 / 14


Other Choices

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

·        Further review of ontologies using BFT

  • No labels


  1. How was this list obtained?

    In addition to above listing there is also GeographicalPosition. 

    (most of the following comments have already been made in emails)

    • We should also review the meaning of "AtomicValue" since in most subclasses, such as names and addresses, and even URIValue (which can be split into protocol, domain etc) the values are not atomic (meaning indivisible).
    • In XSD, Integer subtypes Decimal – in Values.rdf, both subtype Numeric. That seems wrong in terms of OWL semantics. There is a discussion here
    • It should not import FinancialDates (which it does not even use)(it should be vice versa if those types are to subclass Value as suggested)
    • We have I believe used xsd:string as underlying type for Date in FinancialDates ontology. But we should add some facets to constrain it more.

    • It needs skos:definitions
    • The labels use uppercase – our convention is all lowercase and directly derived from the IRI
    • We need to consider the handling of NaN (not a number)
    • XSD has various facets on datatypes which are not covered
    • Speaking of which, we should, for our own benefit, document what some typical SPARQL would look like after this change:

    FILTER (?loan.amount > ?approvalPolicy.threshold) would I assume become FILTER (?loan.amount.hasValue > ?approvalPolicy.threshold.hasValue)

    • We should also document some policies and rules e.g. does it ever make sense for a node of class IntegerValue not to be a blank node? We should also document that we would never expect Value to be used as a range, or any of these classes to be used as a domain. Alternatively would we ever expect the reuse of values e.g. by declaring resources with URI fibo:TheInteger1, fibo:TheInteger2 etc (if not we should document that)? If a value is updated would we expect a user/programmer to create a new node of type IntegerValue or replace the hasValue triple for the original IntegerValue?

  2. Pete,

    Re: How was this obtained - by me looking about, doing queries across all of FIBO, some archeology. Thanks for the addition.

    Re: AtomicValue - there is Value & AtomicValue. Values that are not atomic subtype Value.

    Re: Integer subtypes Decimal – in Values.rdf, both subtype Numeric. No need to follow the OWL hierarchy, Should be what makes sense for FIBO.

    Agree about import if FinancialDates, XSD constraints, etc.

    Will check label casing and other cleanup stuff when we finalize that ontology.

    What about NaN do we need to cover?

    I had also wondered about "common values" and/or a value namespace, but since we would never use IntegerValue directly (as those are the cases that would use the xsd type), I don't know if they would be very useful. But, we could have a namespace convention for common values.

  3. Unknown User (marcel.froehlich)

    Thanks Cory for the effort taken. Before introducing some FIBO specific hasValue, mind there is rdf:value.

    Minimizing the number of properties overall, creating generic & reusable properties when required and preferably reusing well-known existing properties (from common non-FIBO ontologies), where applicable could declutter FIBO considerably.

    1. Marcel,

      I am aware of rdf:value - as it is defined in RDF and not specific to a datatype property, do we know it is compatible with OWL and OWL tools?

      If so, I would be happy to utilize it.

  4. Unknown User (marcel.froehlich)


    you are right, for OWL reasoning using rdf:value is not a good idea, even if it may work in practice.

    Which is the intended OWL version and profile? rdf:value would probably imply OWL Full (not sure how OWL 2 interprets this).

    A generic value DatatypeProperty is  a pretty weak specification, why not using some indication what kind of value it is, like decimalValue or localDate?

    It looks like the whole Value class hierarchy has been created to  package values as resources to get from a single typed Literal to a more conceptual thing, like e.g. a point in time. But I think insisting that there must be exactly one value misses an opportunity:

    Typically there are potentially multiple data representations for the same thing. Why not allow to represent those?

    Example point in time: Local time in timezone x / UTC time / Posix epoch time. Different DataProperties with different values of the same point in time.

    Another aspect missing is precision, time points can be handled at different levels of granularity, there is no one-size-fits-all (e.g.  high frequency trading vs. web transactions). This aspect is not available yet, but could be added to the value resources. 

    Otherwise it is really overkill to create a Resource instead of a Literal value in the first place.

    If changing anything in FND is considered, we should also take into account that there is now a new W3C recommendation available to refine definitions by provide data validation constraints (SHACL).

    Cheers, Marcel

    P.S. I understand that this suggestion blurs the whole idea of a value type concept. Still the question remains: why create it at all?

    From a practical implementation (with data) perspective it is ugly. You would not want to pump up data graphs like this for no good reason (at least one extra triple PER datapoint, that is a lot). If you argue that this is only the concpetual view, then two new questions arise:

    a) Aren't there more elegant ways to express this aspect that do less harm to actual usage. Like e.g. punning properties with extra meta triples that encode this and could be moved into a separate optional file (iff target is OWL 2).

    b) If this is only the conceptual model, what then is an agreed variant of FIBO we can share for implementations?

    1. Marcel,

      The base definition of hasValue with domain AtomicValue is intended to be abstract. When AtomicValue is subclassed for specific semantic (e.g. Time) and an explicit representation (e.g. UTC Time) hasValue is intended to be restricted to the required XSD type. In this way we always know where to find the distinguished value - hasValue. Classes such as StringValue are intended as convenience superclasses that already have these restrictions.

      As for different ways to represent the same thing; the intent is that the value semantic be defined as a subclass of Value (e.g. AbsoluteTime) and each representation then be a subclass of the semantic value (e.g. UTC Time). There is no SHACL required to make these restrictions.

      Can we bring this to a close?

      1. Unknown User (marcel.froehlich)


        sure, I understand the idea behind this approach.

        This is not the right place and time to question early basic design decisions of FIBO Foundations

        Please proceed, I do not want to hinder your work.

  5. Resolution: This is fine the way it is. The generic Value property is not specific and when you sub type it you can add a restriction as needed. 

    Therefore no change? Cory will review and respond.