The API Extension Architecture (API-X) provides a framework for extending the native functionality of a Fedora 4 repository. Fedora 4 is a robust, modular, open source repository system for the management and dissemination of digital content and is especially suited for both access and preservation. Originally released in November 2014, version 4 of Fedora is completely new software that addresses the top priorities expressed by the international community. These were:
improved performance, enhanced vertical and horizontal scalability
more flexible storage options
features to accommodate research data management
better capabilities for participating in the world of linked open data
an improved platform for developers—one that is easier to work with and which will attract a larger core of developers.
To a large extent these requirements have been addressed through the new Fedora 4 content model and its adherence to the W3C’s Linked Data Platform recommendation. The content model is very simple with only two types of objects, containers and binaries; while the interface (API) allows direct access to every object in the repository and facilitates bundling multiple operations into larger transactions.
The API-X project seeks to extend the utility of Fedora’s core feature set by facilitating the mapping of the many and varied domain models currently in use by research communities onto Fedora’s semantic-web-based data model and interface. Concepts such as data set, species, phenotype, collections, metadata, data items, browse imagery, etc. are not native to Fedora 4 and must be mapped to Fedora 4 objects so that communities familiar with those concepts find the web services that are familiar to them. Mechanisms to extend Fedora so that it can support existing commonly-used web service standards, such as the Open Geospatial Consortium Services (OGC W*S) common in the geospatial community, the Simple Cone Search used in the astronomy community, or the Global Names recognition and discovery services used in biology are required.
In addition, many domains have developed federated discovery and access portals based on domain specific metadata. Examples are the two stage discovery mechanisms based off temporal, geospatial, and domain specific parameter queries in the Earth sciences, the ability to query for chemical structures in biomedicine, and to resolve species names across repositories in biology. If research data held within Fedora repositories are to be globally discoverable, accessible and usable by the research community used to such one-stop capabilities, Fedora 4-based repositories will need to be able to support the mechanisms important to their communities.
Lastly, and perhaps most importantly, beyond supporting existing domain models and services, Fedora 4 needs mechanisms that allow it to support advanced data curation capabilities (e.g., format migrations, support for lineage as well as provenance, etc.) and the needs of new interdisciplinary and cross-disciplinary audiences for data by facilitating access to alternate representations of the data (e.g., thumbnails for browsing, statistical summaries or analysis results on-the-fly) as they develop.
What is needed is a framework that allows all of these more comprehensive and possibly domain specific services and models to be added to a repository in a standard, reusable, plug-and-play way. Facilitating this is the purpose of the API-X framework.
How to get involved
Take a look at a hands-on demo of the first milestone API-X release, and provide valuable feedback
All Fedora adopters are welcome and encouraged to participate in this community effort. The group holds meetings via conference call on a biweekly basis, currently every second Thursday at 1pm Eastern (US) Time. Notes from past meetings and agendas for upcoming meetings are available via the links to the right.
Participation can take many forms, from attending meetings, contributing use-cases, and drafting documentation, to acting as a stakeholder or contributing code for development efforts. Just call in to a meeting or get in touch with some of the participants listed below to find out how you can help!
People and Roles
For more information on different ways to participate in API-X planning and development, see the "People and Roles" page. Current participants in the API-X group includes the following:
- Aaron Birkland
- Unknown User (acoburn)
- Stefano Cossu
- Daniel Davis
- Ruth Duerr
- Elliot Metsger
- Diego Pino Navarro
- Nick Ruest
- Bethany Seeger
- Joshua Westgard
- Jared Whiklo
- Recent Papers, presentations, and media
Found 10 search result(s) for API Extensions Meeting.
... do we have other items that are also goals, but not requirements? Is it appropriate for an APIX extension to use native java APIs such as fcrepokernelapi https://wiki.duraspace.org/display/FF/HighlevelRequirements?focusedCommentId=71991895#comment71991895, or should they use standardized and codified fedora HTTP APIs? Discuss list of potential Proof of Concept ideas. Do ...
Dec 21, 2015
... operations serialized APIX framework would largely be agnostic about what's going on in an extension, so we're taking about what occurs within an extension when it's handling a user request. Aaron to find out more about ...
Oct 09, 2015
... Separation of concerns: What does APIX need to know what does validation extension need to know? How would extension implementations interact with Fedora? HTTPLDP? A client library? fcrepokernel seems too closely ...
Sep 19, 2015
... target date and deliverables Finish #10 https://github.com/fcrepo4labs/fcrepoapix/issues/10, #11 https://github.com/fcrepo4labs/fcrepoapix/issues/11 (exposing, intercepting) Extensions to show? Integrate with one or more Amherst repository extension services https://gitlab.amherst.edu/acdc/repositoryextensionservices (e.g. jsonld compaction, xml serialization, image manip, etc ...
Sep 15, 2016
... roles page Stakeholder responsibilities Point of clarity, APIX has two aspects extension framework extensions Also, stakeholders are not implicated in software development Stakeholder responsibilities are a collective responsibility all ...
Nov 13, 2015
... proposal https://docs.google.com/document/d/1UHQMXgnGoIXfe33a6CM6k3IkL3SsYqzkkWBRMaJxMew/edit?pli=1#bookmark=id.4d5klahtu2ap (see: Composability of API Extensions) The need to compose, pipeline, or chain extensions seems implicit in the design Amherst use case implementations explicitly make use ... else to do with these particular use cases at the moment? Updating Use Cases Summary ...
Sep 25, 2015
... great. Seamless, functionalities are extremely impressive. Is interested in the next steps, the short list of extensions in immediate and near future with crystal clear extensions to be pushed to the community so that we can convey to community the concrete values that APIX
Jan 19, 2017
... cases outline) https://wiki.duraspace.org/display/FF/DesignAPIExtensionArchitecture Use Cases Parent Page https://wiki.duraspace.org/display/FF/UseCasesAPIExtensionArchitecture 20151113 Fedora API Extensions Meeting Minutes Agenda Item 1: Review of proposed High Level Requirements High ... do we have other items that are also goals, but not requirements? Is it appropriate for an APIX ...
Dec 11, 2015
... have a release (to mavencentral, etc) in fcrepolabs on the core components of the architecture and one/two extensions that fulfill the high level requirements set forth by stakeholders. The extensions would be hand picked to be widely valuable within the community Task and Progress tracking
Apr 29, 2016
... bseeger have started creating extension impls https://gitlab.amherst.edu/acdc/repositoryextensionservicesaligned with the current design draft These extension impls expose extension definition documents in OPTIONS body on service URI. Should this be a pattern generally supported ...
Jul 07, 2016
- No labels