Contents and Ordering - Design 3 with Bindings

RmModuleDesign3WithBindings

Contents and Ordering - Design 1 - Requirements are LDPCs

A Module is an LDPC and its top-level requirements are member resources of that container. This specification places no restrictions on what resources may be contained in a module, nor on whether a member resource can be contained in more than one module. However, the intention is that the location of each member resource within a module is independent of membership of that resource in other LDPCs.

Each Module member resource which is a LDPR SHOULD represent it tree position in the module with a parent link, and if the tree is ordered, each member resource SHOULD have a oslc_rm:siblingOrder property.

Typically member resources will be LDPC resources, and thus Modules are n-ary trees (optionally ordered) of resources.

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.

In applications where child requirements are ordered, this SHOULD be indicated using [LDPC Ordering][2].

Use cases such as fetching all the content of a module (and recursively so) is currently OPEN

Applied Views

In this design, an applied view would reflect module structure my mirroring all LDPCs in the module with LDPCs representing the “view of” the corresponding node in the module. This is unworkable since it provides no linkage to the underlying data.

Position for non-LDPR member resources

Link: <http://example.com/doors/re12>; rel="http://open-services.net/ns/rm#parent"
Link: <1>; rel="http://open-services.net/ns/rm#order"

The problem with this design is that <1> is not a URI, so this is not valid use of HTTP Link header. I’ve asked Steve. Currently OPEN issue.

Example

:m1 a oslc_rm:Module;
    a ldp:Container;
    rdfs:member :r1;
    rdfs:member :r2.

:r1 a oslc_rm:Requirement,
      ldp:Container;
    rdfs:member :r3;
    dc:title "Requirement 1 with child 3".

:r2 a oslc_rm:Requirement,
      ldp:Container;
    dc:title "Requirement 2 with no children".

:r3 a oslc_rm:Requirement,
      ldp:Container;
    dc:title "Requirement 3 with no children".

Contents and Ordering - Design 2 - Requirements are NOT LDPCs

A Module is an LDPC and all requirements in that module MUST be member resources of that container.

Note: This specification places no restrictions on what resources may be contained in a module, nor on whether a member resource can be contained in more than one module. However, in this design the structure of the module is defined by the parent/siblingOrder properties on each of its members.

Each Module member resource which is a LDPR SHOULD represent it tree position in the module with an oslc_rm:parent and, if the module is ordered, an oslc_rm:siblingOrder property. The member resource MAY additionally have an LDPC ordering property. Container ordering is NOT REQUIRED, and if present, container ordering is NOT REQUIRED to be the module tree order. Applications should consider the performance implications of ordering container members using schemes where structural changes have non-local affects.

Member resources MAY be LDPC resources (and in particular, oslc_rm:Module resources) but this specification places no requirements on the ordering of member resources across nested containers.

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.

Example

:m1 a oslc_rm:Module;
    a ldp:Container;
    rdfs:member :r1;
    rdfs:member :r2;
    rdfs:member :r3.

:r1 a oslc_rm:Requirement;
    dc:title "Requirement 1 with child 3".

:r2 a oslc_rm:Requirement;
    dc:title "Requirement 2 with no children".

:r3 a oslc_rm:Requirement;
    oslc_rm:parent :r1;
    oslc_rm:siblingOrder 1;
    dc:terms "Requirement with no children".

Applied Views

An applied view is a LDPC whose members is a subset of the members of the corresponding module LDPC. (The membership difference being those members which are filtered out of the applied view.)

Structure in the applied view is a substructure of the LDPC structure. This means that the parent/siblingOrder properties on all members is the same as those in the module LDPC, but that the siblings in the applied view are a sublist of those in the module. Parent resources linked from a member of the applied view are NOT REQUIRED to be member resources of that applied view. Applied Views which reorder siblings are not directly representable in this design unless member resources have additional ordering predicates which are suitable for the applied view; such a design does not scale in the number of applied views.