2017-04-27 Meeting notes

Date

27 Apr 2017

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.

1) . At the last FPT, we discussed FIBO product names. Attached is a table prepared by MA, and to which I concur. This will be the product choices that we show on spec. Dean and Jacobus are working on Vocabulary/SKOs now. Please look at this and we will discuss.

2) . FIBO OWL names. We had Master and Release. At the ATL meeting, it was suggested that Master should be Beta. Jacobus believes that we should have Prod for product - the Pink FIBO, and Dev for Development - the pink FIBO and all of the other ontologies. His argument is that prod and dev are commonly used terms in the industry that explain just what we have. Let's consider.

3) . Lots of chatter this week about problems caused by not keeping RDF ToolKit in sync. FORCING that everyone is using the same version. We must finally figure this out and do it. Create a system that allows the RDF Toolkit to download updated versions of itself. It should be possible to do that, but we haven’t yet identified a specific library/etc. that would allow us to do it. Tony Coates

4) . MA is working with Paragon in creating the spec splash page. We must be prepared to use it.

5) . Pick off the next publishing target.

5) For next week.

Proceedings:

0320170427 FIBO FPT RDF ToolKit

Different Product names e.g. Beta and Release versus Product and Development. DW and MA happy to go with Product and development. All agree. Prod is often an abbreviation for Production as well as Product? What do we mean by each? Master = Everything. Release = Pink. This is Production. Then everything in the FIBO-V Full is Development. That has within it DirtyPink and Extension. These discussion about the details within those, are separate from the above conversation. JG has proposals for some of the words for those pieces within those. Also file extensions within GitHub so we don't change the names of things when they cross the line from Development into Published.

MA action to come up with definitive names for the Products - see table from MA. There has been discussion on Vocabulary v Glossary. DW says we had that right. Vocabulary is as per SKOS and so on, with taxonomy and relations. A Glossary typically has words and definitions. On the products list, "Diagrams" seems misleading. Do we mean the full model repository or do we mean diagrams generated from this? Or, is Diagrams what was meant by the CCM model? It seems that this line entry here really does mean the CCM Model. DW has inserted wording against this to make clear that what MA means by Diagrams is the UML-based CCM model. MA is about to release a statement describing all of this.

Since last week DA and JG have completed and released a Glossary item under http://spec.edmcouncil.org Is it only the vocabulary that we are going to do an Excel version of? Weren’t we going to do that from CCM as well? We certainly can generate this from CCM with some dev effort from the report generator. Omar and David have been able to pull the FIBO material into Protege itself via the above. There was some issue with looping around Financial Dates. There was an issue with Protege 5.2 and Windows 10 (Bobbin). Omar was on Win 7.

Next item: RDF ToolKit in synch. Versioning issues with RDF ToolKit? TC not sure what was happening, should not have happened if they use the latest version. TC has sent out a link with the latest version. No-one has reproduced the stated problem with the latest version. Issue now is how to deal with people having the most up to date version. Possibly via the use of some installer kit that would let people always download the latest version. TC has not found any free tools that do this, commercial ones start at $1K. Could conceivably write one. How does NoMagic deal with that? Are there good, free library that implement a Java app that updates itself based on looking for the latest JAR files. JL: we don't do agile releases we do formal releases, so that doesn't address this question. BT we have a compatibility matrix. BT there are issues with people using non up to date versions. DW: If we bought something, what would be the best thing and what cost? TC found a couple of things, around USD 1000 since there are not a lot of these. TC to send some pointers, then DW can follow up with MA. Ideally something we can already figure out how to use. Cory: Doesn't Jenkins and that take care of updates? TC looking for one that specifically handles updates, as distinct from just building an installer. That is auto update. Will be on the agenda against next time.

Next policy target: Elisa on her review: The master Catalog file - we might have one of those, but we also need a catalog file in each module / folder etc. and we do not have. CC confirms this is a problem when loading things. Elie is doing the Artifact ontology. What is missing there? OK: the About file being loaded is a problem. Then separate About files there was an issue with. It would try to find some of the subsequent About files, e.g. the About FIBO Family References that was not picking up like W3C Time, OMG Metadata. It is possible this applies to both of the styles of About file, as these are entirely different. About (1) - really an All file. About (2) is version specific. One or other or both of these may have stuff specific to the OMG submission. PR it should be possible to adapt one of those About files to be the same for OMG and EDM Council even if this means subtle changes to the ones submit to the OMG. All (About (1)) is not working right now (Cory). All and Catalog are both needed. Can we auto generate the new catalog files that Elisa mentions? Can this be added to the Build? TC yes. it can be done - at the moment things only look in the folder you are in. Need the catalog to explore up and down. In CCM, you can use one catalog at the top but it seems that Protege needs a catalog for every folder. Usually, a catalog runs from the folder you are sitting it in. so you might still need one in each folder even if they are the same. Need to generate paths to other directories. If someone is using a local copy you don't want to end up with some from the web and some from a local directory. Catalog is generally all relative paths, relative to the folder where the catalog is situated. If you pull down off the Edmcouncil site it doesn't include the catalog but Protege produces one in a temp location somewhere. RC - we were experimenting with CCM and catalogs some time back. TC different tools apply different semantics to catalog files. TBC doesn't have it at all, it uses the notion of an Eclipse project.

DW: Who best of us can address the Catalog issue? That is to document the problem (Cory, Omar, Randy?). Randy an re-create what we did before both for Protege and CCM. Establish how many perturbations there are to the issue. Does not have TopBraid so that's a separate use case. RC documentation would cover how many kinds of catalog file would be necessary. For tools that use catalog. Would work with Cory. CC: Elisa described the issue fine. MB the question was can it and how can it. DA already has automation to do this, but this needs to be built into the process. JG catalog generating in the publish FIBO job in Jenkins - yes we can do that, but we would have to do that for every Zip file that we generate if we generate multi types of Zip files so each zip file would have its own catalog. For instance for a Zip file that only contains Release ontologies, you would have a smaller catalog file for different packaging methods.43to have this at every directory level, so that the end user can open stuff in each folder. This can be added to the Build suite. JG will implement this. How does this differ from what Dean has? RC: What Dean has is a script that will generate a catalog file for whatever configuration of the ontology you want to package. JG will ask DA for this. Had assumed this would be part of the script for the ToolKit . TC was working on the thing that checks each time if there is an updated version of the ToolKit. Similarly, for the catalog, every time something changes the catalogs need to be regenerated, so this is similar. TC but the process is different - one looks at files and asks, “have they changed?; the other is where you are running a bit of software and wanting to know if the library of code it uses has changed and update if so. So TC on that, and JG working with what DA has to add that to the Build.

MB can we use the change to the catalog file part of the builder, to automatically update the Build software? What about when scripts (not JAR files) are updated? What about maintaining scripts in people's own forks? We used to have it that these are always up to date. JG would like to propose a fundamental change that cuts across this question. Use of a Fork has the disadvantage that Jenkins jobs on the FIBO main repository can't run on the forks. Now there is a new thing for security that might make it easier to do another thing, as a result of which JG recommends that FCT otologists like MB use a new branch in the main FIBO Repository rather than in their own Fork. Would delete that branch after a merged pull request. This would make the above question moot. But MB pints out, if we did not do that, the above question would not be moot and would need to be addressed.

Next item: The HTML. OK: If we have something that is viewable and searchable, whatever it is would be nice to have. This is also DN stance. JG did not like this idea. JG built a thing he showed us some years ago. DN thing used OWL. Doc plug in for Protege, JG looked at the source code and it uses a special component based on the OWL API. You would have to build a Java thing around it. Could include this in the RDF ToolKit but that is not a good short term solution, since you would need to load the whole ontology using the OWL API. CC would hope to be able to use the generation out of CCM so it has the documentation and diagrams. This requires a little work on the CCM model to provide a director of the ontologies that brings them all together. Then that it would generate would be quite usable. JG but we have to be able to do this from the CL in a batch job so Jenkins can run it. The generated HTML files output needs to be able to be mapped to the right URLs so when people go to the given URL on spec, via Master/latest and module, ontology and class, should resolve to the right web page. JL: what do you want to resolve, how, etc. and also whether we are talking about publishing out of the Collaborator or out of the Reporting engine. Can create a special URL structure for the CCM output. If you want FYN URLs so e.g. open an ontology in Protege, take the URL and go there via a browser and see the material about that including diagrams, different versions, all the information about that, a lot of which is FIBO specific.

MB isn’t' this the same as content negotiation? Yes. This is where you click on the URI in Protege and see the RDF, and click on the same URI in a browser and see useful information. JL you can do this, but need to know what it is that you want to see. The content negotiation - could be any set of URLs but presumably simpler if there is a one-fragment difference e.g. /diagrams versus /ontology. If there is a CCM page on some URL that documents that ontology, then we can annotate that class with that URL as an annotation in RDF that would be ready in Protege. CC we have HTML documentation that is pretty usable and we can progress on content negotiation going forward. Sounds reasonable. First step: knowing what we want to happen on the web site when the user clicks on what. Then Jim and co would be able to design what happens in CCM for that to happen.

DW: Who would design that? MA made a start. Suppose we had a page for every ontology, what is the URI for that web page, is it the IRI for the ontology? JG that is difficult to do with any product, would involve creating seeAlso links. If you had another tool that generates similar URLs that are not the same as the ontology IRI, then put those as – seeAlso links in the ontology itself. Need not be seeAlso it can be a more specific annotation.

ACTION: CC can work with JL and MB on website design that extracts CCM content. MB would liaise with MA about what sort of thing we want to see. This is reasonably close. CCM already produces web pages for the ontologies. We have diagrams in those. Need review of what is present. Then the issue with the URLs can be looked at separately.

Can CCM be running in a server or run static outputs? At present, we have Collaborator which is a static web service. CCM also has the means to generate static HTML with graphics etc. The headless thing can come later, after we have figured this out as a static thing. Need someone not familiar with the UML. That can be Mike Atkin. Also if or when we already have URLs for these things we can store these in the ontology either as seeAlso or our own invented annotation for those. Then we can generate those in the ontologies. The Collaborator is behind its own login. This need not be the case: 1. No Magic have made it login by request of the EDM Council. 2. The URL structure can be more static if the EDM Council runs this on their own servers. At present No Magic are running this for the Council as a courtesy. JG we also need to be able to have these found by Google. Also the single-sign-on issue remains.

Decisions:

Action items

Cory Casanave Mike Bennett Jim Logan (Unlicensed) CC can work with JL and MB on website design that extracts CCM content. MB would liaise with MA about what sort of thing we want to see. This is reasonably close. CCM already produces web pages for the ontologies. We have diagrams in those. Need review of what is present. Then the issue with the URLs can be looked at separately.
jacobus.geluk@gmail.com [X] Dean Allemang Develop and code the catalog plan. Much is in the notes on proceedings on this.
Anthony Coates bring back research on what FIBO can use to make sure that users have the latest serializer