Date

25 May 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.

Gather information about visitors to spec who want to use FIBO

How to do this:

System of Record: The system of record for FIBO is the Web Ontology Language (OWL) – a W3C standard. The FIBO OWL can be expressed as UML diagrams (based on the Semantic Modeling for Information Federation (SMIF) standard from OMG). FIBO can also be expressed as a vocabulary of terms in SKOS and as a glossary of terms in HTML. A portion of FIBO is in RDF for web-applications (via Schema.org). The OWL files (and all other expressions) are posted at https://spec.edmcouncil.org/fibo. You do not need to be an EDMC member or have a password to access any FIBO content.

MUCH EXPLANATION - then

FIBO Contact: all questions about FIBO should be directed to Dennis Wisnosky

P.S. Please give us feedback. We want to know what you are doing (and what you seek to do) with FIBO. We want your rants, raves and suggestions. Access to https://spec.edmcouncil.org/fibo does not require registration and we want to keep you and your teams informed on developments. Please send the names and contact details of all the people you want us to add to the FIBO mailing list to Dennis.

FIBO ontology

2. Process for our FCT's to officially work FIBO DA, JG, TC

5) For next week.

Proceedings:

FIBO FPT RDF ToolKit

CCM - everyone is having difficulties opening the CCM project in read-write mode. We are on MD 1. and CCM SP. Randy is on MD . and CCM SP. There was no SP9. Correction JL says there was an SP9 and people should have been on it. So there was a Big Bankg upgrade that did not happen.

MB: I am on MD SP1 on both installations

When someone goes to spec.edmcouncil.org we want it to be the case that someone fills out a form giving us information about them, not requiring a password but giving us visibility of who they are. This is the new requirement. The form is an honor system ,since a person can just go past it if they wanted.

We are running nGenix. What is the easiest way to do this? Where would the data be kept? JG: At present most contents is generated straight from the directory by nGenix itself so there is no HTML in the directory structure. We would need to be generating HTML to support the new requirement. As soon as we are doing HTML then we can add the link to the required feature. JG: Using a cookie can be the approach. If someone does not have the cookie they get redirected to the page with the form. Once they have filed in the form then they have a cookie that goes to their browser.

TC if you have a cookie in the browser, that won't help you if accessing the OWL via other tools e.g. MagicDraw. DA given that you can always bypass the form, it would be possible to access the material directly once you know the URI of the things you are after. DA: How does MagicDraw go to the spec material?

If you get the full URL for the first All or About file, and if you load that which has all the imports in it, then all those imports load FYN just like Protege.

JG you can make a rule in the nGenix config, that if you do not have a specific RFD MIME type but have the standard HTML MIME type, AND you do not have the cookie in the browser, then it sends you to the form. So the absence of the cookie sends you to the form.

Are Protege and CCM forwarding the cookies? No they don't have to because they send the other MIME type the RDF MIME type, and so this is not looked for or expected.

ACTION: if someone gives Jacobus the text for that form he can set this up. The text is in the Agenda for this meeting (DA email) for the form they fill out we need:

What questions does the form need to ask? Where do the answers go? JG we can start with just simple text there. Once the mechanism works we can subsequently add the Form functionality. HTML Forms or some bespoke form code? JG we can use JIRA Service Desk and get them to fill in the form there. DA: Can this be integrated? JG yes, if we redirect them to JIRA and to a specific form we have to create in the JIRA Service Desk. Then it gets stored somewhere in Confluence.

MB we probably do not want them to use the JIRA Service Desk since that would make them part of our ecosystem whereas this is for the wide world. MA requirement is this is free for anyone in the world. Suggest Name, Company, Position, Email. In an HTML form.

JG proposes we do this as a text entry first and only then implement the form. DA however, the PTB are already asking when it will be ready, so doing an interim test with text will not help.

RC why not model the form after the Protege form: this asks what project they are working on. DA finds the Project thing off puttingGive them free text and let people put a GitHub link in there if they want to. All like that. We can do this agilely, get the cookie thing working first.

JG: there is a Fire interface that generates regulatory data. For health records / regtech. They look at FIBO but "cannot download it, there is nothing developers can use, we just see words" So this is the problem we are here to overcome: something people can download right away and we want to know who they are. Not a paywall.

DA we can leave the cookie out, just have a complete honor system. have a button on that page where you can go right on through. In the EU you have to tell people when a site is using cookies. "Please tell us about yourself". No cookies. JG the cookie is needed as a flag to bypass this on subsequent visits. You don't need a cookie if you know the URL for the place you are going. Cookie does not contain any personal information.

We don’t' yet generate HTML pages for OWL URLs. So we have no place to hook that text in. Put this at the front page, where people first land.

Someone not coming in from the front already knows where they are going anyway. For EU Data Protection, it is a requirement that when we take data from people, we put up a sign saying what we are to use the data for. Do we need the cookie? What it would do: someone coming in a second time from the top, would not see the form again. The alternative would be if they bookmark a page after having filled in the form. But that would split the landing page so suggest we don't do that.

There will eventually be HTML for all the ontologies and elements that have a URI, so that people with browsers see a choice of views on an HTML page. However that does not need to interact with this form/cookie business. DA what will be ready when? JG will put the text on the home page this weekend. DA can do that now. Then identify what questions you want to have in the form. Can email the form and press a button, that send the form content to someone's email address. This is supported as standard HTML functionality. Could email to Carole. Or ask Dennis who it should go to. This uses the mailto: feature. This generally uses the user's own mail client. Doing it on the service side requires that you set something up on the server side. As a stop gap we can use the HTML forms and mailto feature, for now. DA will go ahead and do this. Needs to as DW what fields to put on the form. Along with the freeform field where we encourage people to put links and the rest, including gtihub links, all optional.

Next topic:

As a group we have done well with making FIBO available for others We need a plan for people on FCTs working on FIBO. They want to work on the source code. These people will want to load in Pink, add something into or change that, and ensure it still meets the high level of scrutiny required for Pink. For example running Pellet in Protege. So they will need all the stuff they already have, but locally. Incudes About file, catalog etc. for the piece they are working on. DA wants to figure out how to make that as transparent as possible. This applies in CCM as well as the rest. CCM seems to transparently use About and Catalog in the same way as Protege so this should be transparent. However, the start point needs to be the same. CCM users there are scenarios: Round tripping (support existing diagrams). Outside user, uses CCM in a clean copy to create new OWL just like any other tools user. Need to document and test both scenarios.

Someone has FIBO source on their hard drive. They run a version of the RDF Toolkit. An option in that, crates the kinds of artifacst they need (About/All and Catalog). DA idea: if that utility examines each ontology file in that folder, asks each one for its disposition (Pink Alpha) and build an About file that imports all and only the files for that disposition. One woold be AboutFIBORelease.rdf and the otehr would be called AboutFIBOAlpha.rdf. Then when they go to CCM, TopBraid, Protege etc, and open that About file that will give them what they need. Issue: all files import others e.g. a file in Pink could import a file in Loans. Would get wrong disposition. Not sure if that is a real problem. JG that would fail the job. DA - not at this point, as there is no job at that point. JG when they check in to their branch then the job will run and catch the issue.

First job check: if you are importing Pink then if you import anyone whose disposition is not Pink. It is far more cost effective to detect such issues before doing al the work not after. JG you should always push to your own branch every day or more, in any case. Then Jenkins is a back-stop about whether you got it right, after the event. Eventually the RDF ToolKit can do all those tests.

DA: When I build the About file I can check the entire import heritage at that point in time. Flag it right then and refuse to build the About file. JG: The Build is a test in itself. Has to be perfect If it is not perfect it fails. "WE can't share bad things"

What about the MB scenario where we want to promote something from DirtyPink to Pink? DA how this works: the FCT otologist would check out the whole thing (master) in one branch. Certain components are marked as Pink. Wants to bring in something that was DirtyPink. changes the disposition on their own local drive, to Pink. This loads some things, including a couple of things we now don't want, that are to other DirtyPink. Once I no longer believe there are any remaining DirtyPink references in that new ontology then I am ready to try a build. At the point, push to GitHub. the Build spots if you missed any DirtyPink material. If not, push to your branch.

What means "change the disposition of"? This is defined by the System ontology that Elis is working on, but the information is stored in the ontology file itself as part of that ontology's metadata. e.g. Disposition=DirtyPink. Would change that disposition as an edit. We already agreed it should be in the ontology itself. We need to extend the metadata, to support EDM Council metadata. We would use the Artifact ontology in exactly the same way we currently use the SM ontology from OMG and the FIBO AV ontology.

JG: Currently we have TBox and ABox, with the ABox individuals not in the ontology but in a config file. We want this individual disposition information stored in the ontology itself, not just (or not?) in the RDF ToolKit Config file. JG: The references to those dispositions can be stored in the ontology files. These then refer to individuals in the config file. This is more complex.

The option we talked about a couple of years ago, was to store the status in the file itself. So e.g. hasDisposition would be in the artifact ontology (like SM). THis is not governance for the standards process but is governance for the publication. This is an annotation property.

Specifically, in the existing stuff we use instances of annotation properties. Could have a way to read the disposition and pop it into the configuration ABox file.

JG proposes that this be an object property such that it points to a distinct ontological thing that is a maturity level. Then we can create a landing page for that

where that = /master/latest/Pink where Pink consists of these files, classes etc. At present, maturity level has been defined at ontology level rather than class level. Even having this at ontology level depends a lot on the integrity of our modularization process.

Decisions:

Action items

Browser not supported