Page History

...

This strawman proposal addresses the following issues:

1. Allow Fedora to create LDP-RS (RDF resources) that are NOT containers (LDPC), as allowed per the LDP spec.  These will henceforth be called LDP-RS-NCs ("LDP RDF Source, Non-containers") for the sake of this discussion
2. Allow the LDP-RS-NCs created by Fedora to contain arbitrary RDF
   1. No requirements on allowable subjects, predicates, or objects in the triples
   2. No constraints on constructs such as blank nodes
3. Allow the LDP-RS-NCs created to by Fedora to be 'pure' in that they are logically unmodified from client requests
   1. No server managed triples are added by Fedora
4. Allow the LDP-RS interaction model as defined by LDP on these resources
   
   1. Retrieve triples in specified representation (xml, turtle, ntriples, etc)
   2. Logical PUT operation (i.e. logical contents of graph are stored, not necessarily the serialization bytes)
   3. SPARQL Update semantics (PATCH)
   4. Interpretation of relative URIs as per the LDP spec (for example, allowing null relative URIs "<>" to refer to the to-be-created resource URI)

Proposal

LDP-RS-NCs in Fedora shall be datastreams, differing only from binary datastreams (exposed as LDP-NRs in LDP) in the following significant ways:

1. Fedora's HTTP APIs support LDP-RS operations on these resources such as the logical PUT and  PATCH,  resolution of relative URIs in the content, etc.
2. Fedora may describe these resources using slightly different metadata in their corresponding 'fcr:metadata' resources.  For example, LDP-RS-NCs may have a different mixin type than LDP-NRs
3. Basic validation as well-formed RDF or SPARQL/update statements is a prerequisite for accepting content.
4. The binary representation of an LDP-RS-NC as persisted in Fedora as datastream content may potentially be opaque (a decision would need to be made on this)
   1. The serialization format may be specified in advance.  For example, Fedora may chose to serialize as turtle, always
   2. Fedora may perhaps chose to store the exact binary content supplied by the client via PUT, and record metadata indicating which RDF serialization had been persisted.
   3. Likewise, the content may be entirely opaque, leaving it an implementation decision that can change at any time.

An LDP-RS-NC shall be created when the client specifies an LDPR interaction model for newly created resources as per section 5.2.3.4 of the LDP spec.