Page History

...

...

Proposal: LDP-RS as datastreams

This strawman proposal addresses the following issues:

In this proposal, an LDP-RS-NC maps to a Fedora datastream.  In the fedora object model, they are no different from the datastreams that already exist, and have no inherent characteristics that make them different in any way.  The difference lies in the HTTP API, in that they support the LDP-RS interaction mode as described in the background section of this document. 

An LDP-RS-NC (datastream) 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.

LDP to Fedora mapping

Note that 'Objects' in the Fedora model map to the LDPC interaction model, while 'Datastreams' in Fedora map to the LDPR interaction model.

Discussion

Mapping the LDP-RS-NC (non-container RDF source resources) to datastreams has several consequences as a result of the LDP-RS interaction mode defined by LDP, or as a result of their nature as a datastream

1. The Fedora object model does not change at all with this proposal
2. The LDP-RS-NCs created by Fedora may contain arbitrary RDF.  This is a consequence of their 'datastream' nature, in that their content is largely opaque to the Fedora model.  They are blobs, so there is no inherent need to constrain their content other than to verify that they contain RDF as implied by an LDP-RS.
   1. No inherent restriction
3. 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
4. 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 inherent restriction on constructs such as blank nodes
5. Allow the The LDP-RS-NCs created to by Fedora to may be 'pure' in that they are logically unmodified from client requests.  Again, this is due to their nature as an opaque datastream as far as the fedora model is concerned.  
   1. No server managed triples are added by Fedora
6. Allow The LDP-RS-NCs benefit from the LDP-RS interaction model as defined by LDP on these resources:
   
   1. Retrieve triples in specified representation (xml, turtle, ntriples, etc)Logical PUT operation (i.e. logical contents of graph are stored, not necessarily the serialization bytes), turtle, ntriples, etc); as per LDP spec text/turtle and application/ld+json representations are always available.
   2. SPARQL Update semantics (PATCH)
   3. Interpretation Interpretation of relative URIs as in RDF content as per the LDP spec (for example, allowing null relative URIs "<>" to refer to the to-be-created resource URI)

Specifics:

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. 1. -be-created resource URI)

If it helps, this proposal can be also be conceptualized as a kind of 'service' provided on top of a datastream to provide an enhanced RDF CRUD API that neatly maps to an LDP concept that Fedora does not currently support, but most LDP servers do.  

Implementation notes

1. 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:metadata' resources.
   1. For example, "fedora:mixinTypes "fedora:NonRdfSourceDescription"^^<http://www.w3.org/2001/XMLSchema#string>" is probably not appropriate.
2. Basic validation as well-formed RDF or SPARQL/update statements is a prerequisite for accepting content.
3. 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.

...

1. 1. .

...

Proposal:  LDPRs as "Pointlike objects"

...