/
2017-05-23 Meeting notes

2017-05-23 Meeting notes

Owned by Dennis Wisnosky
Last updated: Jun 15, 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.


  1. RDFKIT-78
  2. JG answer to Deans Email 
  3. OK report on the Ghent work
  4. How do our internal developers work with our resources in a seamless manner?
    1. How do these developers run tests on their potential release before it is integrated with FIBO-Production?

Master branch does not build/test correctly

5) For next week.

Proceedings:

FPT RDF ToolKit


RDFTool kitinitially intended to be open. Now the wiki seems to be private. We should check this. Also once we do make it open, be wary of putting EDM Council information on it. Set it as "Open" as per the main FIBO space.  At present there is a long list of people with read/write access.  JG recomments it be open (read access) and have write access limited to those who request user ID. 


Action items:  BT action ingesting FIBO in CCM.  Did this over the weekend.  Her write-up - done but where? Sent to DW.


CC/MB/JL work on HTML - Ongoing. Move to a JIRA issue plus we have this as an action elsewhere. 


ACTION:  DW move CC/MB/JL work on HTML to a JIRA.


DA modes of RDF - not done.


DA loops in Master - was not needed right away in this time frame.  Still needs to happen but no longer in this time frame.


On the BT action - this material and the other two need to go to the Wiki and in the Bennett documentation. Copy to MB, Where to master such instructions?  Can wiki stuff be read by Jenkins and put on the HTML?  JG technically yes. But much easier to do it as mark down and put it on the Git repository.  Confluence also has history but would then no be in synch with the ontologies. In a related question, can the Jenkins things write new stuff to the wiki?  In that case, shouldn't the main landing page also be in Mark down?  We would eventually want to style this page (use CSS stylesheets) for formatting.  At present this page is in the FIBO INFRA repository.  But as HTML rather than MarkDown. Eventually this would also be in MarkDown.  MarkDown is usually used to document artifacts, whereas this HTML is itself the artifact.  So we don't have to use MarkDown but we don't have not to.  So which is easier?  JG: It is easier to maintain HTML page content using MarkDown. This restricts your options but this can also be a good thing for people needing to parse documents.  DW we will make this Markdown for now and we have some time to experiment. 


ACTION:  DA to change the main page to MarkDown.


DA Action on current state.  Not done yet. Relates to who does that when.


DA action to write what JG says works.  Context:versionIRIs and headers. Geluk, Jacobus https://jekyllrb.com/ Jekyll is the underlying tech of "GitHub-pages": https://pages.github.com/.  DA did it but not written up. By header here, we probably meant Cory's HTML page proposed header.  JG can make a simple header but make it look ugly so we are not distracted by that. Meaning that not all the ontology files have the versionIRIs.  The publisher can generate versionIRIs and so we can generate for all and ignore the source. So would then re-write the fie back including the ontology version IRI and maintain the comments etc. of the original This would be part of the publication process. Compute versionIRI at publication time from branch etc.  We should therefore say that the source ontologies should not have this.  Today: Pink has versionIRI, DirtyPink and Ext do not.  At present DA has been hacking this stuff in text.  Note this is all about the ontology file header not the HTML page header.  MB this header still seems to contain some OMG related annotations in Pink. What is the status of that?  DA this is still there.  MB we should review this at some point, and also figure out how to generate it for the EDM Council euivalent stuff.


Next action:  DA looking at that MB adding about the About file - MB doing this in docs - can close.


Main Agenda:   Omar report back on Ghent work.  See deck - this is from the Linked Data Fragments spec server people.  The notion s that instead of a SPARQL end point there is something else, called this fragment thing.  Seems like a good way to publish FIBO, aside from the HTML documents.  This alternative is called "Linked Data Fragments"  The server part becomes extremely light weight with most of the work done in the client.  TPF is the abbreviation for these triple patterns that you get.  Can navigate through from one concept or model element to another. Very fast.  Running SPARQL queries is also possible, using another thing that you can add.  This turns the SPARQL into this stuff.  It does also support a SPARQL end point.  The demo using FIBO took less than  min to set up.  This did not use a SPARQL end point.  There is something you could do. The Java script would take your SPARQL query, turn it into these fragments and use that.  So you can set it up against a SPARQL end point as well as against a TTL file etc.  There are examples out there where this has been done e.g. the Harvard Library.  We could also use a service where someone hosts this for us and we get them to point it at FIBO.  The LD examples are looking at ABox data sets.  The demo Omar is doing with FIBO is looking at the TBox stuff. So you can do either.  If we got Ghent to host FIBO for us, they would simply point to the spec site.  Does not support wild cards. Needs to be a single RDF file. So they would have to pull down FIBO and put it in a single file.  DA we have also been asked to make single file versions for our release, so we would do that anyway.  DA has a recipe for doing this, that can be made into a single product.  JG there would just be one version then.  There is a protocol called Memento.  With Memento you can have the RDF and have historical versions of the data.  Memento uses its own protocol for this and needs to be set up.  Are they compliant with LDP (the Linked Data Protocol)?Yes.  Uses Hydra to hit the Linked Data Fragments interface. See doc on this.  That is the Triple Patterns Interface, which has a doc. So does LDF itself.  Supports the hydra protocol.  Performance - as noted above. Client v Server is different. Have run benchmarks to show how this compares to other things.  DA what problem or audience does this address?  Omar was finding it hard to get around FIBO and found this a useful way for a data person to get around.  So is the audience us?  JG given we want to say there are many user interfaces, this should be one of them.  Navigate through FIBO without using Protege.  JG this would be more useful if we added text data.  Similar to Kevin Tyson idea of setting up a FIBOPedia.  We have registered http://data.edmcouncil.org for all ABox data.  This would have the test data sets.  We should have test data for every class in every ontology in any case. Even in the upper level and conceptual ontologies we should have examples of individuals.  Then people can browse FIBO with real data objects.  This is something that a technical person can go straight to without them having to have or know about Protege and the rest. 


DW:  What to do? JG can set this up and get it running on http://data.edmcouncil.org and evolve is by adding more test data TTL files to the FIBO repository.  Eventually.  Is there a pointer from http://spec.edmcouncil.org to http://data.edmcounci.org?  Yes, or have http://fragments.edmcouncil.org and point to that, and have these there.  Can OK take this on? Yes?


ACTION:  JG to establish the new VM named https://linked-data.edmcouncil.org/fibo///  Omar to use this to set up Ghent link to FIBO.


Others are using fragments dot whatever as the convention. Others are also using data dot whatever. So either is fine.  JG would not put this on spec dot since everything there needs to come from the Repository and every item should have a version.  The fragments dot whatever stuff does not heed to have the same versioning etc, which is why it needs to be in a different place.  JG can do the VM this week and give the access details to Omar.  So we can see this next Tuesday. 


DA and JG are working on the ALL-file (single version with everything). Has a stable URL /master and also /latest so Omar can use either. JG and DA will generate every RDF file in each of the supported formats, so if this needs TTL that will be available. 


PR what happened to the versioning stuff Omar was doing in StarDog?  OK: as part of the Publish process, had it so that if someone entered a JIRA item into the Git commit, it would put that through and there is part of the script that would check that in to StarDog. However the Publish process has changed since this was done, so that is probably disabled.  Was this working in Wells Fargo but needed to be installed on the EDM Council server? Were all the tech problems resolved back then?  OK: It was working as part of the Publish process. Some restructuring needed. Could get back on to it. DA keen to see this. 


JG the FIBO Publish job still runs on the StarDog slave (because speed of loading).  DA would like to pick this back up.


Important.  Action: This is a separate task, from last October.  Either we pick it up again or decide not to do it. We only dropped it because of Omar's time commitments at Wells.  OK: There are  -  lines of code in GitHub that make it call StarDog. The code could probably be improved but the main requirement is to make this flow with the rest of the Publish process.  JG this would be easy if the latest Master and Pink were always dropped into StarDog.  Could run this off what is dumped in the fragments server. So we could point the fragment server also to the StarDog end point.  Not sure how the Memento protocol would work on that.  Clarify the proposal:  When the FIBO Pub job runs on Master branch, we can publish the ontologies in the StarDog end point and that same StarDog end point is then use by the Fragments server to publish it.  So this (the StarDog server) becomes the on line system of record for anyone who wants to publish it.  DA likes this. OK agrees it can be done.  OK:  data would work as fragments. here is a list.  http://data.linkeddatafragments.org/  http://fragments.dbpedia.org/ 


ACTION:  OK gets the Fragments server up by Tuesday.  OK will then iterate getting this running with the StarDog server after that.


Aob?  Thursday's meeting will be hosted by Dean, as long as Tony is available 


Also look at RDF-KIT on Thursday.

Decisions:

Action items