/
2017-05-16 Meeting notes

2017-05-16 Meeting notes

Date

Attendees



Agenda

0.0 Dean's analysis from last night.

1) Where we are on our road map. 

DW the ask is can now all load in Protege and TopBraid. Next is VOM and CCM. Meanwhile we have JG and DN agreeing on what an acceptable first cut in HTML is. We have http//schema.org now. If we can do something with SMIF to show what it would look like, and if can put a pointer on that, e.g. do BE and have it point back to the be folder in the ontology structure to close the loop - can we do that to be published June 30 as our 2nd quarter deliverable."  Want to announce at 8 June EDMC members meeting in NYC.  DA will be there.

2) Open Action Items

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

4) Todays content discussion.

BASH progress - DA

KT will join us on TH.  

From KT if the attached is an accurate representation of the conceptual structure encoded in the directory names?  ProductsAndServices, upper right corner exhibits the property that gives raise to the question.  Likewise FunctionalEntities.

5) For next week.

Proceedings:

2170516  FIBO FPT RDF ToolKit


Dean analysis from last night.  DW suggested that CC and JG recommendations had been diametrically opposed, but Cory responded that this is not necessarily the case.     JG walks on water.     The issue is with opening published version of FBO in Protege when there are import cycles, something it normally handles OK as it has what's called a Loop Buster.     So, the analysis was why the LB isn't coming into play     Others who had no trouble were opening the source files not the published files.     The published files import the versionIRI as first proposed by JG. Dean did research on this and found a note by Peter Patel-Schneider about the implications of this. PPS recommends the behavior JG was recommending.     Protege follows this suggestion but makes a mistake. When it imports a versionIRI, it records this as being the actual IRI and so further imports of the (version) IRI do not detect that it is something already imported.     Changing this to import the actual IRI makes it go away.     


Our policy to not have loops would make this moot.     There is a bug in Pink FIBO FND has this issue.     That will be fixed.     FIBO-Master still has several such loops - at least   exist.     Recommendations:       Abandon importing versionIRI (DA dislikes).  Track down the loops anon fix them, which we hoped to leave to the FCTs.       MB check the extensions, these are a likely culprit. The original EA model had between one and a couple of these. Test without the Ext.       CC why importing and not referencing the versionIRI in DA recommendation?    DA: per PPS note, you have a whole bunch of files you know have gone together. So you want to be able to import all of them. If you have a version F you have a Master Import file that imports F. Then is there is one that several of them import, you would track which ones each set of tested ontologies need to see. This leads to the need to chase the versionIRI. So the import system should find and open the ontologies it has been tested with.      


DA likes this, Peter PS has gone through all the test cases. Seems a good thing for publication of a multi-versioned standard.    This is the JG proposal as implemented in the current Publisher.       


JG other motivation is you don't want to load one version of something in Protege and end up getting an untested thing. Even if you would not use utility version of FIBO in one triple store, then you always have copies lying around e.g. local copy. So that version if you don't use tag for master / latest, then what version is that and what does it import?       Importing a newer version from the web may not have been tested with the one that is importing it, even if it is fine in itself.       So we need to ensure that what is imported in a given tested set is always the se set that was tested.       CC no problem with this but felt the mechanism seemed under-supported. Whatever is published as FIBO we hope is one consistent version.       


JG people may also make copies and use parts of it and the imports statement will follow a number of noses via FYN so if you use latest this gets you in trouble.       DA - Protege almost encourages this. When something not seen in catalog then Protege goes and finds the latest online version rather than the offline version. Without reporting that it is doing this.   Another reason Protege should never be considered an engineering tool (MB).   


JG current arrangement uses the 'latest' key work which points to the most recent in Protege. An alternative is to use a redirect using the git checksum as the actual version number. This identifies a consistent set of ontologies as tested.       DA: Both Protege and TopBraid are buggy in terms of the correct behavior as described by PPS.   Should index a versionIRI import those and do the loop busting correctly.     TopBraid issue is it doesn’t index the versionIRIs     Protege issue is it indexes the but then doesn't take them into account on subsequent import.       


DA conclusion: Protege and TBC not implementing index and loop busting correctly.   JG agrees. Maturity of the tools.


ACTION:  DA Notify Protege and TBC of their not FYN issues.       Meanwhile make sure we do not have circular dependencies.      


If Protege fixes it, people are still using .3. DW we already made it official policy that people use the latest version of Protégé 5.2.   


Usual way to manage circularities is to refactor the modular structure. Hence leaving it to the FCTs.      MB there are real word circularities which will require some layering in the design.      DA and DN dealt with this in one of these, in BE (shares to companies to shares). Used layering approach.  Suggestion is whether we are doing this consistently.      At other points FCTs seem to be making compromises to the semantics. Need a consistent policy.      DW can we get rid of those and get the FCTs to deal with them when they come up?      DA if you break open the link you will get undefined references.      DA doesn't recommend this.  Rather we open an About (All) file. These will have complete disclosure.      Can just say "anything you open that is not in All" you are on your own.      MB can we just merge modules when they are circular?      DA only if they are all within the one FCT domain. Ones seen to cross domains      DA the Getting Started documentation should tell people to open the About file.     


ACTION:   MB add telling people to open the About file to the Getting Started guide.     


Are we calling these About files or All files?     DA too soon for that discussion, so MB can update the doc if we change the name of those. First the circularity issue to be dealt with       DW this doesn't change any of our policies. Solves the problem by implementing a policy we already agreed on.      


ACTION:  DA Find all he loops in Master, arbitrarily break them. Make sure that after this the loads reference the About files. Test in Protege.


It will be left to FCTs to deal with the circularities in their work.      


ACTION:  CC test loading Protege, using FYN and no catalog.    CC: Protégé is loaded.  Took a long time.  <https://spec.edmcouncil.org/fibo/ontology/master/latest/AboutFIBO.rdf>       


If fixed in Protege   then we do not need to action the loops prior to FCTs work.      


Next item : The Bash Thing      DA: has the catalog files publishing into the publish pipeline. Has built a bash version of the catalog file generator and out it in the publishing thing, There are some issues but this is under control. Expect to finish shortly.      Did not use the Python Version Bash version is a stop gap.      


KT will come on Thursday, has sent a presentation to see, on FIBO NQuads.      See wiki for these.      JG has been corresponding with KT on these.   Wants one file with all the ontologies grouped per graph where the graph IRI is the ontology IRI.      Any issues specifying what KT needs?      DA no issues. Just give a name and in the website we generate for all this we need to make it clear what you get.      


Action items Review      DA    related to the catalog issue. Had not done the documentation described in this task.      


DW action – on hash slash policy - done. Will verify MU has put it in the wiki.      


DW action re KT - done      


DA/TC action on RDF ToolKit  TC: They would be able to do this thing on demand but would not be part of the githook.      DA issue is that in publication setting the catalog generator needs to be sensitive to the branch details. Doing it stand-alone would need to take it from your local setting so there are different behaviors to support.   


ACTION:  DA will document the different modes the RDF ToolKit must operate in: Git context related and stand alone.


JG update roadmap - DW did this


EAL Artifact ontology   EAL: This is on pause until June. Has all he needs.    Is this blocking anyone?     Not at present. Can retrofit things later.     


DA "what JG says will work” task.     This is about how the files make from JJIRA all the way to the server.   JG has explained this to DA who will write it up.     Catalog Plan JG/DA     Mark as done, based on the above.     


SKOS Generator    DA not fixed that JG has done it. So no JIRA needed.    


Website design CC/MB/JL    relates to publication plan for June  .    Focus on BE.    Is this more complex because CCM involved?     CC not complex. Need to look at how the different perspectives are linked.     Diagrams are originated in CCM     Work is in producing the organizational diagrams that allow us to get into the detail and make sure these generate in a way people can resonate with.     


HTML generation - any views from DA?     DA no except that SKOSMos is a good direction for FIBO-V. Has asked Matthew Horridge about OWL.Doc. Otherwise agnostic.     


JG architecture action     This is schematic of where the various things will run System architecture. JG can do that.     


JL, MB, EAL: consolidating single master governance diagram.     EAL had started a draft. MB had presented another part of the process in OMG meeting.     Need to clone with EAL and JL diagrams.


ACTION:  DW will Elie and JG diagrams to MB who will consolidate     Will be part of documentation as well as process.     


JG action about BNY person to do HTML?     The person disappeared, due to production pressures at BNY. They are now in production but have more to do. Hope to free up this resource by the end of this month having implemented the knowledge graph.       Done jointly with NJ and London.       Normal work schedule by end of May.      


MU action on candidate hygiene policies. DW has actioned some of these today in JIRA on both hygiene and maturity levels.      


Next item:      We are committed to an announcement by June 8   EDMC NYC meeting.      Maturity levels expected by Jun 2.      


Generating HTML - have a plan.      


Schema thing is in hand .


CC there are 2 parts to this: generating the views, and how they are linked together. See CC PPT from  2 weeks ago on this. We need to understand if and how these generated views of FIBO are connected, both for a visual thing and a technical approach     


JG need an extremely consistent URL scheme for all these products. Then you can predict where things will be.      Similarly, for Vocabulary, if we would have a file per business term with its URL this should be known and predicable. Need a very strict URL convention.      Then the HTML will work.      then the question is only what links we will generate for those HTML pages.      


CC the use of a consistent header to handle this would mean we don't need generated links in each product      Consistent Header - HTML common material at the top of each web page as per slides.      DW - that is interesting graphics, but in the short term need to figure how to populate the initial landing page.      Cory's thing was a specific technical structure to do that.      


DW this is no different to what we did last December. Has CC looked at that?      CC suggesting that each product view is as loosely coupled as possible to support different generation, but have consistent URL scheme and a standard HTML header that knows about the URL scheme so you did not need to generate these links from within the generated products.     


JG we can generate an HTML header, menu, side bars or whatever. Can generate a high level index into the whole site.     

Decisions: 

It will be left to FCTs to deal with the circularities in their work.      

Action items

  • Dean Allemang.  Notify Protege and TBC of their not FYN issues.       Meanwhile make sure we do not have circular dependencies.      
  • Mike Bennett.  add telling people to open the About file to the Getting Started guide
  • Dean Allemang  Find all he loops in Master, arbitrarily break them. Make sure that after this the loads reference the About files. Test in Protege. 
  • Dean Allemang  document the different modes the RDF ToolKit must operate in: Git context related and stand 
  • Dennis Wisnosky  will find Elie and JG diagrams to MB who will consolidate     Mike Bennett Will be part of documentation as well as process.     
  •