/
2017-05-04 Meeting notes

2017-05-04 Meeting notes

Owned by Dennis Wisnosky
Last updated: May 17, 2017

Date

Attendees



Agenda


1) Where we are on our road map. 

2) Open Action Items

3) JIRA Issues Review - https://jira.edmcouncil.org/projects/RDFKIT/issues

4) Todays content discussion.

Spec status - DW and JG and DA

spec contents CC idea

Each of the product views I am talking about would be generated from their source material for each release. The design I am suggesting is a way to organize those product views topically and across views for each topic. So, you could be looking at a glossary entry for something, click on OWL and see OWL or click of UML and see UML. You could also “drill down” from a top level topic to more detail – or get the files.


Progress on DN and JG maturity level discussion


Closer to HTML approach decision (CCM, GitHub Markup, other, all)


The generated catalog that all need to continue working


5) For next week.

Proceedings:

20170504 FIBO FPT RDF ToolKit


Roadmap Review: We made our April deadline at EDW.  Status of all the other things.


Artifacts Ontology:  A big chunk is done; some delayed.   EAL: In a good place, discussed architecture with Dean yesterday, that had been holding him up. Has a slide to share.  Also still issue of back and forth between domain, subdomain, jurisdiction plugin and module. Is unblocked form the architecture perspective (see slide in a bit). On Domain, Sub-domain + Jurisdictional sub-domain versus Module, we have 2 ways forward.  1 Domain and Sub-domain terminology - this is already in the ontology. 2. If we bring in the term Module again, suggest we use not instead of sub domain but as an addition to, reflecting the perspective of the technology as distinct from the perspective of the business domain.


Other matters:  OMG Specification metadata - if not already included in every ontology; has already imported into one of the RDF ToolKit ontologies, to identify metadata about these ontologies.  EAL has not identified a use case for the metadata ontologies.  Also, whether to put something in an OWL file or in SPARQL queries: for example the queries that will show dependencies in a graphical format.   Separately we have another kind of query, which is the kind that Dean does.


DA 3 ways we might do that: 1 the actual dependencies (this ontology refers to something in that ontology).  2 The declared dependencies (OWL imports) 3 Transitive closure of either o those, where we leave out redundant ones e.g. A dep on B dep on C, then A dep on C is redundant; question is whether to include or exclude those.  


Separate, 3rd architectural point from yesterday's DA:EAL conversation remains outstanding. Whatever this is, depends on some script that Dean is working on. Does not see this as being on the CP.  Viewing Elie's slide - JG created the 3 files on the left. EAL has made changes to the ontology and added scripts in a folder for scripts. DA and EAL have discussed how we can modify and update these scripts.  The scripts inject content into one of these files, and other content can be added manually. Then after discussion with DA and JG, have decided to remove some things.  Also now importing SM ontology after conversation with PR and EK.   So all these files need to import it.  JG the import between artifact-ontology to instances is going the wrong way. An instances file must import the ontologies it has instances of. Alternatively, do it a more general way, as per edits carried out on screen now. Split up the file with domains and the file with modules.  DA these were once generated at the same time. Might not break that into 2 pieces.  We need to have that conversation again now.  See Domain / Sub-Domain / Jurisdictional Plugin lists in Elie screen.  EAL ran a script at the Domain level.  


Where are the Domains and Modules TTL files stored? DA does not know. JG these should be in the FIBO Repository.  DA - we decided some of the instance data, esp. the dispositions of the ontologies, should be in the ontologies themselves. This was the outcome of a conversation yesterday.  JG the instance data should be in the FIBO otology itself. DA if we need to import one of the RDF ToolKit ontologies into the FIBO stuff, then someone doing it off line would need the RDF Toolkit ontology however if we make that a FYN thing then it should work (JG agrees).


Back to Roadmap... DW we still do not have enough user stories, but we have an uber user story based on what we will c today. Task about Migrate to SCALA etc.   JG this is a long term thing. We have quick and dirty scripts in the INFRA, not RDF Toolkit repository Whatever you see in http://specedmcouncil.org is based on that script, which is a hack for now.  The real Publisher process - we bought some time with the hack so all the blue tasks can move up.  We re working 2 tracks in parallel:  1. The script in the INFRA repository doing what's on screen here.  2. The RDF ToolKit track building a real product to do these same things in a more advanced way.  DA comments on the Product ontology applies to these things as well. Can turn this into something more productized.  JG this is a product all large corps would want to use for publishing their own ontologies. Also NGOs, Consortia, people like the EDM Council, to organize their metadata on an industrial level. See also agriculture NGO space.


DW to MA: Is there an event we can use as a deadline this summer, that we can shoot for our next major release?  MA no.  The SmartData conference was February this time.  MA we can target the fall round of EDM Council updates for this.  


ACTION:  JG to update the Roadmap with these dates once DW gives him the dates.


Back to Elie presentation, so we can answer the rest of his questions.  EAL: "Product Otology" was mentioned but looking at the work that JG and DA did, there are already hooks that can be used for this, Are we saying we need another ontology?  DA, No, was using the term product Ontology as a short hand, We may decide to design such a thing but at present it is part of the Artifact ontology.  JG the instances of these should stored in the RDF Toolkit thing.  JG 2 files needed here belong in the FIBO Repository not the ToolKit Ontology.  MB which 2?  EAL where.   DA - put these in rtc. But some people don't synch with etc. because of its size given the UML model binaries in there.  DA who needs to see this? It is not part of the publication but it is part of the publication process. so the people tho consume what we publish don't need it.   So then etc. is fine, and seems like the right place Only needed by those maintaining it.  JG not completely true. Say you define a product tag, the ontology product, that has a URL. Could use the same URL we have. Can use the existing URL that is the instance URL for the product, But if you refer to that in the normal OWL files with the objects we define in the RDF ToolKit then shouldn't we publish those.  DA not, the things I expect in the FIBO ontology files consisting of a vocabulary - currently of 3 words (Pink, DirtyPink and Extensions). Don’t need to refer to the product itself. Only instructions for how to build the product.  DA: The outcome is published but the recipe is not. JG you can have product descriptions, status, maturity level. So this is an intersection set of information, from which we generate a whole HTLM website. DA so then the Publish process should have something in it that picks and chooses from that and reports on that - but does not need to publish it. What about LCC and other things?  These are separate "Product Families". 


What do we need so Elie can proceed?  EAL: Ran a script "here" today. Auto populate the instances. Now, the current stats is the level of a Domain, and the next level is all Sub-Domains including subdomains of those.  All the blue folders in Sub-Domain are Domains and some have a relation identifying them with a domain.   Then the discussion of Domains and Modules.  EAL recommends: Keep Domain and Sub-domain but some of these folders need to be called Modules from an architecture perspective. Would have to do that manually.  


DA: Look at SEC where there are things inside of SEC that we think of in business terms as Domains, whereas e.g. Legal Entities have a different relations within BE.  MB domains is the business breakdown of the world, and modules are how the FIBO stuff is carved up. Sometimes the modules reflect business domains and sometimes they do not.  MB in order to have this conversation we need these 2 different meanings.  MB we can just annotate any given Module as being or not being representative of a Business Domain.   MB we should not try to reflect the domain structure in the module structure - we can improve on that relation but they are always distinct matters. In particular the modular structure does not and probably cannot reflect the type hierarchy.  JG how we represent this to the world should not need to reflect how we have chosen to modularize the actual ontology. MB we should not make the Modular structure visible to the business audience, but it does make sense to the implementer audience.


MB and MA can identify the Domain structure.  See MA spreadsheet describing the Modules.  Here the "Module" corresponds to Domain and sub-Domain.  On review of these on MA screen, the Module level here is more or less in line with business sub-domain for the most part.  These make useful subject areas.  PR the subject areas make a good complementary view to the type hierarchy.   EAL do the Module entries correspond to OWL RDF files? No, except About files.  EAL:MB - Exchange Traded Derivatives. Doesn't have Exchange Traded Derivatives.  EAL seems to be looking at Pink for DER only. The DER were incorrectly characterized as Ext in Dean's original metadata - see later version of the table on the FND Wiki for correct dispensation.  


ACTION:  Elie top update the Artifact onto and resubmitß


Next: status of the spec / instructions for users to download.   DA 2 major efforts:  1. Want to get Publication in a state where it can be loaded in the major tools, both online as FYN, and offline via a Zip file. Need instructions for each. 4 tools, 2 modes. Tools are Protege, TopBraid and 2 others.   Has run into issues with TopBraid, Needed for Ralph for CFTC demo.  DA:JG - want to put changes into the Publish script, without creating surprises. Will do as pull reqs into the dev branch of FIBO-INFRA. Want JG to approve and pull these.  JG to watch for these.  On track for this week?  DA yes. Has hit most of it last night.  Believe it will now load into TBC without modifications.  Protege already done.  Working on CCM, may need Jim's help.  Will need Elisa's help for VOM.   


Next: Sec content - uber use case of how people get what they want, See Cory slides.  New version of this today. This comes out of discussions with MA on how the UML and the glossary should look from a business focused pov.  Slides look at how all this might fit together. Want to be able to start with a business topical view and drill into more detail.  Hence top level domains. Then how to connect the Products (Glossary, Vocabulary, OWL and UML etc.). From wherever you navigate to you should be able to switch your view. So click across from SKOS to OWL and so on.  


Topic v Domain? Topic is anything we have one of these pages on.  So Topic could be anything from Domain down to Property or Class.  At the top level, the Topics are the Domains.  Can look at it topically or by Module.  JG keep it as consistent as possible don't introduce new terms like topics, or if we do they should be modeled in the Artifact ontology. This is because everything we see on this screen should be generatable from the computer progr.  MA: Amen.


CC: Since we have different technology that generate different parts, we need a header that will flip between them, whether from a business focused view or a modular (structural) view.  Click on OWL - what does this look like? Can look like Protege if that's somehow feasible. Open to discussion what the OWL purists want to see.  For the header to do that, have a java script function that based on the URL and a (consistent) pattern we figure out how to switch between the appropriate web pages on a given topic.


MA that is exactly what I wanted.  CC question is how we link those pieces from an implementation POV.  Each view on each topic will have its own URL, in a common pattern with a common HTML header that has a function that can use the URL to navigate to the appropriate web page.  JG at this stage, need to talk about the What, not the How. Define the functionality you want as a business user and isolate into user stories.  What we see on one slide here is about 20 user stories. Where and how they are shown can change so we should not define that here. E.g. I want to see a topic hierarchy; I want to see the definition, the explanatory note and so on.  MA we need to start with something.  See written slide at the top of the deck, for these.  The visual is a straw man or discussion. So we can discuss the look and feel as well as the business requirements.  This is all in the wiki.  MA I need you to give us guidance on what is allowed to be shown, how much of Master we will put up there, how we will generate HTML, how we will link to diagrams, how login is managed and so on.


DN has concerns on the maturity level - see agenda item.


Cataloguing - will also involve levels of security permissions. Yet to do.


MA: We will use the website as the portal. Work with spec as the initial thing since the new EDMC website is not ready.   Would then move spec to http://edmcouncil.org when that is ready.


DW we need a design with no dead ends.


MA: we had meeting on risk ontology this week. What we learned: 37 showed from 18 banks. All in the middle of lineage and glossary work for BCBS239 and FRB.  They don't understand FIBO but are interested and need access.  They are struggling with the RDA problem and are hearing us but we need to make it available.

Decisions:

Action items