/
2017-06-13 Meeting notes

2017-06-13 Meeting notes

Owned by Dennis Wisnosky
Last updated: Aug 03, 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 Jacobus latest email to FTP members

Deans plan as a result off 20170612 FLT on 30 June content

Look at current HTML in spec.  DN says it is the wrong one and should not be called glossary anyway.  That has always been the plan.  

How do we deliver N-QUADS - DA

How do we deliver Linked Fragments - Omar

DN says we should remove history before 30 June pub.  FPT and KT seems to think it should be there.  If yes, then in a separate place so not to confuse casual users?

UML for 30 June - MB, CC, JL

5) For next week.

Proceedings:

20170613 FIBO FLT RDF ToolKit


FIBO Glossary: Headless CCM and running report.  JL this is simple and documented.  DA the issue is figuring what server to run it on and such matters. So this remains a task to be done, and requires someone who know their way around our AWS and ecosystem.  JL: MagicDraw and CCM run on Linux, Windows and others. It is a Java platform application.  DA is it generally accepted that the report that CCM produces is the one most people are impressed with.  DW what does this look like?  The report called Natural Language Glossary seems to meet a lot of our requirements This is something we have seen on Collaborator, but is also available as a direct report output from MagicDraw.  JL demonstrates - has Natural Language Glossary on the menu but this may be as a result of running the Report Wizard in the first instance. The NL Glossary is available as a menu option in the Report Wizard.  You can select Scope on this, by adding recursively  We will have separate top level folders for each status of FIBO.  There is a test branch where Pink has been imported into FIBO-Master.  This has been tested, and will be done for real following the conversation between MB and DA yesterday about what does or does not need to be in place, policies about top level folders and so on, for the official version.  


Today we are looking at a test run of that change.  On tests with Lithuania last week we uncovered a feature whereby if someone with a more recent set-up opens (or even touches) the file, even without committing, it created changes in the resulting file.  This was the thing we needed to fix for MB, DA, Ashely and everyone. This was unwound last week.  


Next item:  Email from JG this morning.  JG: The idea is to create something else longer term, (we currently have a temp solution based on bash scripts and not using the OWL API).   We currently publish artifacts for each version of each branch. Anticipate we will publish those for many years. People may be using specific versions in their own production systems for a long period of time.  So a user needs to be able to get an exact version of FIBO at all time. Since disk space is cheap on AWS we can publish every version for every tag that we set, for all the deliverables and all the  flavors of OWL and so on.  We can generate something in e.g. JSONS-LD that is like an About file but covers a range of products that are in JSON-LD as well as the OWL, and have the structure of the modules etc., (with nice labels). Can generate all these in every version that we have with all the right URLs.  This is all server side.


We do all that but JG doesn't like how we do it.  So the propose is to create another product, which is a single-page application (per the new style for building web sites). This has one page index.html such that for whatever URL you hit it loads that single index file and that file is the starting point of the program that drives the single-page application. This generates a bunch of java scripts to your browser and that takes over.  This also controls the URL you see in your browser.  Note that the URL you see in the browser is not necessarily the same as what it is actually using.  From this you can create the different views, e.g. the taxonomy views, and to Glossary and Vocabulary (as views into FIBO). Have a link into that page that looks like a link to spec.edmcouncil.org, but is not a URL that resolves to an artifact but resolves to a page on your local machine that is generated by the code. That can be a page for a class, a property, or whatever else - all the concepts we have described.  For each page you then would see what kind of visual @modules@ you have available for that page e.g. a TopBraid module, PoolParty or whatever any vendor contributes as a module to FIBO as a module for visualizing the ontology in a given way. Then when you click on the module you see that module on you screen, can max, minimize etc., and can enablel and disable on demand per user.  


Then we create a platform that allows anyone to come up with new modules and show (or appear to show) those modules on the spec.edmcouncil.org page, although these need not actually be any file on the server side. For example, they can reach to some other server with its own URI and call something there and create what the user sees.  This would be a platform where every vendor can showcase their products.  Can link this to services such as stack overflow, to have discussions on the content.  So these discussions can be integrated, as can threads on LinkedIn and Twitter.  These are all possible integrations we can bring together on one site.  Can include ontology viz such as VOWL, we can show test items, object diagrams and soon.  


PR is there some common API both for configuring this and allowing the overall page framework to communicate with and bring in those other components.  PR also we must need some control over what components are brought in.  JG yes - we own the master branch, which is what gets published on spec, so anyone can create a fork of it currently called specsite, a Git repo on EDMCouncil.    We could describe documentation for instance telling people that if they want a module to be displayed they should use e.g. the React framework (this being the one JG recommends). There is a version called React Native for native iPhone or iPad apps with the same logic.  So the website itself could be delivered as an iPhone app using that.  This could evolve into a generic platform for KM in a bank.  We can create enterprise versions of this where a given bank would create its own workfow and so on, around this.  Meanwhile, FIBO should look cool and allow easy access for people to understand, visualize and point to (via links) the FIBO content. Also get feedback.  


DW: What shall we do with this now and does it have any connection to or deliverable in  2 weeks?   JG hope to create super-simple basic version of that, which does the same thing as now,but in a better way, and is integrated with the feedback form.  This would get rid of the directory listings. Start with a bare bones version of such a framework, Allow people to contribute their own modules.  Becomes a community effort.  Charles Ivy (sem tech company in London) has some Java scripts at banks, wants to be able to contribute.  So the appetite for helping is there right away.  JD of StarDog also interested.


DW agree about the current state. But if we are here on Jun 29 ready to push some button, where is it and what do we do?  JG make the current site a little bit better using this technology, let people explore the vocab pages etc.  


MB does the notion of a specific element IRI still exist in the new framework?  JG Yes. If you click on a link to a specific concept in e.g. a Word doc, then the program gives you an except header that says "I want HTML" and loads / gives them the single page application (index.html), then the app loads( seconds) and the URL you clicked on is processed by that local application (server is passive at this point), and the browser now does some REST calls to spec.edmcouncil.org to find the right JSONS files to Bering you to the right page and generate the page for the concept you originally clicked on.  


PR is keen on this architecture, Adaptive are developing something that uses this see, e.g. the FIBO Search on their website. They are revamping this and building it on StarDog.  So this is a good time to do this, Adaptive has people working on React and StarDog.  


JG can we integrate some reusable components that Adaptive has and link to that on their platform - this demonstrates the notion above about integration with vendors.  


DW: How much can we integrate by June   JG: Not much. Aim to put this in place instead of the thing we have.  DA there are things to be in place by June. We need to at least style the spec.edmcouncil.org landing pages (pages). There is currently no CSS. Also proof read the content. when we click through we need landing pages for the content that are understandable.  Currently end up with direct to links or a single e.g. NQuad file. If you are clicking through to a directory structure you need expectation management for when you land there.   There are the things needed by Jun   For the styling, not a matter of just using CSS but knowing how to make a good visual style.  


JG notes a Google feature that lets you generate a slick looking site using a thing called Material Design.  We need at least to decide on colors, and need a better resolution (SVG) version of the EDM Council logo and the FIBO logo.  For colors, we should look no further than the upcoming redesigned EDM Council site.  This includes deciding whether to have same styling as the EDM Council site.  FIBO could have e.g. its own color scheme distinct from the EDM Council site styling.  Meanwhile will not change any of the colors we have currently, use that as a starting point, then can have the EDM Council determine any needed changes based on sight of that.  


JG has a demo already on the specsite Git project,  Uses React-MD.  There are parts of this called Drawers, so you can use these as components, e.g. for people's logins.   Assumption is you would choose products from some menu here.  Whenever someone pushed something into this new repo it builds something (using Travis, not Jenkins at present; this integrates well with GitHub).  Builds the application on the GitHub site based on the script that runs.  Travis does the same things as Jenkins, but faster.  Is JG suggesting we switch from Jenkins to Travis?  No. Use Jenkins for the current stuff. Jenkins is more configurable and support pipelines.  So, the Travis stuff he has done would be migrated to Jenkins.  DW we have something up there. Would we use this to replace that?  JG currently it outputs to specedmcouncil.org/fibo/ site.  


DW can we have this in place by June 30?  JG believe this is possible.  May need help.  There is a learning curve, mainly with React.  Since React is what Adaptive are doing, this should be an easily defensible choice.  Anyone can create their own components under the Components.  Components here means what was above termed as Modules (visual modules).  


JG still trying to convert the MArkDown on the fly to an HTML page.  Currently the markdown conversion does not work.  Wanted to do this so you can maintain the original text in MArkDown without HTML knowledge.  PR there is a React component to display MArkDown.  


ACTION: PR will send link to JG for a React component to display MArkDown.


DW Can Adaptive help with this?  PR this is a bit out of the blue would need to find out. Can certainly provide pointers based on what they have done to date.  JG would appreciate help from Adaptive with code reviews.  OR try to link this with Adaptive's FIBO Search component. This is being updated over the next few weeks.  So not by June 30. PR can't respond formally about what commitment Adaptive can make on this.  


DW question for others working on content, e.g. DA. When can they start testing where that content goes.  JG can test this now but would need to enhance things also create new files to generate the right content (JSON files), so that the thing ends up being a discovery tool that goes to the server side and discover what version we have, and then digs into those folders to find the relevant JSON files once these exist.  


What format of JSON does this need?  JG normal JSONS which is easy to parse and understand in the React context.  For instance, a JSON file that is a list of all the ontology files we have at the moment. This would be a file like the About file, with the title, short name, list of the files and so on.  PR there is no such thing as generic JSON.  There are families like JSON LD and dialects within that. Need to know the field names used within JSON.  See e.g. last week's discussion about how to generate all the files. At Adaptive they are querying StarDog and getting results back in JSON-LD.  JG a file based way of doing this rather than a StarDog database at the back end, is easier If we used a StarDog database we would need one for each version.  


DW next steps:  Need to link the content that DA is developing, e.g. the Glossary that is on screen now. For our purposes this will be static content published to the spec site. What will this look like in JG's new way?  JG we can make it look like whatever we want. CCM gave him the opportunity to create a thing. DA produced a couple of templates.  The Glossary we are seeing now was created by Dean during this call.  We think DA would like to know if he can put a title on the single page that is the Glossary, as part of the Template?  JL yes you can modify the template in MagicDraw.  PR not comfortable with the labels for the  kinds of definition.  MB these need to both exist whatever we choose as the labels for them.  MagicDraw lets you modify these labels.  There is an oddity in the Glossary where some concepts is labeled as >- or similar.  JL there is a feature that lets you add a hyperlink.  JL if you click an option called "include properties in the glossary".  This is hidden in Options

ACTION:  All look at - https://github.com/edmcouncil/specsite

Decisions:

Action items