...

• 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
• 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

Editing

• See comments on VIVOIMPL-15 improve  with respect to improving the permissions scheme for editing and make its functions more transparent to users. The best way forward here would be to transfer what's referred to as the editing policies, now hard-wired in code, to a set of RDF statements conforming to an editing policy ontology and editable from the Site Admin menu. This was the approach taken for the user model, and is proposed as an improved way of managing the display model (primarily for managing menu pages) and the application configuration ontology.
• Improve improve editing of data held in context nodes from the organization, event, or other related entity, principally via relationships like authorships or positions or via roles realized in processes or events – most custom forms support entry and editing only from the person. This requires no new functionality but will involve implementing additional custom forms

Other candidate issues relating to content editing

• NIHVIVO-1126 support for editing ref:type of individuals via primary editing interface, not just the admin editing interface
  
  • 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
  Put and delete of data via LOD requests
  • These can be implemented as needed without new code functionality, although the custom forms would require adding the appropriate editing configurations to the code
• NIHVIVO-715 pick lists could do a better job of remembering a user's previous choices

...