2017-08-17 Meeting notes
- Dennis Wisnosky
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.
Review Sept Deliverables - ALL
Discuss an issue Dean is having with
Document the process by which we do CCM round tripping and the creation of new FIBO material via CCM - MB and all
5) For next week.
Proceedings:
20170817 FIBO FPT RDF ToolKit
Tony reports on using Mavin to run the RDF ToolKit from Jenkins.
DW Q: How do we get it? TC: very easy. We would have to modify our build script. So e.g. if we do a master build and it's successful, then we would do another thing. PR: There is a thing called a POM file that is used to build the project and check you have the latest version of things TC Yes and when you produce a JAR file the version information comes in.
DA are we using Maven already for the build stuff we are doing so far? TC: yes when we run this now, the libraries we use are on that, but we don't write back to that. JG: We're using SBT not Maven. DA: getting messages from MU and DN about the ability to run these things on their own environment? Do they need to run the toolkit as well? Currently they download the tools per Omar process and run them, all we need is to tell them to run the latest version. This is what we did so far, but clunky. Now, they need something today not whenever we get around to doing some JavA development.
MB: we need a specific, technical write-up of the above, please do not rely on my notes. TC we still can't do master branch builds due to a problem unresolved with a missing SPT launch Jar. This is the first we hear the name of the thing that is at issue. SPT is the build system. That JAR file seems to disappear for unknown reasons (when?)
JG: https://jenkins.edmcouncil.org/view/rdf-toolkit/job/rdf-toolkit-build-dev/25/console When it disappears, Jenkins can't find it, and not finding it, can't do a build. See URL above, to the Build.
DA summarizes: there is a dependency to another problem before his question can be answered. So we have process issues for the work MU and DN doing.
DA: we need some workaround in place. Not happy with his local one but needs to do something. TC 2 things: 1. look at how to post the scripts to Maven. 2. have a process that just pushes it into a separate job.
JG what needs to be published? DA we used to have 2 chunks of code: One to build Catalog and one to build About Files. Very bespoke code currently used to build those 2 files. For people using tools like Protege they need the about and catalog files when are doing their dev in Protege. Need to be able to create the About files themselves from their own command line. DA has redone these into tiny scripts. The publish process now calls those - so that the desktop folks and the publish folks get the same script. But where does DA tell them to get it? DA currently doesn't do some specific thing that it would help if he did.
DA proposes publish on Maven. JG it is already published on Git. JG can also be published on Jenkins. JG sees this as nothing to do with Toolkit.
DA says it is a functionality that it would make sense for ToolKit to support, though nothing to do with ToolKit today. JG: Ok but what we do in INFRA repo is Q&D hack to get things working, what we do in RDF TOOLKIT Report is what we intend to do to do things the right way. So if we put this in the RDF ToolKit repo this would mix these 2 things as 1.
DA talking to DN who recommended from a user POV we bring those 2 together. Our issue is the right things for maintenance, for short term and for long term. DW will this help DN stay in synch more than he does now? DN probably a different issue.
JG can create a Jenkins job that triggers from any change in the RED ToolKit repo and publishes such things where needed. Then DA and MU, DN etc.,. would go off to that artifact. For instance, currently emails them when there is a new version of a thing they need. Can do that here. JG: even that email can be sent by Jenkins. Long term solution, again. DA expecting this functionality to be written in Java or SCALA into the RDF ToolKit one day.
DA another thing: whether someone like DN can even run these scripts, as they run in Bash. Wells and others like them might need to not have to count on having Bash for such things available. PR: Bash is available on Windows 10. DA uses that. But, had to go to a dev version of Windows. So we can't guarantee that ends users in e.g. Wells have the right versions of Windows, and we should not rely on that. We want them to have one thing they install that gives them what they need to be productive in RDF Toolkit.,
Conclusions? DA summarises: Abandon strawman in DA email. JG proposal is every time I push a thing to FIBO INFRA, it will publish something (needs detail from JG), and DA will then update Omar's instructions for how to install RDF ToolKit. This becomes part of DA documentation for developers on how to work in FIBO.
DA wants to check back with TC and compare with his proposals. TC: fine with that. The things that aren't libraries, it's less clear. So yes.
So DA needs info from JG on how to publish something as a suitable kind of artifact. JG explains this verbally, too fast for MB to write. DA has this in front of him, talks through what do with JG. DA finds this straight forward. Dean to follow up Jacobus' suggestion, i.e.: Make these scripts into a "archived" artifact section of a Jenkins job for a build
ACTION: JG action on OWL landing pages: will work on that this weekend. Put this into the instructions for developers (starting with Omar's instructions for the jar)
NEXT: VOWL as deliverable: See https://jenkins.edmcouncil.org/job/rdf-toolkit-build/ for an example of how this is currently done with the toolkit jar as part of the onto doc thing. VOWL is part of that. JG will generate the onto doc in separate place next to ontologies, glossaries.
403 and 404 errors JG no idea yet, needs further research
Cambridge assignment on JG: Sort of working but not good enough, Still gets ugly URLs. DA this seemed like an impasse in Cambridge. JG: Issue is triggering the job when there is a tag. There are some ugly tags. Tags with an underscore mess things up. So we need a naming convention. We already have OMG tags with underscores, so we needed to rename those (underscore becomes dash). Is the naming convention documented? Where?
MB has renamed the diagrams ending in (AB).
Dig out ISO 20022 naming convention - not done yet. By Monday
"Verify checklist for origin file". See 6/15 meeting notes for meaningful description. MB will confirm after this call whether this is done.
DA actions: Take out FAO Country onto (MB). Done
JL actions e.g. Glossary work. JL not had a chance to look yet. E.g. 1. Put a search in there. Also alternate way of doing glossaries as proposed by JG and DA. Needs to be auto generated 2. Needs synonym. JL: 2 is a config matter. Anyone can do this. It is a project option. DA this also relates to how this is generated. For Jun 30 DA had to go through a series of menus and save it somewhere. Needs to be done with headless thing. JL the 1st thing is project setting. 2nd thing is something to do with GitHub. 3rd thing needs the headless thing set up.
For #1 there is a project option called Natural Language Glossary Annotation Property List. You point this at the SPs you would like to have come out for every entry. In this case, both versions of synonym (to get around the odd config whereby 2 versions of annotations are referred to).
DW: Who, what and when. MB will do Thing 1. Thing 2 (Git)? Thing 3: Headless one. The way forward is that someone has to have access to a server where the headless thing will run, need to install MD and CCM on that server. JL never done this before. Unix or Windows? This will be the server Jenkins runs on, or one it can reach. DA and JG can configure this, maybe a separate VM on Amazon. Any difference from CCM PoV if Win or Unix? JL Unix easier to redirect display etc. so probably preferable but can be either. After someone has installed the CCM stuff per the written-up config in MB memo from 2 weeks ago, then we need someone with Java or scripting to type in a script to do the things that need doing.
What kind of API? JL there is a CL that will invoke the creation of a report, and this is well documented in MD docs. JG if EDM Council publishing stuff on spec then the vendor should do some work on this. i.e. Jim. JG could do this but does not have budget for it. In general when standing up products the vendor should be the one to do that config work. Can someone else in NoMagic do this? JL would struggle to convince NoMagic to invest in this since generally done by customer and documented already be MD. Can provide support if the customer gets stuck. Already giving away free licenses and free support. JG: Would get publicity onspec.edmcouncil.org Once NoMagic gets to see any return from that - needs help convincing the Texas office. DW can help with the convincing.
CC: it is not that much work to make one of these scripts. DA could do it if he had a CL terminal to one of our servers, and can work with CC who would do it easily and educate DA in the process. Using a thing called XTerm. CC and DA will do this together.
Change of About to All files. DA one issue with that was a question we need to answer here. In the Domains, we still call these files About. DA only generating ones at the top level. Question is whether to do the same at Domain level. Also possibly different about with different statuses. The answer is in the script that was factored out, instead of creating AboutDev and AboutProd, would do as All. DA and MB to work together on this, along with the next agenda item:
Agenda item: CCM management process. MB proposes we document what we do around CCM and then work with DA to tease out the things DA does and the things MB does. URIs for example. These should be taken from GitHub. Not spec which is effectively the compiled version. MB should take these from the source. This has been because the catalog has not been in the source. This is the same as the issue facing MU and DN as documented at the top of this meeting.
Next: list of things to do for next week (slide 1 of a deck)
W3C Time not done. UN-FAO done.
Refactoring according to EK memo. MB has done the CCM part of this work. Need to coordinate with DA and EK. MB to document what was changed in CCM so they can coordinate. There are parts of the Refactoring to be completed in RDF. MB may or may not have done the corresponding stuff in CCM. MB needs either a shorter version of the Elisa document or one where the bits that have been done crossed out. DA has a document reflecting this.
SKOS Traditional SKOS versus the FIBO-specific flavor, per MB earlier comments. DA opinion: the way we are using SKOS in our current generation is similar to what other users do. We are extending SKOS to do this. So this is a common practice. We should not apologize for it. Agrovoc and UCAP do this. It is not core but a common extension. So we should describe how we have extended SKOS.
MB should we do a separate one in which properties are concepts? DA happy to do that, it is easy to do and would support more people.
ACTION: MB will specify what this other flavor would be. And what is the audience for this? Current work is based on Kevin Tyson requirements and earlier script. Also bounce this off Kevin Tyson
Decisions:
Action items
- Mike Bennett
will specify what this other flavor of SKOS would be. And what is the audience for this? Current work is based on Kevin Tyson requirements and earlier script. Also bounce this off Kevin Tyson