...
Jira server DuraSpace JIRA key VIVO-101 - Implementing a web service interface (with authentication) to the VIVO RDF API, to allow the Harvester and other tools to add/remove data from VIVO and trigger appropriate search indexing and recomputing of inferences.
- This would also enable round-trip editing of VIVO content from Drupal or another tool external to VIVO via the SPARQL update capability of the RDF api
- Authentication will be involved
- Could manage in our own authentication and authorization system and tell Apache that the servlet requires an HTTPS connection
- This approach would allow testing in a known environment without having to set up SSL certificates
- It would help the user experience if it's possible to bundle together an atomic change set (at least all those changes for one graph), so additions and retractions would not show up piecemeal
- Note that since inferences are done is a separate thread there may still be some lag
Put and delete of data via LOD requests – this has been suggested but we're not sure a specification even exists for an LOD "put" request – please add references here if you're aware of discussion or documentation.- when we were design the RDF API, if we allow anybody to execute an arbitrary SPARQL update or delete, you can't just listen to the changes, so we limited what we supported through the RDF API to adds or deletes, using just a subset of the overall language
- the idea of being able to pipe an arbitrary update or delete through our API would take some work but is theoretically possible
- Stephen is willing to test for the Harvester
| Anchor | ||||
|---|---|---|---|---|
|
...
Other candidate issues relating to content editing
NIHVIVO-1126support support for editing rdf:type of individuals via primary editing interface, not just the admin editing interface, as requested by Brown to allow one type of Document to be changed to another when the original automated type assignment was inappropriate.- Question – is this a functionality for any self-editor or just for privileged editors (e.g., library curators)?
- The question has come up here about whether to remove statements that are no longer appropriate based on the domain of the property with respect to the new rdf:type.
- We think not – the VIVO rendering interface will continue to show the statements, and existing statements will be editable
- If the user removes a statement, the option to add a new statement may not be offered. This is appropriate.
- If the user changes his or her mind and changes back the rdf:type of the individual, the original statements would still be there
- NIHVIVO-1125 class-specific forms for entering new individuals
- These can be implemented as needed without new code functionality, although the custom forms would require adding the appropriate editing configurations to the code
- The first parts of the application configuration ontology, such as treating the same property differently based on the type of the related entity
- what label, but also more
- what property group
- what editing form
| Anchor | ||||
|---|---|---|---|---|
|
...