2019-10-22 Meeting notes

Date

22 Oct 2019

Attendees

Agenda

Focus on issues of time and temporality, with a pragmatic focus on temporal concepts needed for ratings and loan terms.

Proceedings:

The Problem Space (Cory Casanave)

Fannie Mae - trying to create an Enterprise Knowledge Graph (EKG)

How to populate from multiple data sources, use in multiple applications. Therefore not a single application but across the enterprise. This is the reason to do ontologies at all.

Ontology is FIBO-influenced. Attempting consistency with FIBO but also driven from internal data conceptualization, sources and models.

Have run into temporal needs. Several places and strategies:

3 things:

1. Ratings:

Assertions at a particular point in time (event based world). World as a series of events. How we want to look at the world: How is it now? What do I owe now? What is Credit rating now?

Relating these 2 things is a challenge.

2. Corporate Relationships

It may be that Company A is a subsidiary of Company B.

But when did that relationship start?

Almost all (all?) OWL relationships are temporal.

For some, we may not know we need it to be temporal now but in future it will.

PR: GLIEF - tracks the relationships. Reify these. Have a start and end date. If the end date is empty, this is a current relationship.

GLIEF is a potential source for Fannie Mae ontology.

CC: First time we reified the relation itself. Found less painful in terms of being able to reason over it, by reifying the Role that a thing plays. Then Role is played over a time period. Strategy is to take slices of the individual over these different phases of its existence. Can reify the relationship, the role or phase it is in etc.

PR: Challenge: Something can be a Subsidiary of >1 other thing. Playing more than one role may then be an issue.

MB: as long as the role is specific to each entity and each other entity then the temporality can be asserted against that without cross-talk with other roles.

See CC screen: Organizational Role as a kind of Business Role which is a Temporal Entity.

The alternative is Roles as multiple classification, which is used in some cases but not others.

PR also dealing with these distinctions with GLIEF. Can explore the trade-offs offline

So putting temporality onto relationships is one strategy.

3. Loans:

If you just model the Loan semantics (properties and relationships wrt a Loan); then the requirement was to look not only at the Loan current state but also at specific points in time e.g. when acquired, when serviced, when closed (lifecycle events). Requirement is to look at snapshots at a given time.

Segregated into things expected to change, things not.

Strategy is to use conceptual abstraction view of the Loan.

Then current state, projections etc. of these.

Then use the Current State Snapshot for anything we need to track historically.

This can be expensive computationally but reflects one of the ways people think about the data e.g. what do I owe now. Points in time.

Continuous change hasn't been a requirement so far.

Other option: Make each potentially changeable property reified.

Every property can have multiple values and these values change over time. Hard to do this for everything in a tractable way.

In FIBO, was hard to do any of these as FIBO seemed to be only a current state function. Needed more than this.

These are the requirements.

Graph Based Solutions

Fannie Mae also has experience with Neo4J - can also put temporal assertions on the edges themselves.

Also looking at RDF* that uses RDF reification that provides some of this functionality.

Q: How does this differ from just doing it in RDF?

A: They are not reifying the entire relationships but based on the semantics of RDF statement - providing RDF serialization syntax and SPARQL syntax to let a triple be used as the subject of a property. Semantically expands into an RDF statement but can be implemented more efficiently. StarDog next release will implement RDF* so you can do property graph queries.

By providing this in the DB you can make it easier to query.

Also provides a marketing answer from the property graph world to the RDF world. Something to watch.

Allegrograph

BT: Allegrograph is a Quint store, one of these addresses each triple.

In a DB you take the identity of a triple and use as the subject of the triple.

StarDog

PR Also StarDog had the ability to do diffs on snapshots. Like GitHub - an effective snapshot so you didn't need to replicate the entire named graph.

This was discontinued. Changed underlying DB to Rocks DB at v7. From that point, no longer supporting this approach to versioning, but will again in a future release. PR liaising with them on this.

Implications

MB: If there are technical solutions (in graph implementations), that would lead us to put less of the solution in the actual FIBO ontology.

PR: If there is a compelling use case we should include it in FIBO.

Requirements as of Now

Loans

Taking the Snapshot approach. Not ideal. Gives an arbitrary choice of what to put in a Snapshot.

Currently leaving this up to the implementation. No good way to model this.

Can also use named graphs for snapshots. Still have the problem of whether to duplicate the entire world for the Snapshot.

For FIBO

Not say there is one approach but recognize the existence of a few approaches and have well defined patterns for doing so. Maybe event superclasses for the Snapshot state.

e.g.

Complete snapshot
Reified relationships
Reified Role
Other?

Named Graphs

Q: Could a named graph be a way of modeling a context for something?

Where is the sweet spot?

In reality, everything changes (see slide). Have to model differently whether you are or not. If FIBO not really general it is not that useful. Engineering for specific use cases you are not engineering for all the use cases you have not yet considered.

Some will only case about the current state of a loan, others will care only about the initiation and so on.

MB we should consider the range of use cases supported. In early FIBO we took the existing data standards as reflecting an analysis of what end user use cases were to be suppoted rather than us trying to catalog them all.

Snapshots and past / present values

On Cory model - the blue box is the atemporal thing and the boxes in yellow are the temporal stuff. These are:

Snapshot (dated past value or values)
Present

So we can do an atemporal model and tack on current states and snapshots.

[Note: this is similar to the conceptual FIBO ideas outlined in today’s slides]

MB we should define this as a pattern and make it a question for the modeler of future FCTs when to use this pattern and when not to

BT: We like this pattern.

NB Snapshot includes time series.

Reification(s)

The snapshot approach above is distinct from reification of relationships.

Outcomes

We should have a pattern for each of these 2 above, with clear naming convention.

We should publish these patterns in FND and let people choose which pattern to use.

Use in MDA

In CCM, we can represent these as reified relationships in UML and generate different patterns based on implementation choice. Write a generator. See reified AssClass elements in CCM. Given support in the database, can use a different pattern as appropriate. This is an MDA approach - implementation choice based on specific implementation requirement. So using FIBO as a means to originate a conceptual model from which to generate these different implementation models.

Use Cases

Loans

Need a proper Use Case in Loans.

CC did write this up wrt Loans. PR responded suggesting that FIBO did not to express these temporal concerns.

Generic FND Use Case

MB can frame this as an FND Use Case.

Corporate Relations Use Case

Also Corporate Relations / GLIEF use case - see FBC for what has been captured there.

Decisions:

Define the range of simple temporal treatments we identified today, in FND, for domain FCTs to select and use as they require.

Action items

Mike Bennettwrite up FND geeric use cases that are satisfied by the identified temporality treatments