2019-03-26 Meeting notes

Date

26 Mar 2019

Attendees

• Tahoe Blue

• Bobbin Teegarden (Unlicensed)
• Pete Rivett
• Maxwell Gillmore (Unlicensed)
• Mike Bennett
• Elisa Kendall 

Agenda

The main agenda for this week is to review and triage open Jira issues.

1) Open Action Items

2) JIRA Issues Review and triage

3) Road map. 

4) Next Meeting.

Proceedings:

Note: In the end today’s discussion was focused on comments and discussion arising from the ‘News’ slide in the slide deck, leading to a discussion on how to manage the controlled deprecation of informative conceptual model matter that is no longer required.

Elimination of Redundant Conceptual Extensions

Action: PR will do a query or search or similar, and we will use this next week to eliminate places where an Ext ontology concept is only used in another FND Ext ontology.

Temporality (past and present, values v parameters)

Also we need to align on the transformation from conceptual temporal concepts to pragmatic FIBO Release style e.g. in IND versus what we recommended in the FIBO Equity Pricing workshop.

For the most part there are already things in FinancialDates that can be used, and / or things that are collection constituents that are dated.

Other Concepts for Deprecation

Depends on the things we want to replace. See e.g. BusinessExt - there are also things in CIV and BP that use these things.

Jeff Braswell: Common concepts ? from ?

Discussion on whether 'we' should pre-emptively visit things like CAE and CIV and replace or deprecate the Ext terms in FND that these need.

EK for example we can deprecate things like Message in CAE that is moot and rarely used.

EK similarly Address, is mainly in FBC. This would take care of some of the Ext ontologies in InformationExt in FND, as well as PlacesExt, where references to Postal Address may now be moot.

Process Considerations

Q: What is our mechanism for knowing when to remove things in PlacesExt because FBC has already dealt with it?

EK: Best answer is for that FCT to raise an FND Jira to eliminate the content that was no longer needed.

So the Jira would say 'nothing other than in FND references these things'.

MB: even easier if for each FCT they raise the Jira to say it is no longer needed in their domain, and FND can monitor for when all domains are complete. We can then also spot the simpler cases where a given concept is no longer needed.

If we were to push abstractions down to another FCT, e.g. Strategy only being used in CIV, that would still pre-empt a design decision about having non domain specific concepts within a given domain.

We still need to get rid of the mis-named Quantities (Securities Quantities) ontology. The need for talking about quantities of securities is already covered elsewhere so we can get rid of this one as a quick win.

PR: Similarly the property where ‘party becomes other party’ or similar.

Q: How do we identify when we have a new design solution for a conceptual issue, and identify other conceptual model content that can now be deprecated?

EK this requires some bandwidth.

Example: Physical

The ‘Physical’ ontology in FND is only referenced by other FND ontologies that themselves are in Ext. So that can be deleted right away.

How to tackle this case: raise a Jira, delete the thing, delete the references to the thing.

How to delete the references to such a thing, in FND?

In the case of Commodities, we already added Precious Metal, in CurrencyAmount, but removed the parent, which would have been the above.

It is under Commodity, under Negotiable Commodity.

Did we decide whether to remove the 'Relative' notion that would have applied to Economic Resource, in operational FIBO?

EK explains the model as it stands. Includes Regulated Commodity and Negotiable Commodity. Precious Metal is a child of Negotiable Commodity. Includes the 4 metals in ISO 4217. Those have codes associated with them.

These are framed as Independent Thing.

So that physical one is a candidate to remove, along with many of the other things in that ontology, if any.

Addresses (see also Jira)

Other candidates include address sites, geophysical things. These contain concepts that are mainly but not all been eliminated. There are some remaining notions needed for Real Estate.

For some Address things, there are concepts in BusinessRegistries, but the properties there don't have a Domain, or maybe PhysicalAddress is in the Domain, so these can be reused. These are already being reused for other concepts.

We also decided not to use relative notions for e.g. delivery address, headquarters address (as recommended by Dave McComb). In BE we used hierarchies of properties instead.

The GLEIF ontology has a hierarchy of address properties such as legal address headquarters address. So this is the same as in FIBO BE

This mingles the concepts of addresses, uses and locations. This can cause confusion.

These are different purposes for the same location, while the address and location are the same.

EK: we have the notion of Site, for this.

PR: in the GLEIF model you can have different addresses all referring to the same physical building. This would also support e.g. UPS, GPO etc. having different ways to describe the same thing.

This would be the topic of the FIBO pattern we talked about, that we talked about doing a PoC for at some future point.

JB: These can and typically can be different locations, not always the same. Also in GLEIF, another aspect is that for the same address there can be different types of representations of that - a typing of different types of thing.

JB: this includes different transliterations of the same information constructs as different data typing.

Sub typing of data elements versus standards for the layout of addresses versus the information constructs that make up a composite address.

Physical (revisited)

PR: PhysicalExt is used only by 4 other ontologies are all Ext and are all in FND.

This confirms that the use for which this was present, commodities, has now been redesigned in line with FIBO operational ontology design rules, and the conceptual elements can be eliminated.

Summary / Decisions

Next week we will focus on identifying things that are informative extensions and that cacn either be removed right away as not being used, or for which there is a quick route to removal, such as if there are one or two references in an unadopted domain (such as CIV), replacing the reference there with something textual so the knowledge is not lost, and then eliminating the reference and the extension class.

Action: Pete will bring a report to next week’s meeting showing all the cases where some class or property in Ext is referenced only by something else that is itself in an Ext ontology and in FND.

We will also need to describe to other Domain FCT leads, our preferred process for identifying when they have made a design decision in their domain that allows an informative Ext element to be deleted in FND.

Action items

• Pete Rivett bring a report to FND FCT call of 02 April showing all Ext classes and properties that are only referenced by other Ext classes, restrictions or properties.