...
| Anchor | ||||
|---|---|---|---|---|
|
Adding Adding better support for named graphs in the UI (the application already handles named graphs internally and through the Ingest Tools menu).
In many cases one goal of using a named graph is to assure that the content in the graph is not editable, so we need to be careful here. For 1.6, the enhancements under consideration include
- Allowing Allowing the addition of statements about any named graph such as its source and date of last update
- Making Making this information visible in the UI (e.g., on mousing over any statement) to inform users of the source and date of any statement, at least for data imported from systems of record
...
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 (phasing out Flash) – not likely to be addressed in 1.6- Adapting the visualization to work for shared research areas (Colorado interest) and/or shared presentations (Brown interest)
| Anchor | ||||
|---|---|---|---|---|
|
- Limiting Limiting SPARQL queries by named graph, either via inclusion or exclusion.
- This is allegedly supported by the Virtuoso triple store. This would help assure that private or semi-private data in a VIVO could be exposed in via a SPARQL endpoint
- If this functionality is dependent on the underlying triple store chosen for VIVO, it's not something that can easily be managed in VIVO
- There are other possible routes for extracting data from VIVO including linked data requests – if private data is included in a VIVO, all query and export paths would also have to be locked down. Linked data requests respect the visibility level settings set on properties to govern public display, but separate more restrictive controls may be required for linked data.
- Being able to get the linked data for a page as N3, Turtle, or JSON LD, not just RDF/XML
- Enhancing the internal VIVO SPARQL interface to support add and delete functions, not just select and construct queries – see "Web Service for the RDF API" above
...