The Dynamic API ontology

[chenejac]

Is your feature request related to a problem? Please describe. The dynamic API ontology should simplify definition of custom action invoked from the custom entry forms. Therefore, this ontology should be part of solution which will enable easy customization of a VIVO instance.

Describe the solution you'd like Proposed list of entities:

• Action (to represent publicly available function)
• Role (to check required access)
• Step (represents iteration of request processing). Provides a way to introduce chaining (and also have conditionals) for Operations and retain reusability. There are two types of steps:
  • Operational Step
    • has operation
    • has next step
  • Conditional Step
    • has condition
    • has next step if true
    • has next step if false
• Operation
  • Template (N3 or optionally any other type of template to add to the triplestore)
    • N3Template
  • SPARQL Query (SPARQL query to get information from triplestore)
  • Solr Query (to get data from Solr core)
• Parameter (data required by Templates and Queries or created as a result of queries)
  • Parameter type
• Validator (to validate required and provided parameters)
• Model
• Resource
• RPC
• HTTPMethod
• CustomAction

Tasks

• [X] #3653
• [x] #3654
• [ ] #3655
• [ ] #3656

Additional context The draft version of the ontology available at https://github.com/vivo-project/Vitro/blob/sprint-dynapi-2022-feb/home/src/main/resources/rdf/tbox/filegraph/vitro-dynamic-api.owl

The draft version of the individuals available at https://github.com/vivo-project/Vitro/blob/sprint-dynapi-2022-feb/home/src/main/resources/rdf/abox/filegraph/dynamic-api-individuals.n3

[chenejac]

Are type and cardinality defined as properties of Parameter? If we define that some Parameter type is a person instance, should we enable definition of SPARQLQuery for getting a subset of all persons from database (e.g. just from some institution). This certain case may be better to define in Validator assigned to a Parameter (through the hasValidator property).

Should the Validator class include hasSHACLCoreRule and hasSHACLSPARQLRule properties? Not sure SHACL notation is the best for the on the fly validation of the data provided by VIVO users. If someone has an example of this, please provide in the comments below. Anyway, we need some notation for defining validation rules for provided data from the custom entry forms. Otherwise, we will need to create a lot of subclasses of Validator Java class for any validation, and it is not scalable for VIVO users who are not Java developers.

[chenejac]

We should consider adding heading and description data properties in the Action class. It might be useful in generic user interface for custom entry forms. Also, multilingual error message (if validation failed) might be useful. Probably the hasErrorMessage data property should be added to the Validator class. Can someone envision some use case when validation success message is also useful? If it is added in the ontology it should be also added in the https://github.com/vivo-project/VIVO/issues/3619.