Date

04 Jun 2019

Attendees

• Maxwell Gillmore
• John Gemski
• Rob Nehmer
• Bobbin Teegarden
• Mike Bennett
• Pete Rivett
• Robert Trypuz

Agenda

1.News
2.FND Use cases
–Internal – support FCTs
–External – understand industry usage
3.Housekeeping
–Recent Pull Requests
4.FND FCT Roadmap
–Creation of web content
5.AoB

Proceedings:

Guidelines (slide 6)

Need not be mechanical, but need to be formally stated. Not sufficient just to say 'common sense'. Write down what we mean.

Use Cases Review

Actors

PR: Some of the things shown in MB ‘grab bag’ of finance industry knowledge can be considered as ‘Actors’ in the sense used in use cases.

Also include EDM Council as a Third party - customer.

Scope

FND itself could span all the different ontologies that the EDM Council might promote or develop.

Core concepts should be reusable across ontologies, where applicable.

New Use Case - Querying

RN: There is some appeal to end users in having this foundational ontology, as certain queries could use those concepts - e.g. overall contractual exposures, risks etc. (Contracts with a single execution date; contracts of a given form) across Domains. Typical for regulatory, planning etc.

Non IT Usage (use case)

Strategic, business intelligence etc. - not only operationalized things. Makes use of foundational work.

The above is not the same as a local implementation.

PR disagrees. OWL lets you not have to put everything into a single ontology.

Scope

See FND issue FND-253 on corporate law, enterprise goals and objectives and strategy.

MB: The assertion that legal input was not sought is incorrect. These terms arise from conversions both with Oliver Goodenough and with GRCTC legal experts.

MB explains the rationale for these terms – generally needed to provide distinguishing characteristics for other concepts e.g. corporate officers. Without these, would only have terms and written definitions. However, being legal constructs, these do not correspond to data that an application would process or reason over. Again this goes to the nature and scope of FIBO itself.

Foundational Abstractions

There are effectively two kinds of, or reasons for, the semantic abstractions in FIBO:

• Things that are ancestral to FIBO Domain content e.g. contracts, contract terms
• Things that need to be referred to by properties in FIBO Domain content, e.g. dates and times, quantities and units etc.
  • These are themselves positioned within a hierarchy of abstractions to disambiguate these concepts – see e.g. Quantities.

Add to criteria: Distinction between high level abstractions for core content (Contracts etc.) v high level abstractions in hierarchies of things we need to refer to in properties, e.g. quantities and units, math, time etc.

General Comments

FIBO still not fully characterized as conceptual or operational.

Disambiguation – please explain

MB: Identify under what circumstances someone needs to be able to distinguish between things.

PR: Write this description down and use in the documentation we are looking to provide (this answer was fine but needed to hear it).

Decisions:

Action items

• Type your task here. Use "@" to assign a user and "//" to select a due date.