You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Creating an API for accessing MaRDI-Portal components and data.
Defining the public and internal interfaces.
Practically, there are some components of Wikibase which already have GUI interfaces (like quickstatements and openrefine), writing API endpoints for them is probably not necessary, however we could forward some of their capabilities to our API endpoints if they will be extensively used. For other libraries and implemented components we could have an access point API, example an API before (Wikidata Integrator, Wikibase Integrator etc. ) which offers the public capabilities used in our scenario.
This is a very early WIP-draft.
Tentative Tasks:
Check if Python or PHP is suitable (KG API is PHP)
Collection of use-cases and possible endpoints
Forward the KG API, check how this can be done with open-api specification
Preliminary feature ideas:
Authentication
Some security layer, especially for the public endpoints
ORM Mapping to Data in MediaWiki / Wikibase
Swagger features: API Documentation has only be noted on one point, automated client generation.
Jupyter Notebooks integration somehow
Forwarding SPARQL Request for KG Queries
Messaging System, queues for more time-consuming jobs
Microservice architecture
Common techniques for creating 'federated' API's
Ingest integration
Import an Entity from Wikidata by API call to Portal KG
This will be done at a later stage, currently we can use Wikibase/Mediawiki API's directly at some point if we have more API features, we add the currently specified requests to this Portal-API. @eloiferrer
Epic description in words:
Creating an API for accessing MaRDI-Portal components and data.
Defining the public and internal interfaces.
Practically, there are some components of Wikibase which already have GUI interfaces (like quickstatements and openrefine), writing API endpoints for them is probably not necessary, however we could forward some of their capabilities to our API endpoints if they will be extensively used. For other libraries and implemented components we could have an access point API, example an API before (Wikidata Integrator, Wikibase Integrator etc. ) which offers the public capabilities used in our scenario.
This is a very early WIP-draft.
Tentative Tasks:
Preliminary feature ideas:
Additional Info:
Corresponding Milestones:
Epic issues:
Related bugs:
Epic acceptance criteria:
Checklist for this epic:
The text was updated successfully, but these errors were encountered: