/
2017-07-06 Meeting notes

2017-07-06 Meeting notes

Owned by Dennis Wisnosky
Last updated: Aug 17, 2017

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 spec.....  Pages

Discuss the final push to the 30 June Publicatioon

Discuss the next release process

5) For next week.

Proceedings:

2017 FIBO FPT RDF ToolKit


See email agenda - main thing is to go over the work last week on spec.  See overal launch page spec.edmcuoncil.org - this now has extra stuff e.g. GitHub and JIRA signup.  The new EDM Council website will result in this landing page changing.  Any comments or errors on this page?  


JG: Too much text that should be on sub pages.  JG the /fibo page also has too much information.  JL: error: wikis should not have an apostrophe  The 2nd mention of this is correct (on the right)  DA will correct this.  DW did the HTML on these pages by hand this time around.  


To the /fibo page...  There is a repeated sentence.  This somehow relates to SourceTree.  DA walk through each item in turn.  


Glossary/Production:  Was generated using the Natural Language Glossary export from CCM. DA created 2 profiles for this in his own CCM, defining which sub-set of the models in CCM are used to generate the Glossary. Called Production and Development. The resultant files are also so named.  This is done by hand. Need to use the headless version of this when available, until then, this is done by hand.  DA also had to post-process some of the results of the Glossary output.  For example, there was a class called Unknown Class that showed up.  An issue is that the thing in CCM was imported using a hack that deals with the cascading restrictions, where there are named classes for the cascade nodes. At present that also has to be done by hand.  That is unacceptable and also means we can't round trip since the hand edits would have to be unwound each time.  Possible the odd Unnamed Class came from that.  In the real world, we need to be able to produce this automatically, including the header for the page (with the EDM Council logo).  JL; DA has done the right thing by modifying the template in CCM. This can be exported and checked in to GitHub independently, so that others can check it out and bring it into their CCM.  Back to the preamble: is there a way to customize the HTML - specifically the EDMCouncil logo image tag, the page title.  JL: we inserted a variable, we can probably take that and put it in the shipping version of the glossary.  JL it may be possible to do the same with the logo, if a URL for the logo is already present.   JG: Surely this should be the FIBO logo.  Or both.  DA was aiming for uniformity across the pages at this stage.  JG we also need higher quality logos, please can we go back to the source for these. Looks unprofessional.  


PR there seem to be names at the end that are not real classes but are names of restrictions.  These are the things described by DA just above.  DA there will be a round tripping that will respect these things, by imitating DA’s hack.  Also need a way of leaving them out of the Glossary.  JL we also have SP10 ready to do some beta testing as of this morning. This does implement the cascading restrictions support.   JL there is also a separate piece: the cascading restrictions use un-named classes that maybe the domain or range of properties. The approach to naming these things is not implemented. Also, the NL Glossary does not represent those yet.  MB surely we want the Glossary to not support the nameless nodes.   JL the plan would be to replace the node with a phrase that summarizes what that node is about, e.g. "situates some commercial activity".  CORRECTION these will not be defined in the Glossary but they will be reflected in the Glossary, in that classes that are defined in terms of these will have them as part of the bulleted definitions of those classes.  


JL: A better approach to finding things in the Glossary would be to use Java script. At present, we had a pull down that scrolls off the page. Makes it hard for users to know what to do e.g. <ctrl>F  Also can't search for a string that occurs in the middle of a term.  DA what we have is a quick and dirty solution but we need to find some Java script that will make this easier, as some available open source Java, and pop that in.  DA this also brings up the previous question about how to include things in the HTML.  


Decision:  For Glossary, do we do nothing until 20170930?  DA yes - the requirements are all as minuted. These are:  Automate the thing.  Be able to update the headers.  Find better image(s) for those.  Find and include script to improve searches.  


PR can we now hand edit to remove all the stuff at the end?  DA yes, since we are maintaining this by hand, DA will remove those things now.  


ACTIION:  Remove stuff at the end that PR does not like.


Vocabulary  Currently has Development. There is something we can do for Production.  DA this requires filtering out the ones where the maturity is Production.  At present this uses a query that is too slow to use.  So DA did a hack using grep. This is fragile but usable for now.  DA has got this to run this morning.  Want DN to have a look at this and then he will add the links to it on this page and on another page that is a compendium of all the products.  DW what is GZ?  This is a Zip program similar to but distinct from PKZip.  


DA what is our policy for compressing? Have been seeing GZ.   JG: The GZ option is supported by nGnix even if you e.g. click on the Turtle link, it automatically serves the GZ file and the browser unzips it.  This corresponds to things DA is currently doing by hand.  Some people want the ZIP as one file, others will not.  For our users, they are going to want ZIP not GZ.  DA will copy the code that zips things, and zip this and put the links here.  Production for SKOS will be later today. Unless DN vetoes it.  


ACTION:  DA will change gz to PKzip.


ACTION:  DA will add a production SKOS today. 


SMIF views:  DW this has been a huge effort over the last couple of weeks.  JL style looks good.  DA this was partly by hand and partly macros.  The entries in italics go to diagrams, on the Collaborator server.  Once you are on the Collaborator server, you are now in Collaborator's own context.  It proved not to be possible just to have each diagram dropped into place in our structure.  JL if you click on white space in the diagram, you get a link for just the diagram.  JL expected this to be a diagram we could use stand-alone. Was surprised to find that using this still took you to the contextual view of the diagram after all.  DA on his machine when you open a new tab it has about: (blank) as its context.  JL he gets an odd thing called data: (blank). Gets some scrambled stuff that mat or may not be a picture.  The diagrams all have (AB) at the end. This is confusing.  DA has taken those off on the front page but not changed the diagram names.  We can change the diagram names in CCM - perhaps by a (careful) search and replace.  


ACTION:  MB to rename these diagrams ending in AB.  

OWL:  This is distributed ontology by ontology not class by class.  DA has links to the ontologies in the usual RDF formats.  This is not necessarily the most useful thing. Would people want to make use of a single ontology?  Check with Corporate Bodies (TTL).  PR a number of the files seem unavailable giving a 403 error.  DA this is probably a spelling error.  This downloads or opens in Protege depending on a person's set-up.  


DW congratulates DA on the effort to do this.  DA there is again a huge by hand component to this.  MB we should maintain the list of things we need to do by hand.  MB now would be a good time to implement the proposal where we change About to All for the all-importing file.


ACTION:   Dean to change one of the about files to ALL for the all-importing file.


PR on ontologies - see emails of 3 or 4 quite significant problems.  DA had a dangling comment on SMIF above.  PR Emails:  DA has seen these, not gone through all of the details yet.  To the question of where we report and track these: DA proposes we use JIRA in INFRA.  Assign to DA in the first instant and he would reassign as needed.  DA this was the kind of vetting he was after.  


PR - some of these seem easy e.g. inclusion of /latest/ and /master/ imbedded in the URIs- seems an easy fix.  DA this is the versionIRI. This is the way it is supposed to work. Import statement says imports latest and the versionIRI fetches latest and this looks in a thing in a folder with that information.  The question then was what to do about the class names e.g. whether these had the versionIRI.   Recall this was where Protege 4.3 and TBC had a "loop" problem caused by this.  DA has a hack that is needed for TBC, but this does ot work with RDF or JSON files.  THis is a well known situation. If we don't like the current config we need to revisit that.  PR: StarDog also does not resolve versionIRIs  DA maybe there is a magic cookie for StarDog for at least one fo the formats.  OR you can download the NQuads.  (the NQuads is one graph and has no imports),  DA proposes: not change our versionIRI strategy.  Does JG agree?  DA: The issue is that a lot of the tools don't respect the versionIRI. Instead such tools say you should be able to import something by one of its IRIs. Protege now works this way but TB and StarDog do not - these are considered failings of those toools not of our config. Given that DA had to do a workaround for TBC, and PR has the problem with StarDog, it will be the case that others looking at our stuff will also need to know how to do this.  JG maybe do 2 versions, one standards-compliant and one that bypasses that.  This would leave out the section of code the JG wrote that re-writes the IRIs, so the non-standard version would be that version that misses that code.  JG do we really want to do that?  DA agrees with the decision that required that code, so happy to continue doing just a version that uses all that.  


MB: we should publish just the canonical version (standards compliant) and then publish notes giving details of our workarounds for these tools, so there is clarity about the release.  


PR why does versionIRI have words like Latest - should surely have e.g. 20170630 type ofIRI  This can be reversed out.  PR the actual value of the versionIRI doesn't represent the version if hit just says /latest/ -we should have something representing this given release e.g. 20170630.  JG this is supposed to replaced using a tag.  We should set a tag in Git.  We should have set a tag in Git on June 30, itself but we did not.  Will that come through if we do it now?  JG Yes.  DA then latest, and that tag will be in synch, and as we move along the latest will depart from the tag, until September when we set a new tag for latest.  DW can we do that now?  Will that trigger the Jenkins job and make it all happen?  JG yes, but the Jenkins job should also trigger when you set a tag. This has not been tested but should work.  DA next week's Friday meeting in Cambridge: maybe we can plan to use part of that as a working meeting to do the above actions, so we work in it together.  JG will come to Cambridge for this.  


ACTION:  DA, JG, TC, MB meet in Cambridge, UK to set publish tag to publish date, not latest.


More topics:  The Table (added yesterday).  This table is at the bottom of spec page.  This will be updated with the items that come out today.  


Next item:  How much will we do in July and August? What can we promise for September that we know we can deliver?  DA: streamlining what is already here. We could do a by hand process in Sept. A lot of the work between now and September will be the automation.  This is for Glossary, for SMIF diagrams, and move to SP10 for round tripping of cascading restrictions.  This should be transparent to the people using this.   MB: So we can consider what FIBO content to bring in Sept, independently of this.  PR - there are inconsistencies we can enforce.  There are naming inconsistencies in Production.  We can do a full pass through the Development labels as well.  There is a round tripping implication on these labels.  Of all the potentially correct ways to map acronyms to URIs and labels and vice versa, CCM has chosen one, ISO 20022 has another and the undocumented OMG-FIBO insistencies involves yet another.  Consensus! we should follow ISO 20022 if possible.  


ACTION:  MB to dig out the ISO 20022 naming / transformation convention for URIs and labels.


Next things:  JG is working with REACT.  JG on our side it is a complete switch-over, Will copy things we build in V3. Will rebuild the whole thing. This is the same one as the spec site we can make progress there.


PR: his team is working on a React-based interface on top of StarDog, working on a FIBO based interface.  Hope to have a working version in a few weeks based on FIBO Master.  


See also the isDefinedBy issue per PR email. Has sent the SPARQL and RegX stuff for that, to DA, who will work on that.  

Next item:  Getting 500+ people off GitHub and onto Spec.  This is why we have the Feedback button on spec.  Any cautions on getting people off the GitHub and onto spec?  JG we are using the authentication from GitHub even for people who are not using Git itself.  DW the new EDM Council things will have that.  MB we see emails indicating that people have created their own Fork of the GitHub repo.  JG we want to try and lure people by them logging in either via GitHub account or other accounts, even Facebook etc.  There are standard libraries that support that. Anything we can do to make the user identify themselves would be good.  Anything else would be like a paywall.  MB the question of using GitHub authentication is unconnected to whether or not we le tthose people still access the /fibo repository.  This is about what groups people are in.  DW wants to revoke those members' access to GitHub/fibo and also point them to /spec  PR a downside of that is people will not get updates except every 3 months.  JG eventually we should have our own registry of those users on /spec but that is separate from authenticate people.  We will table this for now - maybe find a gentler way of moving people across rather than just removing their access.  


Next week no meeting.  Slower in July and August and pick up the pace in Sept.  DW thanks everyone for the hard work that went in to the spec release. Mike Atkin is very pleased with what he has seen.  FIBO is now out of the closet and available to everybody at any level of competence.

Decisions:

For Glossary, do we do nothing until 20170930?  DA yes - the requirements are all as minuted. These are:  Automate the thing.  Be able to update the headers.  Find better image(s) for those.  Find and include script to improve searches.  

Action items