vivo-community / scholars-discovery Goto Github PK

Currently, only version 7.7.1 is supported. We will need to update the managed schema and Solr config to support later versions. The Docker file and configurations in the solr directory should be updated.

Allocated time to research the following.

API to deliver self contained view; HTML, CSS, and JavaScript; of a section view.

Thoughts and speculations. Not necessarily desired design.

1. Add Java API handlebar compiler dependency.

2. Add "wrapper" template to package existing template along with scripts, styles, and enclosing tags. It's important to be re-using the existing, persisted templates.

3. Wrapper JavaScript should be responsible for requesting data and pagination. Pagination should be entirely client-side.

4. Requires API endpoint to deliver single element with inline JavaScript to make additional request for rendered template. Element requires data attributes for individual id, display view, and section.

5. Services to render section for given id and display view.

6. Requires additional API to deliver rendered HTML to replace embedded tag.

Based on TAMU code and product evolution, add addresses to the graphql endpoint. This includes adding to the graphql and populate/stub a reasonable number of fields.

Will require a Boost argument model and resolver. Update relevant methods which boost using static hard coded values.

The Persons property is etdChairOf. Either can parse the label using regex to pull the year or add another property to the nested object for the publication year of the associated document.

Remove bullet points. Use bootstrap 4 list-unstyled class.

Based on TAMU code and product evolution, add email to the graphql endpoint. This includes adding to the graphql and populate/stub a reasonable number of fields.

Add the java dependencies to the project for the graphql endpoint. Get a basic graphiql endpoint going with no data.

Export search result as Word Document in format displayed. By default only Publications Search View have this option.

Will need to use docx4j to generate dox from html.

The CollectionView model will have to be updated to afford a map of export configurations. Currently, CollectionView has only a list of Export Fields. The model changes will have to afford these and the ability to export docx using CollectionView result templates. Refactor if necessary.

The Export Argument Resolver will have to be updated as well.

Should use existing exporter interface and controller endpoint. Use existing Directory/Discovery view result templates. Render using handlebars and generate docx file from resulting html using docx4j import xhtml.

docx4j dependency

<dependency>
    <groupId>org.docx4j</groupId>
    <artifactId>docx4j-ImportXHTML</artifactId>
    <version>8.0.0</version>
</dependency>

Will require request parameters to specify page, size, and sort.

Entity which extends View. Should have a list of embeddable about section which has template, header, and id. Template will hold the html for administration. The id will be used for scrolling to using link fragments.

Request parameter for number of most recent to return.

Based on TAMU code and product evolution, add organizations to the graphql endpoint. This includes adding to the graphql and populate/stub a reasonable number of fields.

Blocked by addition to Collection View to configure boost fields. Will most likely require an additional request parameter. Will have to negotiate boost along side of sorting. May be that when a boost is specified it may have to be the first order sort.

Since the graphql schema might be in flux, this ticket is to figure out how to test it when we have something more solid in place.

Should be converted to sub sections. The template should include link to person whom graduated from the organization with persons name as link text.

grants: awardedBy
award: awardConferredBy

• badges
• title, description, about, diagram
• technologies
• dependencies
• deployment instructions, separate md file with link
• contributing instructions, separate md file with link

A crude PoC can be found here, https://github.com/TAMULib/Scholars/blob/sprint3-experiment/middleware/src/main/java/edu/tamu/scholars/middleware/MiddlewareApplication.java

Blocked by customization of Vitro to publish triple-store changes of RDF Delta Patch Server to message topic. Consume message topic and re-index accordingly. Re-index will query collection by syncIds for relationships and determine if Solr document is new or to be removed via type predicates of the RDF patch.

Based on TAMU code and product evolution, add positions to the graphql endpoint. This includes adding to the graphql and populate/stub a reasonable number of fields.

Currently, query parameters for facets and filters require a list of the fields in which to facet or filter and then parameters namespace to those fields for faceting selections and filtering values. This does not account for pathing to nested properties, it is that of the flatten properties of the Solr documents.

The design should accommodate faceting and filtering on nested property paths, take into consideration mapping to GraphQL requests, and use argument resolvers.

relates to #53

reference, http://scholars.library.tamu.edu/vivo/display/n92930c0b

https://github.com/leangen/graphql-spqr-spring-boot-starter#custom-type-mapper-for-graphql-output-and-input-types

https://github.com/leangen/graphql-spqr-spring-boot-starter#customizing-input-and-output-converters

Based on TAMU code and product evolution, add educations to the graphql endpoint. This includes adding to the graphql and populate/stub a reasonable number of fields.

https://github.com/vivo-project/sample-data/tree/master/openvivo

@nymbyl has a report with this started, but maybe there are improvements to it.

https://github.com/OIT-ADS-Web/scholars-discovery-setup

https://demos.library.tamu.edu/scholars-ui/display/relationships/n778956c8/Grants/View%20All

Add search export to discovery APIs. Endpoint requires parameters for search query, index from directory view, filter fields, sorting, and export fields. Most of request parameters are same as the search facet and count methods. The sorting field is encapsulated in the pageable parameter of the facet search. This may require some innovation in providing request paramter for sort. The export fields can be convention defined request parameter. Should be a repeatable request parameter providing column header, value path, and optional delimiter per export field. A convention is in place for filter fields and may be referenced for export fields.

A link to the search export should be added to the HAL responses via the resource processor.

The abstract solr document repo will require a new custom method for streaming the Solr response.

The export endpoint should stream the desired export file directly from Solr response. The first use case is of a csv. Optionally, could put in place ability to implement an export service interface that is injected via argument resolvers based on a query parameter. The mapping of the discovery model to csv column can be done using reflection. The value path should be the same as the serialized response from the API. It can be derived from the NestedObject and Reference annotations. Utilities should be created to extract value given a value path.

The default query parameters for the front end link for any given collection will be generated by the addition to a Collection View.

• Embeddable ExportField
  • column header
  • value path
  • delimiter, provide default
• EmbeddedCollection of ExportFields on CollectionView

The value path will need a validator. It should check the given discovery model and annotations to ensure it will resolve a value if the value is index.

Endpoints to support reindex all, by collection, and by collection and document id. Include links in applicable HAL responses.

This flag will provide the ability to express whether the section view can be shared from the UI.

Implement a basic person lookup in the graphql endpoint with minimum data. This includes adding it to the schema definition file.

This is blocked by the API to download person one pager word document.

Blocked by #68

Will need to use docx4j to generate docx from html.

Here is the desired template:

one pager template.docx

Only display 5 most recent publications.

An additional handlebars template should be added to the DisplayView entity. This template will need to be rendered using Java handlebars engine and generate docx from result html using docx4j import xhtml.

Similar to #67

The API should be {collection}/{id}/export with optional type query parameter defaulting to docx.

A HATEOS link should be added to the resource JSON response.

relates to #54

During harvest of a collection, an isolated log should be created of failed SparQL requests, multiple most-specific types, missing required properties, duplicate literals with slight variation, and inconsistent language attribute use.
The log itself should probably be machine readable and contain as much relevant information as possible. The log may be emailed and or used in reattempts or other scheduled processes.

Size as assuming we won't be changing the existing SPARQL. Furthermore, this will occur only in the context of a full harvest and will re-create the log each time. Just put in hooks for logging whenever the various discrepancies are detected in the course of harvest.
Amending an existing log in place would be a future feature.