2015-07-27 Meeting notes

Date

27 Jul 2015

Attendees

Decisions

Proceedings 20150727 FIBO FBC FCT.docx

20150727 FIBO FBC FCT

At the end of today a new draft of the spec will be posted to the wiki. Everything else to date is already on the wiki. Elisa has posted stuff related to changes needed in Foundations.

Today: will look at proposed structure of the tables in the spec need opinions on this.

Slide 3: recap is revised slightly: We will now have a small products and services module in FBC with financialspecific product and service concepts. Client and accounts will also be looked at to see if some can be moved to Foundations/accounting as non financial industry specific, or now.

New ontology for FBC: Need to revise Quantities, now called QuantitiesAndUnits with a new module. This work was completed yesterday but not yet posted to Pink. For Products and Services, Elisa can ove 90% of it intact to Foundations. 2 classes won't move, everything else can. Is now refactoring what’s left and determining the impact on the other FBC ontologies. Payments ad Schedules has no dependence on BE and onyl depends on Foundations so this has been moved in its entirety to a new module in FND. Languages and Countries has been moved to LCC. Slide 6 refers to the LCC work above.

Not sure how to do this in Github. Not clear how to manage non FIBO namespaces in GitHub. MB notes there is an existing issue on non IBO stuff e.g. WM, which this may relate to (this is with Dean). Dennis notes we also need to talk to Jacobus on this.

Slide 7: First action refactoring, is largely done but not posted to GitHub. Needs to revise what's affected by this in FBC. 2nd bullet: recncile with BE is waiting on David and Dean merge / comparison exercise. Elisa has promised them a list of things FBC is working on for this. 3rd bullet, Elisa and Gareth will follow up this week. Would include things like ECB, BoE etc. which as individuals would go into the jurisdiction specific work. 4th bullet better parent for License needed by the end of this week.

Action: MB will do this before the end of this week.

5th bullet (services list): Get material from Steve Creek and from Gareth on these. There are some dramatic differences so its hard t identify possible common abstractions for these. There is a distinction between the concept of a service, the relations between services and who regulates them (which will vary hugely without commonality), and the regulationspecific definitions of concepts, which are often not to be taken as definitive of the concept in its most semantically pure form. We need the top level scaffolding i.e. the idea that a service may be regulated by some regulatory body.

Final bullet; the draft spec. This is in progress. Current draft will be posted to pink. This will be the current draft of the RDF/OWL, whereas the current draft of the written spec is not what is posted to GitHub at this point. These ontologies need LCC before they can be posted. So this is dependent on the agreement with FLT / Jacobus about how to manage non FIBO namespace in GitHub. The draft spec itself, will be uploaded to the wiki not t GitHub. This will be the current draft. This may alternatively be done in JIRA. We are not using GitHub for change management for written documents. We are not using GitHub for management of binary files such as Word documents as there are no benefits to this. See Meeting Notes wiki page: Guidelines on what goes where (1st action on Meeting Notes page) is one foe the FLT.

2nd issue refers to the refactoring move non financial specific products and services to Foundations. See FBC19. Parts of this may move to Accounting. However some of the current abstractions have dependencies on BE, that are accounting concepts.

Schedules MB questions why this needed to move to FND. Interest accrual schedules would need to be in FBC as these are financial. Elisa proposes to move payment schedules to FND. Transaction, was in Products and Service which is merely defining an occurrence kind which is an event, and is evidenced by a confirmation. FND has done the work on occurrence kind and the like. The definitions for e.g. Transaction are based on Barron’s. We would have to review these and make sure they correspond directly to the abstractions we have agreed upon. Similarly for Payment and Payment Event.

Obligation already defined in FIBO. The Barons definition of Obligation corresponds to what in FIBO already is

Commitment. Elisa and Mike need to collaborate on this, since the conceptual work has all been done and is ready to use, so work in BC should draw upon that.

Payee and payer have been modeled independently of the existing material. This is all very high level, but needs to correspond to the existing abstractions. FBC cannot wait for an RTF so this work will be added to Foundations as part of the FBC submission, as per the process we already agreed.

Next issue in the Meeting Notes page: BE Reconciliation. The last action in the wiki is done.

JIRA open actions / issues:

FBC2: Buys from etc. does not align with the lattice. Elisa will work on an example using a trade and work through this with David. Will define why these need to be not independent agents. Best example on this is a trade, esp. a back to back trade, where a bank is acting on behalf of a client to purchase something for that client, so then they are the buyer and then they sell it to the client whereby they are the seller, in the same trade process. Another example is when a bank is trading internally. There is existing published work no internal transactions in the REA ecosystem. This is why these have to be between parties in roles as we have from 2 different banks already. These leads to relations between parties. Dean is still digesting similar patterns to this, in the work with MB. This issue really refers to the partitions and so does not come under the Lattice, in the sense that we now use the word Lattice to refer to the symmetrical patterns for ownership and control. This issue will ultimately be closed with the right language. Open until David agrees.

FBC17: labels revision Elisa working on this week.

FBC19 migration will be done later this week. Also investigate changing the references for LCC in GitHub.

FBC8 open

FBC4 we hope to have preliminary draft today.

FBC10 is a duplicate of 8. Reconciliation Thing already discussed - probably JIRA18

FBC12 Gareth is working on

Slide 8 Homework

Mostly unchanged since last week. Gareth doing gap analysis for EU and UK. Latest versions of ontologies before refactoring are in GitHub. Needs Jacobus's help in uploading the latest revisions.

Patterns we just talked about. Unclear that we need to change anything but would need to co=ordinate with Dean about adding this to the patterns document.

Use Cases (still slide 8): Use Case 1 this is primary use case in FBC for scoping. Will get documented as part of FBC. Relating regulator to the services they regulate to be added to motivation section in the written spec.

KYC still don't have KYC use cases. If Elisa doesn't have more info on these we need it from people on the call. Needs a more detailed breakdown for what this use case requires. For instance, in addition to client and customer one might also need account holder. Needs more scoping details coming out of this KYC use case. Needs a better explanation of what KYC involves, for the motivation section o FBC.

Action: Use case for KYC on slide 12. MB to review and see if this is enough to specify what Elisa needs.

Recap: moved all classes except catalog and regulated commodity, to FND. Moved a bunch of restrictions, some need adding back in FND. Payments snd Schedules moved in its entirely. Also review to what extent clients and accounts need to be moved; the current concepts are specific to financial accounts. Might need a new name for FBC once most of the business and commerce pieces were moved back to Foundations. Need to talk about this next week. However the aspects of products and services that were moved were non financial and what's left is "Financial" Business and Commerce, so this name should be fine.

Slide 19: Correction slide 10 - Status of the draft written spec. May need to revise the Reference section. Section 6 is the first FBCspecific piece. This is in process. Has improved the structuring of the content. 7 and 8 mainly boilerplate (8 is Architecture which will require specific namespaces0.

Slide 13 we look at the spec. Update from the latest submission template. There have been minor changes in the front. Section 0 this is what gets stripped out of the spec when it is submitted. Other stuff maybe out of date and needs review. Or is already known from other specs. Includes unique material on this spec and its dependencies needs to be update to point to LCC. Left in "What is Content" section.

1. Scope: Overview remains unchanged for FIBO, with additional paragraph on what this spec is.

1.2 Scope of this spec written fresh for each spec. Includess relationship to ISO 10962. Definitions section revised slightly. Definitions policy minor change for definitions derived from something other than an existing standard. Barrons scope revised.

2. Conformance untouched. Reference ISO 10962 not clear if this is normative or informative to be decided

4. Terms and Definition’s needs more material

6.3 can be removed.

Section 10: Table refactoring. Used to all be one table for all classes, properties (individuals were not covered). Need to separate classes and properties. for IND we have 1 more column for the Explanatory Note, but left off the term and definition section (a mistake). Now have 1 column for all Annotations, with the definition, and explanatory note and the term and definition origin adapted from, in one column, with labels within the cell for each metadata element. This is the proposal on the table.

See Table 1027 as an example. In the Parent column, rather than use the dummy label or the restriction class, she puts what the restriction is in the parent column. This uses a natural language description of the restriction. These descriptions are currently written by hand, similar to what we did for the definitions for the restriction class entries themselves. We output fibo:explantoryNote but not skos:editorialNote into the table, as per previous discussions. This also eliminates the tables that describes the restrictions, since they are in the Parent column.

Do we need a separate column for Name and Label? Elisa not yet thought of eliminating these. As a user of a spec, she always uses the CamelCase name of the item, she never uses the label. The label can be put in parenthesis in the Name column, thereby reducing white space. So that’s a Yes.

In the Parent column, it's possible for people to misread the description of the restriction as being an explanation of the class name above it. These are separated by white space and are italicized, but is that enough to make the distinction clear?

PR: Would the other teams have a problem using this, or are we proposing new universal approach? This is a proposal for all specs. : Would need to be brought to the FLT.

Is this OMG specific? No. Looking at Properties: There are none in this ontology, so we will have to look at proposals for these in the FLT. Want to get consensus on this approach before taking it further.

Action: DWiz put on FLT agenda. DONE

The solution to the other problem noted above, would be to generate a heading in the Parent Column, between the parent classes and he parent restrictions. MB not yet determined how to do restrictions which are an equivalent class needs to be addressed). Would then also have a heading for Classes in the Parent column.

Which of 2 things to do for Restrictions: one heading 'restrictions' or label each restriction separately as 'restriction'. Pete notes that the written words for this example restriction is not very clear. however, it is the exact wording that corresponds to the restrictions. Mike proposes 'may only be' and 'must be some' as these define the features of a restriction without needing to already know what allValuesFrom means in OWL (the label doesn't help understand this). Look at MB's previous efforts in recent specs.

The meaning of the restriction is that the parent class is the set of things that define all values for classifier? No it is the set of things where all the values for defines are classifiers. Elisa will rework this.

We haven't touched on how a cascade of restrictions will be reflected in this kind of language. However, it does mean we are not reliant on the labels for the blank nodes.

Review: if we do something like this, would Pete like it? Yes. All seem happy with this approach.

Properties still to be done, in line with what we agreed today on classes. Elisa will posts a version of this in the next ay or so, via JIRA. A new JIRA issue will be used to carry this review, and the original JIRA can be closed since there is now a draft.

The different drafts posted in JIRA wil be identified by date not by version, as we are not using version control on these Slides:

Homework (slide 13): Writing up the KYC use cases and figure out where in the spec that goes. Elisa will start a section for that and leave a placeholder for the KYC aspects of it.

Slide 14 Schedule: Next week: more discussion of the spec and relationship between regulated services and regulators. Will continue gap analysis and feedback the following week.

Aug 17th final integration. MB and EK to coordinate tomorrow on the things Elisa needs that FND FCT are

working on so we are in step.

DWiz: Issues whether to defer or move forward? Elisa anticipates that all of these will be addressed by the end of the current phase of work. Some we can work through next week. We don't want to publish a spec with any open issues against it. By 24th we need a draft so if there are open issues these can be addressed after Aug24 but before the meeting in Sept. Has to be largely complete (updates would be in an Erratum.

DWiz: Are things in this spec that are dependent on changes in FND? When are those likely to come up in the OMG? The changes that FBC recommend will be the RFC, saying that this specification modifies that one. So there is no dependency on the RTF. Then we would have a revised Foundations that includes exactly these things and a couple of small fixes, before the end of the RFC period. If we put this forth for people to look at in September with 2nd review in Sept, we need the FND RTF to deliver the specific changes in December. Would this mean there were dependencies on things we were yet to review? No, the point of the RFC can make changes to other specs. As long as we have coordinated as per today's notes and not reinvented stuff, then the Foundations RTF should be happy with the changes. We don't necessarily need to have the changes until the end of FTF1 at the end of March. However, December is preferable. Another view is that until the RFC is approved it's premature to do that, and then it's needed immediately.

PR: How is this orchestrated in GitHub? Note these are additive not destructive changes to existing ontologies. So having them in Pink should not be problematic. Add a 1.1. About file to Foundations that will include these.

Challenge is what to do about currency representation and currency codes. Currency will remain in FIBO so no impact from LCC. Country is in Foundations, so the LCC work would reflect the concept from FBO but not the individuals. However those individuals need Country concept from 3166, not from FIBO. So there is a dependency to manage. There is a dependency from the individuals of type Currency to the individual of 3166 which is now LCC.

Need to fin a way around this. for example, not to include the individuals in the About FND 1.1. but have a separate About file for FND 1.1. with individuals.

This is a open Q for the FLT.

Action items

Mike Bennett MB will do a better parent for License by the end of this week
Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
.
Mike Bennett Use case for KYC on slide 12. MB to review and see if this is enough to specify what Elisa needs Unable to locate Jira server for this macro. It may be due to Application Link configuration. .