vivo-community / scholars-discovery Goto Github PK
View Code? Open in Web Editor NEWLicense: BSD 3-Clause "New" or "Revised" License
License: BSD 3-Clause "New" or "Revised" License
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.
Add Java API handlebar compiler dependency.
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.
Wrapper JavaScript should be responsible for requesting data and pagination. Pagination should be entirely client-side.
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.
Services to render section for given id and display view.
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
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
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.
@nymbyl has a report with this started, but maybe there are improvements to it.
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.
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:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.