Page History

...

Anchor
Editing Editing

Editing

•  Being able to configure the relationships that determine what is editable through self-editing, such as that an author of a paper can edit it while nobody else can. The caution is that this has a complexity similar to a generic deletion problem – how far does the authority bridge?
  
  • See comments on VIVOIMPL-15 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 editingto content editing

•  NIHVIVO-1126support 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)?
  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 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

Anchor
Ingest Ingest

Ingest Tools

• Integrating Mummi Thorisson's Ruby-based CrossRef lookup tool for searching and loading publications into VIVO, on GitHub along with OAuth work for retrieving information from a VIVO profile in another application
• Improving and documenting the Harvester and documenting the Harvester scoring and matching functions
  •  Stephen is already working on updating the Harvester documents in general – not sure how much into the scoring and matching
  functions
  • he will get

Anchor
Internationalization Internationalization

Internationalization

Also  Also referred to and documented as Multiple Language Support in VIVO

...

Anchor
Provenance Provenance

Provenance

Adding  Adding better support for named graphs in the UI (the application already handles named graphs internally and through the Ingest Tools menu).

...

Anchor
Visualization Visualization

Visualization

• improved  improved caching of visualization data – a student project at Indiana University has investigated and traced the issue as a problem in allowing multiple concurrent threads trying to create the cache of data for the same type of visualization. 
  
  • This has been reported instead as a problem with scalability (e.g., for a Map of Science from the 32,000 plus publications in the University of Florida VIVO, or at UPenn)
  • This may solve the problem and will at least make it easier to determine whether further work on caching is necessary – if so, a solution for caching intermediate data vs. the final resulting page or image is likely to make sense
  • Jim will finish processing the pull request from Indiana that fixes a concurrency bug that might start more than one instance of a long process
•  HTML5 HTML5 (phasing out Flash) – not likely to be addressed in 1.6
  
  
•  Adapting the visualization to work for shared research areas (Colorado) and/or shared presentations (Brown interest)

Anchor
QueryExportReporting QueryExportReporting

Data Query, Export and Reporting

...