interest to develop a CDM Taxonomy?

[llynhiavu]

Proposal

Is there an interest from the community in developing a "CDM Taxonomy" ("taxonomy")

• A taxonomy would be documentation that supplements a CDM version and help users understand and navigate the CDM data model

• In practice, it may look like a tree structure representing all the features/functionality covered by CDM (e.g. products, processes)

  • and (?) how these are to be implemented in CDM

• Someone can get started by reading the extensive documentation, browsing the data model, looking at examples, referring to information in decks, however, there isn't a simpler document that shows the entire model from a "business" perspective, and how to enter it. A taxonomy would bridge that gap.

• This is early stage. At this point, we would be interested in gauging interest and thoughts from people. Please add comments / questions to this issue.

Thank you!

Background

• We recently received queries from prospective users of CDM interested to understand the CDM at a higher level, beyond the data model. Using Rosetta IDE or other visual IDE we can certainly browse the data model graphically which is very useful. However it can be challenging to relate the business concepts to types and models defined in the CDM. A CDM taxonomy could help bridge the gap.
• "While the CDM model and associated terms are described in Rosetta, it would be useful to have a map of the underlying taxonomy / vocabulary. i.e. It would be something along the lines of a list of domains, sub-domains and elements that describe everything in the trade domain. There could be many models that use the same vocabulary, CDM being one of them."

Note

• there would be a new version of the taxonomy for each major version of CDM
• the taxonomy could be broken down into multiple smaller taxonomies managed by SMEs to make it easier to maintain
• in practice it would be an artifact (e.g. diagram, tree, excel spreadsheet, taxonomy tool, ? TBD) available as part of the documentation (?) that developers could use

[LionelSG-REGnosys]

This sounds like a formalised version of the diagrams added to the [https://cdm.finos.org/docs/product-model](FINOS CDM documentation) for the Product Model in CDM 6, for example:

Perhaps there needs to be work to produce such diagrams for the whole model?

[llynhiavu]

Thanks Lionel. Those diagrams are great by the way to help understand and navigate the asset / product. what other areas were you thinking.

For the "CDM taxonomy", was thinking about something at a higher level, that provides some sort of "interface" between what people know (business concepts) AND how it translates to CDM.

I don't know the forum yet but I wanted to socialize the idea at the next CRWG or Derivatives WG or Steerco level. I've been working on a draft visual representation as starting point for discussions.

[iansloyan]

Hey Lyteck - I am sure this idea is on the roadmap so I think it is great. I would probably encourage a different name than Taxonomy. But that is secondary. Do you mean it to be a catalogue of products and processes in common parlance which then decomposes (or composes?) into the relevant CDM components?
Would love to discuss.

[llynhiavu]

Hey Lyteck - I am sure this idea is on the roadmap so I think it is great. I would probably encourage a different name than Taxonomy. But that is secondary.

(Ian, apologies for the delay. I read you input when it came in. Last week was a bit busy. glad to hear your interest. )

• Yes what you are describing is exactly it. a mapping between what people know (business-wise) and where CDM "begins"
• I was thinking higher level as well. Like a mind map (in fact I developed one as PoC) that people can navigate visually and look at "leaves" for details on "how to" actually start, implement.
• This "mind map" would serve as an overview that should be familiar with people, regardless of CDM. So labels would be products, events, legal docs, at the top level.

[lolabeis]

I agree that there is a need to address, but I would have reservation on trying to achieve that by way of maintaining a separate artefact from the model or its documentation. My main reasons are:

• This would be yet another artefact to keep in sync with, and map to, the model (at present, it already requires a sophisticated regression process for the documentation)
• Developing this would further absolve the model or its documentation from being relatable business-wise, thereby negating the purpose of the CDM to be a "domain" model. It could lead to the model / documentation becoming worse, not better, if it is freed from that constraint.

I think there are different ways to skin that cat, and we should definitely discuss. Some ideas:

• Improving the documentation so that the big, high-level concepts (event, product, trade, party, agreement, etc) are presented first - could usefully recourse to diagrams.
• Improving the navigation in Rosetta to start from those high-level concepts, before jumping straight into parsing model components.
• Building an FAQ section in the doc:
  • How do I build an interest rate swap?
  • How is a clearing event represented?
  • etc

An overarching concept could be to make the doc fully modular, with bite-size pages that answer one question: "How do I / What is...?" (in line with how most software docs work today). This would alleviate the impression that "the doc is large". In turn those bite-size pages could be linked to one or model components and / or test samples, so that you could navigate to and fro.

[llynhiavu]

Thanks Leo. All your points make sense. Your suggested ways to improve/slice the documentation are very good ideas.

I would argue though, why not do all of the above?

• I agree the artifact shouldn't be a replacement to the documentation. I see it more as a way to ease people into CDM through something they can relate to. Talking to firms, people seem to be intimidated and don't know where to start. The artifact could be used in marketing / training presentations as an entry point to documentation.

• The artifact could be developed while continuing to improve the documentation (as a priority) [which I hadn't actually considered before as an option]. The artifact would in fact work better with bite-size topics because we would want to link from taxonomy "leaves" to CDM bit-size documentation.

• If it turns out that maintaining / keeping the artifact in sync with the CDM model is

  • is not cost effective OR
  • has a negative impact (your point # 1) OR
  • that people don't find it useful,
    we could always decide to drop production of it (and return to an improved documentation which would have been developed "in parallel". That improved documentation would have to be a project on its own.

• That artifact would certainly be developed more quickly than any improvements to the structure and depth of the documentation (just because it is simpler, just representing higher level concepts). So it can fill this recognized (knowledge) gap, immediately (well, with minimal time required from everyone. It's a low hanging fruit imho.)

[lolabeis]

In the meantime, I also propose to convert this issue to a discussion. We are always looking to declutter the issue board in the repo and keep it focused.

[llynhiavu]

In the meantime, I also propose to convert this issue to a discussion. We are always looking to declutter the issue board in the repo and keep it focused.

Thanks Leo for converting to a discussion. Makes sense.