/
2017-11-21 Meeting notes

2017-11-21 Meeting notes

Owned by Dennis Wisnosky
Last updated: Feb 26, 2019 by Mike Bennett

Date

Attendees



Agenda

1) Use Case reminder

2) Where we are on our road map. 

3) Open Action Items

4) JIRA Issues Review - https://jira.edmcouncil.org/projects/FND/issues/FND-48?filter=allopenissues

5) Todays content discussion.

SMIF OWL-UML

SKOS

RDF/S

6) For next week.

Proceedings:

20171121 FIBO FND Special Values Discussion

 

MB summarizes and present the agenda

 

Cory presents on the revised Values ontology. Notes are on the Values wiki page. CC went through all the ontologies in FIBO-Master. Not distinguishing between Released and not released. A lot of things in the BFTs were changed to Values and then exported. Some of these things need, not to be changed back but think about what each of them change to.

 

MB - we need not change every legacy ontology until the FCTs are due to do their work.

 

CC has 2 sub pages - type substitutions and things that need to be reviewed. The substitution page is intended to be done all at once and automated. The intent is to make the current Values ontology consistent, remove some dependencies on it, and make sure it is related to the other Foundations.

 

MB concerned to ensure that a global grep might cause more work to need to be done in the CCM models.  CC we can make the needed changes either in OWL text or in CCM. First identify the changes to be made and then later figure out how to use them.

 

EK: we will need to document every change that effects a Released ontology (need redline for formal updates). We would need to deprecate any types in the BFTs we can't just delete them. CC the things that were changed from BFTs to Values ontology.

 

MB reiterates that BFTs is only in Release. SEC and FBC and DER has things that might also use Values. PR if it is in Values ontology this was Ext so there should be no use of non release Values. CC if is the case that Values is not used in Release, then there are only 15 ontologies that refer to BFTs.  So we could simply not do these changes that talk abbot BFTs, we can leave them alone. CC: where there are only a couple, has listed the ontologies in which these occur.

 

MB the matter of how to apply the new strategy for use of BFTs, might be a job for the FCTs

individually, rather than CC's big bang approach.

 

How to determine if something is Release: see annotation maturityLevel=Release. So it might be simple to apply our new policy on the application of Values. There are 560 uses in 101 ontologies. Most people are currently using the XSD datatypes. The 560 uses of Values have to be adjusted. Having done that, some of these things can be removed from the Values ontology. Many of the things in Values (ex BFT)

 

CC has identified grep-able changes to the dates ones, and identified the new FinancialDates

referents.

 

EK: for changes to BFT in Release, we have to change those slowly via OMG issues. CC this can be done under a blanket issue. This will effect multilpe FIBO specs, and numerous pages in those specs. PR why not do this in FIBO2. EK agrees. All assume this is a FIBO 2 thing,. All agree that it is. We will not change anything of BFT in FIBO1

 

ACTION: CC will segregate the (15 ontologies) BFT substitutions, and we can deal with those

separately.

 

ACTION to Cory from DWiz “Is what we are doing now replacing this or extending this or revisiting this or what?”

https://wiki.edmcouncil.org/display/FLT/Policy+-+FIBO+Semantic+Value+Policies+and+Patterns

 

BasisPointsValue - should not be defined in Values but in something specific to interest rates or

similar.  DayMonthValue to the FD ontology. This would now be an ontological kind of thing, and would be still be a Values type.

 

Not everything from the Values ontology needs to be in the Values ontology.. The non negative integer - used once, straight substitution. PercentageValue - no current usage of the current BFTs one. CC proposes to leave PercentageValue alone. Simple ones like textValue goes to String.  timeValue. TimeValue - one use, so fix it. FND team can that on. That is all the automated substitutions?

 

CC: other things need to be done automatically, after the Time one has been fixed. MB suggests there are things like Name where Legacy has ontological classes but release uses datatypes. Identifier is not such a thing - we always have the class of thing that is the Identifier. So Identifier becomes a sub class of Value. Based on the assumption that all identifiers are text, these should be called TextIdentifier. There are other kinds of identifiers.

 

 MU There are lots of things that have text in them. The one thing you want about the value of an identifier is that it does not change. PR agrees with MU that identifier should not inherit from Value at all, as it does not . MB suggests we do not get to the bottom of these today.

 

CC there are also things on the 2nd page which, once resolved, can be removed from Values. That's why we won't finalize the Values ontology itself until these are all dealt with (or parked by agreement)

 

PR disagrees with atomic value.  CC the Values ontology becomes very small, with mainly just Value, Atomic Value and so on. PR does not like atomic value. Jeff Braswell atomic usually means discrete, values are usually continuous. The AtomicValue matter is part of the roll-out strategy for the new usage of Values. This only needs to be done in FIBO2. PR not convinced we need 2 classes, and Atomic is misnomer. CC we do need a common property for when it is atomic.

 

PR be careful about hasValue.  PR for testing a property we would want to use the qualities of a thing. Are we going to look at the full set of properties? CC this is the reason AtomicValue was there.

CC would prefer to have the decision on AtomicValue set before we do these changes. Where is the ontology? In what namespace? This has not been updated since the xxx OMG meeting.  EK can help CC fix that when we get to the point of fixing it.

 

What else do we need to do about Atomic Value? The hasValue is the same problem. hasValue is in this ontology (not Relations)

Jeff Braswell  atomic value in this context is largely made up of CPU datatypes. In the RDF spec there is another thing that is almost exactly like that. It may or not be allowed in OWL. in a mathematical, how-to-process, sense. There is a conversation to be completed on this, before we finalize Values. We can do the substitutions for Provisional / Ext in parallel with that. i.e., floating point, real numbers, integers, etc.  Nearly everything except this and percentage would either be removed or go somewhere else.

 

EK we had some statistic stuff in IND.. Jeff Braswell perhaps distinguish between concepts of values and representations of values? We can use those in IND as a model for what we do at the more primitive level. Those are functions, i.e. applications of mathematical formulas to underlying values.

 

EK reads out a long list of math concepts that are already in the legacy Math ontology. We need to co-ordinate these FND FCT collaboration with IND.  This is part of the application of the Values policy side of things.

 

Next steps?

Does EK have a problem with how CC separated AtomicValue from the other stuff.

EK probably - let's deal with Atomic Value after that is cleaned up.

 

Jeff Braswell distinctions between numeric value and discrete (text) values are important. MB we will have an interim variant of Values where all the clutter is gone but we still need to deal with the hasValue / AtomicValue.

 

Jeff Braswell the different atomic value types are in fact distinctly different. CC the only thing that will affect xxx is percentage.

 

MB There is a JIRA 28/29 which Dean and Elisa will work on so we won't get to that this time

around either. So that's a separate problem. With the exception of those things from BT, the substitutions and deletions can be made. These impact only legacy. CC will do those. CC and MB will co-ordinate on those substitutions.

 

The only thing we needed to fix by hand on that was Time (time of day) which MB will fix by hand.

 

ACTION: CC will go ahead with the 1st phase and we will re-group.

Decisions:

Action items