-
Notifications
You must be signed in to change notification settings - Fork 0
DigiAPI
Welcome to the Digiapi wiki!
This page explains the reasoning behind the developing the Digi-API, by using the API canvas model
TODO: current idea of order of items to be managed in the canvas. Starts from the middle, goes to the left and then via the core of the API to the right
TODO: Need presentation material / slides via .io page etc.?
The API of relates to the strategy of the National Library of Finland (NLF), where openness is one of the corner stones. In addition the Open National Library policy (under work) and Digital Humanism policy include openness and interfaces for the key services as a main targets for the years ahead.
In addition for the modern user, API is needed in order for the user to find their own ways how to utilize the cultural heritage material. API enables connecting different services and maybe even creation of new kinds of services and products.
At first phase there are three distinct user groups for the API: researchers, media houses and developers each having need for the API, but with bit different goals in mind. Researchers would need the big data material and possibly with both retrieving and returning improved material back to NLF. Media houses could have interest for their own archives in order to enrich their own archives and public-facing services. Developers at large could do custom services based on the content and user needs.
The API for the digital collections (for the digi.kansalliskirjasto.fi) part would consist of providing API for the newspaper, journal and ephemera (technical ads, brochures). Possibly some other material later on.
We need to develop the API with relatively low resources, due to other ongoing projects during 2016-2019. API doesn't directly to fit any existing ones, so for resourcing we might need a new proposal going forward. The key resources are technical product owner and internal technical planning to define and plan the technical details of the API and lead the way in the implmentation, testing and finally support.
Internal stakeholders: DigiAPI would enable harvesting of digi content for indexing in the main portal of NLF. In addition, this relates to the incoming Open Data policy of NLF and its target plan.
External stakeholders:
- Developers to create their own ideas based on the content available.
- Researchers for obtaining data via API for their research.
- Possibly other collaborators, who would like to utilize the content via API as part of their own service offering to their clients.
Activities for the API design as a whole.
- Define use cases TODO: UseCaseList
- Design of initial version of API
- API Mockup development
- "Dry-Run" with potential users
- Update API Mockup with content
- Creating project proposal for actual implementation, via using the design and dry-run use as example
- Creating implementation backlog items based on earlier work
- Implementation
- Internal testing (possibly with some partners)
- Release for use.
- Support
- Monitoring the metrics and fine-tuning API.
API is for researchers, individual developers and other partners.
The API provides its data via REST/JSON. (XML TBD?). Provided that page content is given via API, the ALTO format is used for returning page content and coordinates of the each word in the page image. See Definitions for examples.
For ease of maintenance and support the API should be part of the existing framework. Probably requiring its own virtual server (TBD?) depending on usage levels and extent of the API.
Expected benefits are increase and novel ways of using the digital cultural heritage of the newspapers. In the long-term, it might enable new partnerships and new kind of ways to also improve the original material, e.g. by enabling to integrate any extensive correction schemes to the master content.
As in strategy and objectives, API woul be one (technical) step towards that plan. Secondly important would be to see how API is used for the developing new kind of apps or services.
In the follow-up metrics sense, it would be important to continuously follow the API usage. Also in point that does the API fulfill its purpose, does it require more promoting and whether performance is in suitable levels.
TBD: What is the expected effectiveness and value of your API Program?
When API is released a web page is created, where the API is explained (fields, calls) and some examples of common queries.
Increasing knowledge of the API via help of APISuomi, OpenGLAM, Digital Humanities Finland, Mikkeli APIOPS -networks. Promoting API in the events and hackathons organized.
TODO: Light-weight Comms.plan?
Developer archetypes -> TODO UserProfiles
Based on the Developer Segmentation 2014, at http://www.visionmobile.com/product/developer-segmentation-2014/ the most potential segments in DigiAPI case are:
Explorers
Independent developers to gain experience (e.g. in a hackathons, also can include the researcher use).
Product Extenders
Developers, who have existing systems, but who desire to combine data from multiple sources to enrich existing services further.
Digital Content Providers
Media houses etc, who would like to improve existing digital content with content from digiapi and provide it as part of their service for their clients.