Core Features
-
Authorization — Fedora 4 authorization is designed to be fine grained, while at the same time manageable by administrators and end users. Authentication is managed by the servlet container or externally, but authorization mechanisms are open to extension and many reference implementations are included. Roles-based access control is an included feature that makes permissions more manageable and at the same time easier for external applications to retrieve, index and enforce. Finer grained security checks have no impact on the performance of requests that have a Fedora administrator role.
-
Versioning — Within Fedora 4, snapshots of the current state of a resource may be saved into the version history. The RDF for historic version shapshots may be browsed and old non-RDF content may be downloaded. Furthermore, an object or subgraph may be reverted to the state that it existed in a historic version.
-
-
-
RESTful HTTP API — The Fedora 4 HTTP API is generally a RESTful API. HTTP methods like GET, PUT, POST and DELETE are implemented on most resource paths. The API also relies heavily on content negotiation to deliver context-appropriate responses, and a HATEOAS-driven text/html response (providing a decent GUI experience on top of the repository).
-
Authorization — Fedora 4 authorization is designed to be fine grained, while at the same time manageable by administrators and end users. Authentication is managed by the servlet container or externally, but authorization mechanisms are open to extension and many reference implementations are included. Roles-based access control is an included feature that makes permissions more manageable and at the same time easier for external applications to retrieve, index and enforce. Finer grained security checks have no impact on the performance of requests that have a Fedora administrator role.
-
RESTful HTTP API — The Fedora 4 HTTP API is generally a RESTful API. HTTP methods like GET, PUT, POST and DELETE are implemented on most resource paths. The API also relies heavily on content negotiation to deliver context-appropriate responses, and a HATEOAS-driven text/html response (providing a decent GUI experience on top of the repository).
-
Versioning — Within Fedora 4, snapshots of the current state of a resource may be saved into the version history. The RDF for historic version shapshots may be browsed and old non-RDF content may be downloaded. Furthermore, an object or subgraph may be reverted to the state that it existed in a historic version.
-
-
-
RESTful HTTP API — The Fedora HTTP API is generally a RESTful API. HTTP methods like GET, PUT, POST and DELETE are implemented on most resource paths. The API also relies heavily on content negotiation to deliver context-appropriate responses, and a HATEOAS-driven text/html response (providing a decent GUI experience on top of the repository).
-
Versioning — Versioning in Fedora implements the Memento protocol. Its formal name is HTTP Framework for Time-based Access to Resource States – Memento. This document focuses exclusively on how the Fedora software implements the Memento software and best practices when using Fedora Versioning.
-
-
Versioning — Versioning in Fedora implements the Memento protocol. Its formal name is HTTP Framework for Time-based Access to Resource States – Memento. This document focuses exclusively on how the Fedora software implements the Memento software and best practices when using Fedora Versioning.
-
RESTful HTTP API — The Fedora HTTP API is generally a RESTful API. HTTP methods like GET, PUT, POST and DELETE are implemented on most resource paths. The API also relies heavily on content negotiation to deliver context-appropriate responses, and a HATEOAS-driven text/html response (providing a decent GUI experience on top of the repository).
Optional Features
-
External Search —
To support the differing needs for sophisticated, rich searching, Fedora 4 comes with a standard mechanism and integration point for indexing content in an external service. This could be a general search service such as Apache Solr or a standalone triplestore such as Fuseki or Blazegraph
-
Backup and Restore — The Fedora 4 Backup capability allows a user, such as the repository manager, make a REST call to have the repository binaries and metadata exported to the local file system. Inversely, the Restore capability allows a user to make a REST call to have the repository restored from the contents of a previous Backup operation. In addition, with the default configuration, files are stored on disk named according to their SHA1 digest, so a filesystem backup approach can also be used.
-
Backup and Restore — The Fedora 4 Backup capability allows a user, such as the repository manager, make a REST call to have the repository binaries and metadata exported to the local file system. Inversely, the Restore capability allows a user to make a REST call to have the repository restored from the contents of a previous Backup operation. In addition, with the default configuration, files are stored on disk named according to their SHA1 digest, so a filesystem backup approach can also be used.
-
External Search —
To support the differing needs for sophisticated, rich searching, Fedora 4 comes with a standard mechanism and integration point for indexing content in an external service. This could be a general search service such as Apache Solr or a standalone triplestore such as Fuseki or Blazegraph
-
Backup and Restore — The Fedora Backup capability allows a user, such as the repository manager, to make a REST call to have the repository binaries and metadata exported to the local file system. The Restore capability allows a user to make a REST call to have the repository restored from the contents of a previous Backup operation. In addition, with the default configuration, files are stored on disk named according to their SHA1 digest, so a filesystem backup approach can also be used.
-
External Search — To support the differing needs for sophisticated, rich searching, Fedora comes with a standard mechanism and integration point for indexing content in an external service. This could be a general search service such as Apache Solr or a standalone triplestore such as Fuseki or Blazegraph
-
Backup and Restore — The Fedora Backup capability allows a user, such as the repository manager, to make a REST call to have the repository binaries and metadata exported to the local file system. The Restore capability allows a user to make a REST call to have the repository restored from the contents of a previous Backup operation. In addition, with the default configuration, files are stored on disk named according to their SHA1 digest, so a filesystem backup approach can also be used.
-
External Search — To support the differing needs for sophisticated, rich searching, Fedora comes with a standard mechanism and integration point for indexing content in an external service. This could be a general search service such as Apache Solr or a standalone triplestore such as Fuseki or Blazegraph
-
Backup and Restore — The Fedora Backup capability allows a user, such as the repository manager, to make a REST call to have the repository binaries and metadata exported to the local file system. The Restore capability allows a user to make a REST call to have the repository restored from the contents of a previous Backup operation. In addition, with the default configuration, files are stored on disk named according to their SHA1 digest, so a filesystem backup approach can also be used.
Supplementary Information
-
Identifiers — Identifiers can be specified in REST API calls and generated either automatically using the internal PID minter or via an external REST service.
-
-
External Content — When referencing content hosted outside of the repository, you can create an empty binary to act as a placeholder for the external content, specifying the URL of the external content.
-
Identifiers — Identifiers can be specified in REST API calls and generated either automatically using the internal PID minter or via an external REST service.
-
Linked Data Platform — The W3C Linked Data Platform (LDP) specification details a simple approach for a read-write Linked Data architecture; lays out a set of best practices for Linked Data architecture; and defines a basic interaction model based on HTTP access to web resources that describe their state using the RDF data model. Fedora implements the LDP specification for create, read, update and delete (CRUD) operations, allowing HTTP, REST, and linked data clients to make requests to the repository.
-
External Content — When referencing content hosted outside of the repository, you can create an empty binary to act as a placeholder for the external content, specifying the URL of the external content.
-
Identifiers — Identifiers can be specified in REST API calls and generated either automatically using the internal PID minter or via an external REST service.
-
-
External Content — When referencing content hosted outside of the repository, you can create an empty binary to act as a placeholder for the external content, specifying the URL of the external content.
-
External Content — When referencing content hosted outside of the repository, you can create an empty binary to act as a placeholder for the external content, specifying the URL of the external content.
-
Linked Data Platform — The W3C Linked Data Platform (LDP) specification details a simple approach for a read-write Linked Data architecture, lays out a set of best practices for Linked Data architecture, and defines a basic interaction model based on HTTP access to web resources that describe their state using the RDF data model. Fedora implements the LDP specification for create, read, update and delete (CRUD) operations, allowing HTTP, REST, and linked data clients to make requests to the repository.
-
Identifiers — Identifiers can be specified in REST API calls and generated either automatically using the internal PID minter or via an external REST service.
-
External Content — When referencing content hosted outside of the repository, you can create an empty binary to act as a placeholder for the external content, specifying the URL of the external content.
-
Linked Data Platform — The W3C Linked Data Platform (LDP) specification details a simple approach for a read-write Linked Data architecture, lays out a set of best practices for Linked Data architecture, and defines a basic interaction model based on HTTP access to web resources that describe their state using the RDF data model. Fedora implements the LDP specification for create, read, update and delete (CRUD) operations, allowing HTTP, REST, and linked data clients to make requests to the repository.
-
Identifiers — Identifiers can be specified in REST API calls and generated either automatically using the internal PID minter or via an external REST service.
