Versions Compared

Old Version 3

changes.mady.by.user Dragan Ivanovic

Saved on

compared with

New Version 4

changes.mady.by.user Brian Lowe

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Paste notes

...

  1. Brian Lowe (star)
  2. Dragan Ivanovic  
  3. Georgy Litvinov 
  4. William Welling 
  5. Naveen Sadhu
  6. Veljko Maksimovic 
  7. Huda Khan  (star)
  8. Ralph O'Flinn 
  9. Benjamin Gross 
  10. Michel Héon 
  11. Florian Kotschka

...

  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. Georgy’s dynamic API proposal:
      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.
      2. 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: Started 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 (please correct if need be:)) 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. Georgy: pull request for attaching files to documents to prove info correctly put into VIVO 
          17. 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

Draft notes on Google Drive

...