Date

Call-in Information

Time: 10:00 am, Eastern Time (New York, GMT-04:00)

To join the online meeting:

  • https://lyrasis.zoom.us/j/84378615572?pwd=bGUxSjlyRTdjOGl5U1B6L0Yva3RQdz09

    Meeting ID: 843 7861 5572
    Passcode: 556561
    One tap mobile
    +16699006833,,84378615572#,,,,*556561# US (San Jose)
    +19292056099,,84378615572#,,,,*556561# US (New York)

    Dial by your location
            +1 669 900 6833 US (San Jose)
            +1 929 205 6099 US (New York)
            +1 253 215 8782 US (Tacoma)
            +1 301 715 8592 US (Washington DC)
            +1 312 626 6799 US (Chicago)
            +1 346 248 7799 US (Houston)
            877 853 5257 US Toll-free
            888 475 4499 US Toll-free
    Meeting ID: 843 7861 5572
    Passcode: 556561
    Find your local number: https://lyrasis.zoom.us/u/kerqtGDrJ4

Slack

Attendees

(star)  Indicating note-taker

  1. Brian Lowe (star)
  2. Dragan Ivanovic  
  3. Georgy Litvinov 
  4. William Welling 
  5. Veljko Maksimovic 
  6. Huda Khan 
  7. Benjamin Gross 
  8. Michel Héon 
  9. Florian Kotschka
  10. Benjamin Kampe 
  11. Fadwa Alshawaf
  12. Christian Hauschke 
  13. Andreas Czerniak

Agenda

  1. Announcement
    1. Integration of VIVO and DSpace project
  2. Questions/Issues/Pull Requests
    1. Pablo E Diaz Ramirez issue
      1. https://groups.google.com/g/vivo-tech/c/ZIyA_ZTunHM
  3. Reorganization of Wiki pages - https://docs.google.com/document/d/1JmdIHYcaYCDCYSQyevKjAVdgH4aZ8JXr3Ls9eIjlrS8/edit?usp=sharing
  4. Discussion about sprints' topics
    1. https://docs.google.com/document/d/1hJSWAa3ENoFOYyp0GyvDqBdehra3AmFBAD9X2dX3cSo/edit?usp=sharing
    2. Georgy's proposed ontology for dynamic api https://docs.google.com/document/d/1vtNIVEYWdBgV11N-wiPk_UNKpiFQ4sKetJ8elJ6xy2E/edit#

  1. Discussion about priorities for further development of VIVO - https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing
    1. The topic will be i18n
      1. Move i18n properties from resource bundles to ontology / (editable) RDF
      2. Find solution for syntax differences between languages that does not require template customization per language 
    2. Data ingest

Notes

 

  1. DSpace / VIVO integration project:
    1. Details forthcoming.
    2. Committers should work with those outside the committer group to build capacity.
    3. DSpace has 2000+ installations; opportunity to grow community by adding semantic web aspect to existing repositories
  2. Pablo E Diaz Ramirez issue:
    1. Some initial hurdles with deploying VIVO + Virtuoso with Docker were addressed by email.  Still apparently an issue with sample data not loading or not persisting in Virtuoso.
    2. Need to solicit more log details from Pablo in order to diagnose further.
  3. Reorganization of wiki pages
    1. Dragan has proposed a reorganization here: https://docs.google.com/document/d/1JmdIHYcaYCDCYSQyevKjAVdgH4aZ8JXr3Ls9eIjlrS8/edit?usp=sharing
    2. We have comment rights if we have other ideas about how to organize things.  Should also comment with links to documentation that we find to be a good example to emulate.
  4. Sprint organization:
    1. Release schedule: April and October look like the most likely months.
    2. One topic might be VIVO Dynamic API proposed by Georgy:
      1. Motivation:
        1. Need a rest API to facilitate front-end/back-end decoupling
        2. It’s relatively difficult to add a new custom form / add new editing functionality.  Requires creating N3 editing generator Java class.  Complex and difficult to understand, and requires debugging and recompiling when something goes wrong.
    3. Ontology to describe steps in editing workflow
      1. Link together queries, parameters, and N3 templates.
      2. Extend API dynamically by adding additional RDF descriptions using this ontology.
      3. Michel: sounds very similar to something I have done in VIVO-Proxy.  Would be good to work more closely together and propose something standard for the VIVO community.
      4. Georgy:  First step is to define the ontology -- the language for describing the functionality.  That should be discussed thoroughly, and then a plan for implementation can be developed.
      5. Christian: Does this mean that we can not only define data with triples but also define forms?  And transfer forms from one VIVO to another just by sharing triples?
        1. Georgy:  In general, yes.
      6. Dragan: Should have a general static API for things that don’t require custom forms.  The dynamic API would then be used in cases that require it.
        1. Georgy:  Should be discussed what things should be static.  Not only entry forms, but Solr and other functions may lead to special cases and processing rules that might be better described using this type of dynamic language.
        2. Dragan:  If everything is dynamic, then VIVO becomes Vitro + RDF configuration files.  Could be more easily adapted to another domain.  Danger is that when something is completely generic, it may be harder for people to understand than if there is purpose-specific Java code.
        3. Georgy:  It’s not so easy now, since you have to work with Generator classes and Freemarker templates; not a straightforward linear flow that is easy to read for a newcomer.
        4. Christian: could help people get up and running by distributing a set of standard forms described using this ontology that could be adapted.  Could be more uptake of VIVO if we use this more generic Vitro approach and make it easier to adapt to different environments.
        5. Georgy: We don’t currently have a lot of resources for development of core Java code.  This is a way for people to develop forms/APIs without writing code.
        6. Dragan: Instead of writing simple Java code for a simple static API, now you’ll have to write something in an ontology.
        7. Georgy: We already have the ability to create/edit these ontology entities in Vitro, so we can start building these descriptions.  Debugging should be much easier.
        8. Christian: We always have a lot of changes in the custom editing forms with all of the partners we work with.  This is a lot of work, and delays VIVO projects a lot.  Lots of iteration and testing required.  There is always something that has to get added to a form, and each addition requires development time.  With the ontology definition, effort can be split between developers and librarians.
        9. Brian: Internal generators and components interact in a complex way.  Taking that existing engine and being able to make it easier for people, like librarians, to add or change the N3 would be helpful.  
        10. Christian: Do you have any idea how much development effort would be required for this kind of work?
        11. Georgy: Still need to decouple freemarker from the other portions would still require work.  Making an endpoint isn’t necessarily hard but then replacing all the underlying code would take work.  Perhaps a year with sufficient development resources committed to this.  
        12. Dragan: We should start thinking about ontology for this task. 
        13. Georgy: Described basic parts of the ontology in the Google doc 
          1. List of entities required 
        14. Huda recommends looking at N3 editing form extensions that were developed for the LD4L project
          1. N3 strings could be defined in a JSON document.
          2. Developed another Java class that could map the JSON configuration to the internal generator-style code.
          3. Not precisely what is being discussed here, but it might be informative to look at that JSON-to-Java mapping.
        15. Dragan: What might be the first step in moving this work forward?  Topic for sprint? Might be difficult to organize this work in a sprint.  Need to decouple the tasks?
          1. How to define the ontology?  How to assess if sufficient for our use cases? Need other data or other cases?
          2. Georgy: Iteratively implement and then see if use cases are satisfied
          3. Dragan: What if changes need to be made?
          4. Georgy: Enable extensions as required.  Would have more portions of the constructor
        16. Michel from chat
          1. I think that if we have to define a sprint on this project, it would be possible to create a sprint with the goal of designing a proof of concept to
          2. 1- consolidate the architecture
          3. 2- identify the central ontological elements
          4. 3- obtain a sketch of the technological framework
  5. Georgy: pull request for attaching files to documents to prove info correctly put into VIVO 

Draft notes on Google Drive

Task List



  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.