An oslc_rm:Requirement MAY be of rdf:type ldp:Container. In such cases, oslc_rm:Requirement MUST conform to the requirements of LDPC, as specified by LPD.

RMOtherModuleDesigns

Contents and Ordering - Design 3 - Requirements are NOT LDPCs, module separate structure and content

Overview

A Module resource is a container of requirements; Requirements in a module are typically organized into a hierarchical structure like a document. We could call this a “requirements specification”. A Module is similar to an oslc_rm:RequirementCollection but for the structuring of its requirements.

I suppose a module is bit like a desconstructed HTML subset/RDFa document. Why do we need this - how about HTML/RDFa and PATCH and DIFF?

A module oragnize its requirements into hierarchical structure by providing a structure container. Separating the content of the module from its structure allows different modules to share or partially share the same content, and to allow different organizations of that content.

Applications may offer a variety of ways of obtaining a derived module from from data (for example, running a script, or evaluating a view definition). This specification does not describe a notion of view or applied view but instead describes the resource representations which might result. TODO - do we want AppliedView?

This specification uses LDP(C) resources to standardise the way that resources are added and removed from a module, and how the structure a that module can be defined and updated.

Specification

A Module is a LDPC with type oslc_rm:Module. Each member resource MUST be an LDPR. Each Module member resource MUST have an oslc_rm:bound property which references a resource informally called the “bound resource”.

Module member resources MAY be LDPC resources (and in particular, oslc_rm:Module resources) but this specification places no additional requirements in this case.

Note: This specification places no restrictions on whether a Module member resource can be contained in more than one module.

Note: A binding’s oslc_rm:bound property may refer to itself (the binding resource and the bound resource can be the same resource).

Note: I see no reason to give a typing to a binding resource. Notionally, “oslc_rm:bound rdfs:domain x:Binding”.

A module LDPC MAY define a LDPC container ordering. This specification places no requirements on container ordering.

A module MAY have a (non-member) oslc_rm:structure property. When present the object of this property MUST be a LDPC whose member resources link together binding resources in an application-defined structure. These member resources MUST have an oslc_rm:entry property to identify the bound resource that is being placed in the structure. OPTIONAL properties oslc_rm:parent and oslc_rm:siblingOrder describe structural relations to other member resources. The optional properties are sufficient to define directed graphs, n-ary trees, ordered n-ary trees, ordered lists and unordered lists.

TODO: should we use unordered lists to unify requirementcollection? TODO: do we need to specify what we mean by these data structures and exactly how these terms should be used to represent them?

The structure LDPC MAY additionally define a LDPC container ordering. This specification places no requirements on any such container ordering.

Non-LDPR member resources are permitted by this specification and such members MUST indicate location with HTTP Header information (see section XXX). It seems that non-LDPR member resources may require some attention.

Applied Views

An applied view is a Module with an oslc_rm:derivedFrom link to the resource which describes the relation bewteen an applied view and some other resource. A common application is that applied views are derived from some computation over a data set.

TODO: Do we want to define:

<> a oslc_rm:AppliedViewGenerator;
   oslc_rm:module :m1,:m2,:m3;    # a view of multiple modules
   oslc_rm:view :view1.  # not shown here

Or instead should we admit that oslc_rm:derivedFrom to point directly at a module, in which case the view is not represented. This is likely sufficient for current use cases. oslc_rm:derivedFrom is multi-valued so allowing an applied view to aggregate data across multiple data sets.

Note: The intention is that the members of the applied view LDPC is a subset of the union of the members of the linked Module LDPCs, but this is NOT REQUIRED by this specification.

The applied view MAY have an oslc_rm:structure resource to describe ordering of the bindings in the applied view.

TRS

This is an informative note.

LDP makes no provision for the efficient communication of LDPC changes over TRS. In the abscence of efficient patch/diff mechanisms in TRS it is likely that an LDPC with a large number of members will place significant load on the LDP server as well as on network and consumers of the LPDC representation.

For this reason implementors should carefully consider the consequences of adding LDPC resources to their TRS and consider other designs, such as the one shown in the example, where the membership triples are repeated in each member resource. In such a design the TRS resource set would not include Module LDPC resources.

Ordering and Paging

TODO. LDPC spec requires pagination of containers, and this specification places no additional requirements on pagination.

Example

@prefix dc:        <http://purl.org/dc/terms/> .
@prefix ldp:       <http://www.w3.org/ns/ldp#> .
@prefix oslc_rm:   <http://open-services.net/ns/rm#> .
@prefix rdfs:      <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf:       <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix :          <http://example.org/doors> .

# representtion of :m1
:m1 a ldp:Container, oslc_rm:Module;
    ldp:containerResource :m1;
    ldp:containerRelation rdfs:member;
    ldp:insertedContentReleation ldp:MemberSubject;
    rdfs:member :r1, :b2, :r3;
    oslc_rm:structure :s1;
    dc:title    "Module One".

# representation of :r1    
:r1 a oslc_rm:Requirement;
    oslc_rm:bound :r1;
    dc:title    "Requirement 1 with child 3" .


:b2 oslc_rm:bound :r2 .
:r2 a oslc_rm:Requirement;
    dc:title    "Requirement 2 without children" .

:r3 a oslc_rm:Requirement;
    oslc_rm:bound :r3;
    dc:title    "Requirement 3 without children" .

:s1 a ldp:Container;
    rdfs:member :s11, :s12, :s13 .

# representation of :s11
:s11 oslc_rm:entry :r1;
     u:order "1".
:s1 rdfs:member <>.

# representation of :s12
:s12 oslc_rm:entry :b2;
     u:order "2".
:s1 rdfs:member <>.

# representation of :s13
:s13 oslc_rm:entry :r3;
     u:order "3";
     oslc_rm:parent :s11.
:s1 rdfs:member <>.

:av1 a ldp:Container, oslc_rm:Module; # other container properties omitted
    oslc_rm:structure :avs1;
    rdfs:member :r1, :b2, :r3;
    oslc_rm:derivedFrom :m1;
    dc:title    "Applied View One of module one".

# representation of :avs1   
:avs1 a ldp:Container;
    rdfs:member :avs12, :avs13 .

# representation of :avs12
:avs12 oslc_rm:entry :b2;
     u:order "2".
:avs1 rdfs:member <>.

# representation of :avs13
:avs13 oslc_rm:entry :r3;
     u:order "1".
:avs1 rdfs:member <>.