Values Review Page

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 https://www.w3.org/TR/swbp-xsch-datatypes/
• 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?
  
  

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.

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.

Cory,

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?

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.