Date

23 Feb 2017

Attendees

Agenda

1) Open Action Items

2) Where we are on our road map.

Artifact ontology

Serializer

FIBO-Master schedule

3) JIRA Issues Review

4) For next week.

Proceedings:

20170223 FIBO FPT

Serializer and Build - version control and push of latest to users. At present we don't have a way to ensure everyone is on the same version. Omar had a suggestion for this: Look at having what we put into GitHub has a label, and parse that when something is checked in. The idea is that somewhere in GitHub is the current version number, and have the code check its own internal version against that. Then there are options for what to do, if they differ e.g. let the user know vs auto upgrade. At this stage we look to having the message to the user, since auto-upgrade would be more complex. But where and how does the notice to the user get out?

OK: Should be a simple way of doing that, since we control it via a Jenkins job. Is there a JIRA ticket for this? No. Create one.

ACTION: Omar create a JIRA ticket for the creating a message to the user that something in FIBO has changed via version control.

Open action items – none, except the Roadmap action item: strawman version of the artifact ontology for DA to review. JG to do.

Not had time yet. JG to work with TC F2F to work this out, tomorrow or next week. This is a blocker for several other actions. JG: will make a start this week.

FIBO-Master DA: there are a few layers of things to do. DA: State of FIBO Master as delivered was good as a starting point for loading and dealing with issues. There are a few references to things that were not defined. There are bits of FIBO Red which we already decided would not go into FIBO Pink. DA will start expurgating those. DA will go through with Elisa and make a list of things that will stay and things that will go. DA will provide a version that passes his minimal hygiene tests by end of next week. This will then be a strawman version of everything we intend to publish. Will be Master that incudes Pink as a sub-set, and a FIBO-V that generates from these. Not sure about http://schema.org Will then have a version for all our products. DA will have a pipeline by earliest tomorrow week. See new notes on the slide with the barrels.

DER is much broader in scoop than the IR Swaps PoC. This will become clearer as we start to see the overall content. DA: There are 3 statuses of things in Master: 1. Thins checked in to Pink. 2. Files in domains that have never had a content team (the only version is former Red material in Dirty Pink) 3. Things in between: i.e. modules and ontologies living in places where FCT has done work, but some of these files are needed to understand definitions in Dirty Pink. DA has talked those through with Elisa.

Hosting: Nothing new. Do we need something written about this? Yes, we need the record for things people know. JG needs to write down how we do the hosting of http://spec.edmcouncil.org Similar to the SSL issue - JG would have been a single point of failure on resolving that issue. So we need those things written down. Comodo is the provider. Emails from them went to other people listed as owners (Mike A and Carole?). JG any technical person would have been able to do this. They would have needed the password. DA and DW and eCore also have the keys now. We did not need the Comodo password. DW is a different type of user. JG is the technical contact, but DW and MA also on their list.so Comodo support needs another tech contact.

Migrate to Serializer: Blocked by the artifact ontology? No. This action does not have priority since the Sesame Serializer works fine.TC gave up on this last week after our discussion. Assume we continue to use a serializer based on sesame but build the rest of the toolkit with the OWL API; Page needs updating to say this. Hosting - we already agreed to host everything on Amazon. This is still the plan but is still needs writing down! Migrating to Scala and OWL API is parked.

CL Interface: This is a parallel effort. JG work in progress. When finished we can combine the Serializer CL I/F with a new CL I/F so these are combined in a simple command. JG will document this. This is a hierarchical CL. You type the first word, and then there are the options 'serialize' or 'build'. The build can invoke various build types. Can also have an 'all' option that invokes them all.

ACTION: JG to document how the CL will work, i.e. what the Jenkins job will have to do.

Can someone help JG with this? OK will have to know the CL structure in order integrate this stuff for his tasks. So he can help test this. These things need to be run from the Jenkins stuff that Omar is doing. OK is happy to help. JG will first document what that Jenkins job has to do. The Jenkins job is triggered by any change in the FIBO Repository. This will then start the builders (all of them i.e. 'RDF ToolKit build all, 'Then the ontology itself as loaded into the FIBO Repository as a file, in your Branch. Not the same for all branches. Given a number of builders, the RDF ToolKit calls those builders. so these are to be packaged together or we can call them from somewhere else, in which case we need to define and document where the build things are stored in the structure, so these can be called. We need to store things in a structure as close as possible to the URL structures we discussed for the products. Then in the Jenkins job description you add a post-build site where you take all the fields in the stored directories and store them in the Amazon place. Then the http://spec.edmcouncil.org web server which lives in the same place as the Jenkins jobs, will then redirect to the XYZ server. All of this needs to be documented.

ACTION: OK will do a mockup build to generate files and have something working.

DW: A related thing: DW is the bottleneck for GitHub. Gets requests. Some are from EDM Council members. That is potentially thousands of individual GitHub users. Also half the requests are from people who are not EDM Council members, including academics, small business ventures and so on. When we do http://spec.edmcouncil.org we should change the way we use GitHub and let people who are EDMC members automatically get what they want without DW being in the loop. For those who are not EDM Council members, since these are a marketing choice, we should redirect them to somewhere where they can access the stuff for 30 days and then be chased off if they don't join the Council. This relates to authentication and so on, for http://edmcouncil.org So the web thing we generate should generate some login and security buttons and pages. We can use an authentication service. So people can register themselves as a user. This relates to the earlier conversion about a single authentication server. This requires GitHub Enterprise. In DW scenario GitHub would be restricted only to the inner circle. At present he lets everyone in who asks with the presumption that if they don't join the Council they will be knocked out.

JG only people who contribute to the ontology will need GitHub access. Most of the people asking for GitHub now only want the OWL, so once we have http://spec.edmcouncil.org then we should see a significant drop off in the people wanting GitHub access.

Separate question: should we restrict http://spec.edmcouncil.org and use authentication? DW the policy is that people who are not members of the EDM Council should have access to http://spec.edmcouncil.org JG: it would be better for people to be able to access it. DW if people are interested they can see stuff but if they don't contribute, then we will remove them. MB is this policy for GitHub or for http://spec.edmcouncil.org? DW this is a slightly different policy. For spec. etc. - if their entry path goes to the EDM Council user website then they get access. The policy for http://spec.edmcouncil.org: anyone can see it but only for a limited time. If they do not either join the Council or contribute then their access is removed. MB the issue with that is if people are using FIBO URIs and their access is revoked then it will appear as if "FIBO" is not working. JG if we make FIBO content universally accessible then we can also reference it on social networks, and we can also track any reference to FIBO by people on social networking. For instance you want to talk about "what is Legal Entity" - a person can google it and find the FIBO definitions. DW let's build in to the UI whatever we can do immediately. This will change over time. JG decisions need to be made here e.g. do we want people to be able to google a term and land on the FIBO page. DW yes, and if they want access to it and are one of the employees of a member firm then they can go there. JG if it is behind a firewall, then it can't be on Google and people can't put a reference to it on their own pages. So adding authentication to http://spec.edmcouncil.org would be a mistake. What was previous decision? This was that we can protect certain branches. JG: Should be open for most of the content else no-one can find it. DW We want to build in a way that it is open for at least some of the content e.g. FIBO Release material that has been vetted. So the question is, do we want people to rummage around the stuff that hasn't been completed? JG yes so that you have a community of people talking about this in many ways. Can integrate with social networks. Can add a Linked button. The issue is that as soon as we create publishable artifacts, we don't know what our policy is for access to those. Right now we have no access - but that 'is resolved as soon as we have http://spec.edmcouncil.org so whatever we do now is not relevant to that conversation. JG: if someone wants to provide formal feedback on something then we can require them to log in or set up and account?

What is the first step? THe current Roadmap leads to all this. Needs more documentation. Will result in one large website with all the information you can think of being on http://spec.edmcouncil.org so this becomes the standard way of thinking about how our data works in the financial industry.

Next steps? Parallel working on the Jenkins material and the CL interface and builder(s). OK is the bottleneck on the Jenkins integrated thing. Expect to get something up on http://spec.edmcouncil.org maybe on a /test URL. Can simply dump the current GitHub content there as a first core deliverable and then expand upon that.

Do we need another URL called /Test? Yes. JG will add that. Needs to configure the Ngenix server to accommodate that. THen it can be pushed on S3.

ACTION: JG to add a URL called /Test and configure the Ngenix server.

This will not be right "right" URL since it's test but it will work. OK agrees. OK can do the necessary, given we now have the access. This is an existing action on Omar, he now has the information he needs. It's part of he main publishing work, we just decided where the initial test material should go. /fibotest is a better URI to use. Use that. Test with all the current branches. With the current directory structure below that.

Final item: MA ask "When can we demonstrate FIBO Master?" Need to determine what that demo will be. Likely to use Portege, other tools for better viz, and CCM.

Agenda for next Tuesday (4 days from FIBO Master being exposed). What will our demo be? MB needs to redo the business facing diagrams. Part of the demo will be a fresh output of this material to Collaborator, so MA can show people how comments and feedback works. RC: For tools, he has been ingesting XBRL into CCM to use FIBO. Used a tool from Luxon called XML to CSV Conversion Tool 1.6 (open source, free). Worked great. Was able to convert XBRL into CCM with this. If it works on XBRL it should probably work on any XML given that XBRL has arcane usage of XML. Used the Surety Work in Process XBRL taxonomy. Luxon xml to csv .http://codeplex.com

Decisions:

Action items

Omar Khan (Unlicensed) create a JIRA ticket for the creating a message to the user that something in FIBO has changed via version control.
jacobus.geluk@gmail.com [X] document how the CL will work, i.e. what the Jenkins job will have to do.
Omar Khan (Unlicensed) do a mockup build to generate files and have something working.
jacobus.geluk@gmail.com [X] add a URL called /Test and configure the Ngenix server.
Randy Coleman (Unlicensed) demonstrate Luzon
@