Indicating note-taker
Time: 11:00 am, Eastern Time (New York, GMT-05:00)
To join the online meeting:
Indicating note-taker
Mailing list messages
Status of In-Review tickets
|
Kitio Fofack ? Benjamin Gross ? Orcid and i18n
Only touches one file
Low-hanging - need one more reviewer
Received
|
Bugs (1.11)
|
Notes from the Architectural Fly-in
Still needs work
Not yet reviewed by the entire team
Need more details, from the whiteboards, etc.
Ralph is pulling together material from the notes, trying to get the correct terminology for the tools.
When completed and reviewed, these will be brought to the leadership group and the broader VIVO community.
Looking to get consensus, and perhaps even buy-in.
Ideally, create a calendar to accomplish the action items in sprints.
Mike: the leadership group has discussed having a sprint starting on March 18, 2019. If we have a plan in place, the leadership will be more able to commit resources.
2019 sprint schedule
March 18-29
June 17-28
September 16-27
December 2-13
Touch lightly on the contents of the (preliminary) summary of the Fly-in: https://wiki.duraspace.org/display/VIVO/2019-01+Architectural+Fly-in+Summary
topics included:
Ingest
Mike: what was the thinking about "editing in production"?
Ralph: not part of the first round of tasks. Focus on read-only GUI first, then move on to editing.
Jim: there was more focus on the read-only pages. There was some discussion of putting the editing functionality in a component outside of the VIVO frame (or core).
Andrew: again, the concept of "Shapes" or "entities"; i.e., a set of RDF that confirms to the shape of a Person.
In some installations, the only permitted edits are in the source systems, not in VIVO itself.
Also, if there is an ingest pipeline that includes "shape validation", then edits should come through that pipeline,.
Alex: Duke and others are looking at incremental updates, in additional to full ingests.
Don, steve: what are the "shapes"?
More than the data on the page -- Mike: the backend always contains more data than the page displays
Don: if the shape doesn't include all of the data on the page, then we need to do additional calls to create the page.
Mike: having the shapes forces us to think about the edges of the graph that represents an entity. "Your graph" overlaps with other people's graphs.
It's good to think about this!
Decoupling the UI
Do the "shapes" play into this as well?
Decoupling other pieces of VIVO (Triple-store, search engine, etc.)
As much as possible, independent components would be packages as Docker containers.
Allows (compels) independent development.
Facilitates cloud-based installation.
Are shapes customizable? (steve, Andrew) Andrew says this will be true. Steve: if we are going to tighten down the entities, apply schemas, then why not use a relational database? Why not just scrap the existing code base?
Ralph: the shapes and schemas are to help with ingest and to help with the UI, without breaking things that we have been supporting.
Mike: the LOD is primarily for the RIM application, If you are only interested in putting profiles on the screen, then any application can do it.
Mike: also consider, why is a company like MasterCard hiring ontologists? What do they see as the value of semantic tech?
Steve: don't you lose that flexibility/power if you start enforcing shapes? Mike: it's a balancing act. Jim: there might be other paths that reach around the shapes validation.
Steve: After 20 years, do we see any real results from RDF? If anything, the point of a triple-store is that it's schema-less. The developers must accept the burden of data validation.
"Blah-blah-blah" maturity of the technology. Hang out with the Europeans.
Alex: Justin was talking about SHACL etc as a lesson learned from the RIALTO project. this and other evidence suggests that this is not a wayward concept.
Don: shapes could be used to prohibit data, or perhaps just to flag data irregularities.
Status of in-review tickets
There are two tickets that are small changes and that need one more review.
