Page tree
Skip to end of metadata
Go to start of metadata

Dates: April 23 - May 4

TEAM:

  1. Muhammad Javed (Cornell)
  2. Mike Conlon (VIVO) (through May 1)
  3. Jim Blake (Cornell)
  4. Benjamin Gross (Clarivate)
  5. Marijane White (OHSU)
  6. Tatiana Walther (TIB)
  7. Kitio Fofack (UQAM)
  8. Ralph O'Flinn (UAB)
  9. Don Elsborg ( CU Boulder )  (20 hours )
  10. Christian Hauschke (TIB)

Schedule of Meetings:

  1. Week 1
    1. Monday - April 23rd - Kickoff meeting
    2. Friday - April 27th - Status Update
  2. Week 2
    1. Tuesday - May 1st - Status Update
    2. Friday - May 4th - Evaluation 

Tasks

Re-evaluation of 1.10 branch. (Testing)  - IN REVIEW

Temporary notes on Docs: https://docs.google.com/document/d/1KeWlrAd6hNMsPZOag9OdtyquTur_2caWuMIgYyzKlmo/edit?usp=sharing

VIVO-1410 - Getting issue details... STATUS

    1. Code freeze

    2. Create a new release candidate

    3. We will be testing vivo-ontology-lab pull request. https://github.com/vivo-project/VIVO/pull/63

    4. Is it good to go in production?

    5. Preparing documentation for release (LEAD - Mike)
      1. Create release notes
      2. Create release upgrade instructions regarding Jena2/Jena3
      3. Does ingest documentation need to be revisited?
      4. See Preparing Documentation for Release
    6. Evaluation of Jena2 and Jena3 tools 
    7. Work through and document upgrade from 1.7
    8. Team: Mike Conlon (VIVO) Muhammad Javed (Cornell) Benjamin Gross LEAD (Clarivate) Ralph O'Flinn (UAB), Jim Blake (Cornell), Don Elsborg ( CU Boulder )

    9. DELIVERABLES:

      1. Pull request merge in dev (and merge to master??)

      2. Updated documentation following evaluation of current state of 1.10 documentation. Don Elsborg volunteered to assist as 1.7 persona. 

        1. Upgrade a CU Boulder 1.7 dev instance with local customizations to 1.9 — updating documentation as appropriate

        2. Upgrade CU Boulder 1.9 dev instance to 1.10 with local customizations 

        3. Verify single vivo.owl file and address local customizations for CU Boulder instance. 

VIVO ontology & Ontologies.owl file update     - DONE

VIVO-1463 - Getting issue details... STATUS

VIVO-1447 - Getting issue details... STATUS

    1. Replacing multiple vivo ontology files with a single one vivo.owl ontology task force group created.

      1. We will test if vivo.owl contains all entities (classes/properties) that exist in current VIVO software.

      2. We will test if ontologies.owl file is complete. All ontologies are mentioned in siteAdmin page. (ontologies.owl)

    2. Team: Muhammad Javed (Cornell), Mike Conlon (VIVO), Marijane White LEAD (OHSU)
    3. DELIVERABLES:
      1. A decision that changes are good to go in production or not ready (with comments)

VCARD ontology update (HomeWork)  - IN REVIEW

VIVO-1461 - Getting issue details... STATUS

  1. Homework: Evaluation, what has been changed, what should be removed, what should be updated, building the VCARD ontology module file (Add/Retract).

  2. Team: Tatiana Walther LEAD (TIB), Muhammad Javed (Cornell), Mike Conlon Co-LEAD (VIVO)

  3. DELIVERABLES:

    1. A file that contains list of VCARD entities that are used in vivo software but with a second column, specifying if the entity is current, changed or is deprecated (do not exist) in the current VCARD ontology. (current/deprecated/changed).

    2. A new model to substitute the changed or deprecated VCARD terms.

    3. A file that contains vcard graph that should be removed from vivo.owl

    4. A file that contains vcard graph that should be added in vivo.owl.

    5. Evaluate vivo_changed.owl

    6. "SPARQL Construct Query" to find existing triples and to replace with new. - most likely a part of the next sprint

  4. Comments:

    1. 04-27-2018: Created a file vcard.owl which I have extracted out of vivo.owl by means of robot. Then I've made the necessary changes: *1*. I've changed the URIs if necessary, *2*. I've modified datatype properties to object properties if it was required, *3*. I removed deprecated properties and classes. I have substituted the removed classes with rdfs:Resource in range assignments of affected properties. 4. I've added the owl:equivalentProperty axiome where it was required according to the spec. All of these changes are in the vcard_changed.owl. Both of the files as well as a vcard_diff.txt where all the differences are enumerated are in the Google Drive folder (https://drive.google.com/drive/folders/1Q6ZgmxyF0wDDgvNt0zm8OOgQfAud4ydM)  I have also tried to make a new vivo.owl with the help of merge / unmerge functions of robot, but not all of the deprecated things could be removed this way. So, I need to figure out, how to do this with robot. Of course, it would be no problem to do it manually. I'm not that experienced with robot yet.

    2. 04-30-2018: As discussed and agreed upon the affected domain and range assertions recently , I've removed those, where the class for the range and domain no longer exists in the spek instead of substituting it with rdf:Resource. There were not only the range and domain assertions affected, but the values of owl:allValuesFrom in the assertions of vcard:Kind. So, I had to remove the affected assertions as well. All of these changes you can see in the vcard_changed_2.owl (https://drive.google.com/drive/folders/1Q6ZgmxyF0wDDgvNt0zm8OOgQfAud4ydM). After that I've created the vivo_changed.owl (also in the Google Drive folder) which contains all the changes on vcard terms.  As it is obviously very necessary to test and evaluate, how the vivo_changed.owl affects the application, me and Javed considered it to be a new and only sub task which is to be finished by the end of the sprint 1. @marijane white it would be great if you could evaluate the vivo_changed.owl together with Javed. And everybody who wants to evaluate the updates on vcard is very welcome!

    3.  When reviewing Muhammad Javed  detected some domain assertions which are still in vivo_changed.owl but not in the recent version of Vcard spec. After a further chek other numerous assertions were removed or added. A renewed review needed. 

Preparation of ontology modules for the candidate ontologies/entities to be deleted. (Homework)  - IN REVIEW 

VIVO-1464 - Getting issue details... STATUS

  1. Homework: Preparing ontology module files for the candidate ontology entites to be deleted from vivo.owl

  2. Once re-organized ontology files are in place, next step is to clean ontologies/entities that do not sit well with VIVO. In this task, we will analyze.

  3. Which one of the ontologies are candidate to be removed.

  4. If removed, pull the graph out and make it available for those who would like to use It (in case).

  5. Team:Muhammad Javed LEAD (Cornell), Mike Conlon (VIVO), Tatiana Walther (TIB)
  6. DELIVERABLES:

    1. Graph file(s) of the candidate ontology modules to be removed.                                             

      1. Updated vivo.owl file.

        1. Updated vivo.owl file availabel in google drive https://drive.google.com/open?id=1SE8ZMzRk8wdaJUrEdF-CTcDo1TynlY8c .

      2. Updated ontologies.owl file

      3. Ontology modules (.owl files) that are removed from the updated vivo.owl file.

        1. Added four separate owl files in google drive https://drive.google.com/open?id=1SE8ZMzRk8wdaJUrEdF-CTcDo1TynlY8c  for Scientific_Research , OboInOwl, SWO and RO ontologies.

  7. Comments:

    1. 04-30-2018: Task is completed and read to review. Files are available at https://drive.google.com/open?id=1SE8ZMzRk8wdaJUrEdF-CTcDo1TynlY8c .

Multi-Language Support  - IN REVIEW

  VIVO-1451 - Getting issue details... STATUS

    1. Implement this feature on Capability map as a proof of concept of this issue. A user should be able to view the capability map in the language selected switching languages should change the language in which the map is displayed. The scope include making modifications at all levels of the application including templates, Javascripts, Java code, SPARQL queries and Ontology.
    2. Team:Kitio Fofack LEAD (UQAM), Christian Hauschke (TIB)

    3. DELIVERABLES:

                 a. A functional Capability Map completely internationalized and integrated to the main develop branch.






  • No labels