Don: abox/tbox: made a Google doc. Outlined the various structures that are in the RDF directory. Put in files that CU Boulder is overwriting – our use case. E.g. overriding PropertyConfig.n3 to change label to “CU Boulder authors”.
Third-tier build: has been a thorn in my side; difficult to see how changes propagate through the tiers
Maybe there’s another way to accomplish the same thing, perhaps with branches.
Would be nice to have an easy way for local institutions to change the labels.
Andrew: Does this suggest additional issues (beyond documenting Maven 3-tier build)? Not sure how you want to scope this so we have scoping and can trace back to what was done at the end of the sprint.
Don: With documenting Maven 3-tier build, can document what we’re doing.
Should I make a ticket about our problems with 30-tier build?
Andrew: For sprint, would be good to have tickets that you can close in a day or two, and then open subsequent tickets.
Don: Not sure if my issue is necessarily a ticket. More of a discussion.
Andrew: Are we positioned to focus on something and get it done?
Don: 3-tier build thing might be totally out of scope, but don’t want to forget it.
Documentation of why we’re doing what we’re doing with abox-tbox should help with VIVO documentation.
1. This is how we do it and here are the side effects
2. Then evaluate parts that seem excessively complex
Also document what kicks off inferencing
Andrew: good to create a ticket or two that describe these things
Don: will do right now.
Mailing list threads
Yinlin’s question about whether there should be support for rendering handle identifiers as links in the VIVO UI
Andrew: Would handle make sense to treat like ORCIDs and DOIs?
Don: I think we’re doing the same thing where if there is a DOI populated, we display it as a link. Is that what we’re talking about?
Andrew: I think so, but can’t speak to it in detail. Does the DOI functionality you describe provide anything else besides displaying a link on a profile page?
general sense that there’s a need to render things like DOIs as links and not just strings
Don shared example
Yinlin: Most of our faculty have DOIs or handle links. Want to have links to handles on VIVO. Right now need to customize, but want this integrated into core code so that we don’t have to apply our customizations with each upgrade.
Andrew: Is Don’s example (buttons with DOI-constructed links) like what you’re looking for?
Yinlin: Can show screenshot. Our site is private.
Don: Graham raises good questions in his email.
Andrew: Is the handle an identifier or a link to a document?
Ralph: Graham’s response might be viewed as squashing the idea of handles.
Brian: question of whether a handle is really just a link (e.g. a URL from a vCard) or whether it can be used as an identifier
Andrew: How is it different from a DOI, which is a part of the ontology?
Brian action item: will raise issue with ontology group. Problem could also be one of the Bibo ontology, which conflates different versions of a work. Each might have its own handle, and it’s not obvious how to deal with that currently in VIVO.
Andrew: We need to hear from the community about whether there is a need/desire for similar functionality. So far we only have one email opinion.
Yinlin will ask other folks how they approach the same issue.
Andrew: don’t be discouraged by the one response you’ve received so far.
1.10.1 patch release
Andrew: Some bugs in 1.10 need to be addressed. Need to prioritize these issues and have conversation about a 1.10.1 patch release. Can bring to committers’ call. Don: Is there a way to see whether a bug is breaking or not? Andrew: Should make Critical the dividing line for bugs that need a patch release
Previous Actions
Alex Viggio will bring news of Elasticsearch instead of Solr up with Product Evolution. Might there be consequences for the September sprint.
Indicating note-taker
