Beginning with Hydra 9, the repository interactions underlying the Hydra platform are informed by the W3C Linked Data Platform specification. The first implementation of this specification that Hydra is built and tested against is Fedora Commons 4. Redesigning the repository interaction layer around LDP has identified areas in the LDP specification delegated to the implementation for which Hydra has its own requirements.

Clear Requirements of the LDP Implementation

1. Support for Containers
2. Support for NonRDFResources of arbitrary MIME type
   1. Because these may include descriptions of external entities, this must include MIMEs associated with RDF, but not managed as such by the LDP implementation 
   2. Hydra indicates this by use of a Content-Disposition:attachment header
3. HTTP PATCH support that accepts updates with Content-Type: application/sparql-update, cf Sparql insert behavior in Hydra base classes
4. Path segments including a colon (':') character, like a namespace-prefixed element
5. NonRDFResources must have a RDFResource describing them given in the object of a Link:<>; rel=ldp:describedBy header

Possible Requirements of the LDP Implementation

1. Hydra expects a successful PUT to a URI to result in a containment triple if it creates a resource (eg, PUT /a/b creates /a/b, and adds <a> ldp:contains <a/b>) 
2. Hydra expects the implementation to parse the filename out of the Content-Disposition header of a NonRDFSource, and:
   1. use it as the object of a <http://www.loc.gov/premis/rdf/v1#hasOriginalName> statement in its description
   2. return it in a Content-Disposition header in the response
3. Hydra expects the implementation to checksum the contents when creating a NonRDFSource, and expects the checksum to be added to the resource's description as the URI object of a <http://fedora.info/definitions/v4/repository#digest> statement 
4. Hydra expects a NonRDFSource to contain a RDFSource description of fixity status, with a literal <http://fedora.info/definitions/v4/repository#status> property equal to 'SUCCESS' if the checksum is verified
5. Unclear whether Hydra's interaction with versioned data is driven by navigation of properties generic to LDP, or whether the implementation is required to supply versions

Non-LDP Requirements

1. Hydra expects NonRdfSource URIs to respect Content-Range
2. Hydra expects NonRdfSource descriptions to include a checksum of the binary content
3. Hydra expects the repository to track date of creation and modification in RDF descriptions

Bugs in Hydra

1. Hydra relies on an implementation-specific URI pattern to identify the description of a NonRDFResource github issue 727 rather than the describedBy Link header indicated by LDP 1.0 sections 5.2.3.12, 5.2.6, and 4.2.8
2. Hydra expects PUT operations to include a Location response header
3. RDF Datastream implementations don't include Prefer headers for their expected serialization? Not relevant if they are correctly stored as NonRDFSource

Testing Requirements

1. The Cleaner test rig expects to both delete objects and free their URIs up (this seems like a bug)
2. Testing resources hard-code /fedora/rest as the LDP REST endpoint

Related Documents

A Brief Comparison of LDP-inspired and Traditional Fedora APIs