The goal of this effort is to define a common set of resources, formats and RESTful services for the use in Requirements Definition and Management tools and use by (for example) systems engineering or ALM tools that will enable the effective use of requirements across a development life-cycle.

Requirements Management (RM) resources define the requirements or capabilities of a system or the outcome of some programme of work. We use the term system entirely generally and without prejudice to software, hardware, IT, regulatory, business etc.

Requirements are the basis for defining what the system stakeholders (users, customers, suppliers and so on) need from a system and also what the system must do in order to meet those needs, and how the surrounding processes must be orchestrated so that quality, scope and timescale objectives are satisfied. The discipline of requirements management involves many activities including elicitation, definition, documentation, analysis, decomposition, validation and justification; it involves managing changes to requirements and establishing and reasoning about their interrelationships. In involves the creation of assets which are invariably related to other systems and processes. RM is inherently multi-disciplinary and across the life-cycle; it brings together all assets across the life-cycle, ascribing them meaning, captures their dependencies and interrelationships and ultimately, captures the way in which they together produce the desired system.

Requirements management activities

• Elicitation, definition and communication introduce requirements in such a way that relevant stakeholders can understand and agree that the system will meet their needs.
• Gathering requirements and related assets into a coherent set, for example as a set of requirements documents, as part of forming a precise overarching specification of the system. Such a set of requirements is often part of a contractual agreement between parties, for example.
• Analysis aids the understanding of requirements and enables the expression of refactored, decomposed, refined, elaborated, or clarified requirements. Assets such as system models may be created during such analysis.
• The need to validate the system induces the need to create test requirements that demonstrate that all requirements have been met, and thus, for example, that contractual obligations have been discharged.
• The need to deal with ambiguity, complexity or testability of a requirement leads to lower-level, related derived artefacts. These derived artefacts may be requirements, or they could be from some other system, such as change requests, diagrams stored in a PLE system and so on.
• The recording and management of the links created as part of each of these processes is central to understanding the meaning of requirements, assessing the impact of proposed or actual change and, through the recording of rationale information, validation that lower-level requirements are correctly derived from higher-level requirements.
• The need to plan the scope of a release or milestone in order that the requirements that are to be met are known and meaningful and will meet the stakeholders’ needs.

Traceability analysis

Impact analysis exploits the links created during such derivation and analysis in order to understand the ramifications of actual or proposed changes to higher-level requirements. In this way the impact to the system, or aspects of its delivery can be assessed and acted upon.

Derivation analysis exploits links in order to inform cost/benefit analysis processes, or to understand the rationale for some parts of the system, and the ramifications of actual or proposed change to those parts.

Coverage analysis informs planning and progress processes and it also provides verification information on the satisfaction of a requirement by other assets, and contributes validation information to the quality processes that are responsible for the creation and management of test requirements and other test-related assets.

In each of these kinds of trace analysis, the type of links being analyzed is significant, as is the justification argument which describes why that link is present.

Management of change and auditing

Changes to requirements reflect changing needs or system behaviours. Trace analysis informs change processes, as do other life-cycle characteristics, such as stability of the requirement. Auditing processes may be used to support accountability for historical changes.

Requirements across the life-cycle

Requirements are the engineering language used to define not only the needs of the system stakeholders but also the performance and constraints of the system itself. As such, most other lifecycle activities are either based on requirement data or heavily influence the requirement baseline of a development project. Once you have established processes for requirements management, change management, quality, and model-driven development, the next logical step is to integrate them in a collaborative ALM environment. This helps organisations not only break down silos, but can also accelerate process maturity. For example, this approach can make it easier to demonstrate overall solution compliance and produce cross discipline metrics that support more informed decision making.

Requirements Driven Development

When development activities are enabled using integrated requirements data, they provide focus, traceability and impact analysis. Developers can address issues and priorities without the need to access multiple repositories for information. Achieving process maturity in ALM depends on having a reliable, on-demand view of progress across the entire project in both agile development initiatives and traditional waterfall approaches. Round-trip traceability enables analysis of the contents of each build, baseline, and release. Teams can see exactly which requirements, change requests, and development tasks have been implemented and which have not. In addition, the ALM platform displays the differences between different baselines. As such, teams can see what has changed. This approach makes it easier to demonstrate accountability, ensure security, and complete audits.

Requirements Driven Testing

One of the biggest challenges to testing maturity is to confine testing at the end of development when bugs are most costly to fix, resources are low, and time is short. With the ability to map requirements directly to test cases, test engineers can see exactly what requirements and features they should be testing, as well as who made changes and when. Teams can check to see that requirements match specifications, customer requests, regulations, and standards early in development. Testers can also describe the tests associated with each requirement as soon as these are defined to ensure that testability considered when writing requirements.

Model Driven Development (MDD)
Integrated MDD helps development teams better manage system complexity by focusing on high-level design and development of application architecture and software using a graphical language. This enables team to translate requirements to a system model depicting functionality and to validate its behaviour through simulation. Often analysis of the results yields a route for further development and test. Incorporating MDD into the ALM environment reduces the gap between the project requirements and the final implementation. The ability to visualize requirements and trace them throughout the lifecycle improves understanding and project-wide impact analysis.

Approach

The specifications will be developed iteratively by first prioritizing scenarios and focusing on a minimal set of key scenarios. Once these scenarios have been satisfied by specification and proof of implementation, more scenarios will be considered.

OSLC RM Specifications

OSLC RM 1.0 Specification (Finalized)

OSLC RM 2.0 Specification (Finalized)

The following table shows the materials produced during the V2.0 specification effort.

OSLC RM 3.0 Specification (In Progress)

Meetings

Meeting agendas and minutes

Feedback

If you have feedback on a specification or on scenario development, please use the release-specific pages documented above. If you have feedback on OLSC more generally, please get in touch with the RM workgroup lead by email, or come to one of the meetings.

Mailing Lists

Requirements Management
General Open Services

Terminology

We’re building a [[Requirements Management definitions | glossary of terms and definitions]]

[[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 <>.

[[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.

[[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. 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.

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 <>.

[[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. 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.

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 <>.

[[RMOtherModuleDesigns]]

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

Overview

A Module resource is a container of binding resources; these binding resources refer to other “bound” resources. For example, a module might contain an ordered tree of requirements representing a specification document; a module could contain test cases or change requests, or any other linked data.

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 may oragnize its binding resources into structures (like a tree) by providing a separate structure container. Separating the content from the structure allows different modules to share or partially share the same content, and to allow different organizations of that content. Applied Views are a particular use case here, where module content is restructured and potentially filtered to result in a derived module.

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 spec does not describe a notion of view or applied view.

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

Spec

A Module is a LDPC with type oslc_rm:Module. Each Module 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 <>.

[[RMOtherModuleDesigns]]

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

Overview

A Module resource is a container of binding resources; these binding resources refer to other “bound” resources. For example, a module might contain an ordered tree of requirements representing a specification document; a module could contain test cases or change requests, or any other linked data.

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 may oragnize its binding resources into structures (like a tree) by providing a separate structure container. Separating the content from the structure allows different modules to share or partially share the same content, and to allow different organizations of that content. Applied Views are a particular use case here, where module content is restructured and potentially filtered to result in a derived module.

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 spec does not describe a notion of view or applied view.

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

Spec

A Module is a LDPC with type oslc_rm:Module. Each Module 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 (perhaps these are nested?)
   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:isAppliedViewOf :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 <>.

[[RMOtherModuleDesigns]]

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

Overview

A Module resource is a container of binding resources; these binding resources refer to other “bound” resources. For example, a module might contain an ordered tree of requirements representing a specification document; a module could contain test cases or change requests, or any other linked data.

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 may oragnize its binding resources into structures (like a tree) by providing a separate structure container. Separating the content from the structure allows different modules to share or partially share the same content, and to allow different organizations of that content. Applied Views are a particular use case here, where module content is restructured and potentially filtered to result in a derived module.

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 spec does not describe a notion of view or applied view.

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

Spec

A Module is a LDPC with type oslc_rm:Module. Each Module 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”.

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. Container ordering is NOT REQUIRED, and if present, container ordering is NOT REQUIRED to be related to any ordering over the structure of the LDPC members. 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

@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:isAppliedViewOf :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 <>.

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;
   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.

Note: The intention is that the members of the Applied View LDPC is a subset of the members of the linked Module LDPC, but this is NOT REQUIRED by this specification. The membership difference being those members which are “filtered out” of the associated data set.

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.

[[RMOtherModuleDesigns]]

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

Overview

A Module resource is a container of binding resources; these binding resources refer to other “bound” resources. For example, a module might contain an ordered tree of requirements representing a specification document; a module could contain test cases or change requests, or any other linked data.

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 may oragnize its binding resources into structures (like a tree) by providing a separate structure container. Separating the content from the structure allows different modules to share or partially share the same content, and to allow different organizations of that content. Applied Views are a particular use case here, where module content is restructured and potentially filtered to result in a derived module.

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 spec does not describe a notion of view or applied view.

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

Spec

A Module is a LDPC with type oslc_rm:Module. Each Module 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”.

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. Container ordering is NOT REQUIRED, and if present, container ordering is NOT REQUIRED to be related to any ordering over the structure of the LDPC members. 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

@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:isAppliedViewOf :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 <>.

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;
   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.

Note: The intention is that the members of the Applied View LDPC is a subset of the members of the linked Module LDPC, but this is NOT REQUIRED by this specification. The membership difference being those members which are “filtered out” of the associated data set.

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.

Ordering and Paging

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

[[RMOtherModuleDesigns]]

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

Overview

A Module resource is a container of binding resources; these binding resources refer to other “bound” resources. For example, a module might contain an ordered tree of requirements representing a specification document; a module could contain test cases or change requests, or any other linked data.

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 may oragnize its binding resources into structures (like a tree) by providing a separate structure container. Separating the content from the structure allows different modules to share or partially share the same content, and to allow different organizations of that content. Applied Views are a particular use case here, where module content is restructured and potentially filtered to result in a derived module.

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 spec does not describe a notion of view or applied view.

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

Spec

A Module is a LDPC with type oslc_rm:Module. Each Module 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”.

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 resource. A structure resource MUST be a LDPC whose member resources link together binding resources in an application-defined structure. Common structures include n-ary trees, ordered n-ary trees, ordered lists and unordered lists. (TODO: should we use unordered lists to unify requirementcollection?)

This specification defines vocabulary terms oslc_rm:parent and oslc_rm:siblingOrder sufficient to represent ordered n-ary trees, unordered n-ary trees, ordered lists and unordered lists. Structure members

The structure LDPC MAY additionally define a LDPC container ordering. Container ordering is NOT REQUIRED, and if present, container ordering is NOT REQUIRED to be related to any ordering over the structure of the LDPC members. 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

@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 rdf:subject :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:isAppliedViewOf :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 <>.

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;
   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.

Note: The intention is that the members of the Applied View LDPC is a subset of the members of the linked Module LDPC, but this is NOT REQUIRED by this specification. The membership difference being those members which are “filtered out” of the associated data set.

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.

Ordering and Paging

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

[[RMOtherModuleDesigns]]

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

Overview

A Module resource is a container of binding resources; these binding resources refer to other “bound” resources. For example, a module might contain an ordered tree of requirements representing a specification document; a module could contain test cases or change requests, or any other linked data.

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 may oragnize its binding resources into structures (like a tree) by providing a separate structure container. Separating the content from the structure allows different modules to share or partially share the same content, and to allow different organizations of that content. Applied Views are a particular use case here, where module content is restructured and potentially filtered to result in a derived module.

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 spec does not describe a notion of view or applied view.

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

Spec

A Module is a LDPC with type oslc_rm:Module. Each Module 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”.

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 MAY have a (non-member) oslc_rm:structure resource which when present MUST be an LDPC.

A structure resource is an LDPC whose member resources link together binding resources in an application-defined structure. Common structures include n-ary trees, ordered n-ary trees, ordered lists and unordered lists. (TODO: should we use unordered lists to unify requirementcollection?)

A server should define the structure resources it uses but such definition is outside the scope of this specification. This specification defines vocabulary terms oslc_rm:parent and oslc_rm:siblingOrder sufficient to represent ordered n-ary trees, unordered n-ary trees, ordered lists and unordered lists.

Each member resource of a structure LDPC represents structure using oslc_rm:parent and oslc_rm:siblingOrder. The member resource MAY additionally have an LDPC ordering property. However container ordering is NOT REQUIRED, and if present, container ordering is NOT REQUIRED to be related to any ordering over the structure of the LDPC members. 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

@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 rdf:subject :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:isAppliedViewOf :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 <>.

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;
   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.

Note: The intention is that the members of the Applied View LDPC is a subset of the members of the linked Module LDPC, but this is NOT REQUIRED by this specification. The membership difference being those members which are “filtered out” of the associated data set.

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.

Ordering and Paging

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

[[RMOtherModuleDesigns]]

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

Overview

A Module resource is a container of binding resources; these binding resources refer to other “bound” resources. For example, a module might contain an ordered tree of requirements representing a specification document; a module could contain test cases or change requests, or any other linked data.

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 may oragnize its binding resources into structures (like a tree) by providing a separate structure container. Separating the content from the structure allows different modules to share or partially share the same content, and to allow different organizations of that content. Applied Views are a particular use case here, where module content is restructured and potentially filtered to result in a derived module.

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 spec does not describe a notion of view or applied view.

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

Spec

A Module is a LDPC with type oslc_rm:Module. A module contains binding resources - these are the LDPC member resources. A binding resource (or binding) MUST have an oslc_rm:bound property which references the bound resource.

Note: A binding can refer to itself (the binding resource and the bound resource can be the same resource).

A module MAY have a (non-member) oslc_rm:structure resource which MUST be an LDPC.

A structure resource an LDPC whose member resources link binding resources into an application-defined structure. Common structures include n-ary trees, ordered n-ary trees, ordered lists and unordered lists. (TODO: should we use unordered lists to unify requirementcollection?)

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.

Note: This spec does not place additonal requirements on access to non-member resource of a Module.

A server should define the structure resources it uses (HOW WOULD IT DO THIS?). This specification (OR IS IT A PROFILE?) defines vocabulary terms oslc_rm:parent and oslc_rm:siblingOrder sufficient to represent ordered n-ary trees, unordered n-ary trees, ordered lists and unordered lists.

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

@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 rdf:subject :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:isAppliedViewOf :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 <>.

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;
   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.

Note: The intention is that the members of the Applied View LDPC is a subset of the members of the linked Module LDPC, but this is NOT REQUIRED by this specification. The membership difference being those members which are “filtered out” of the associated data set.

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.

Ordering and Paging

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

[[RMOtherModuleDesigns]]

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

Overview

A Module resource is a container of binding resources; these binding resources refer to other “bound” resources. For example, a module might contain an ordered tree of requirements representing a specification document; a module could contain test cases or change requests, or any other linked data.

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 may oragnize its binding resources into structures (like a tree) by providing a separate structure container. Separating the content from the structure allows different modules to share or partially share the same content, and to allow different organizations of that content. Applied Views are a particular use case here, where module content is restructured and potentially filtered to result in a derived module.

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 spec does not describe a notion of view or applied view.

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

Spec

A Module is a LDPC with type oslc_rm:Module. A module contains binding resources - these are the LDPC member resources. A binding resource (or binding) MUST have an oslc_rm:bound property which references the bound resource.

Note: A binding can refer to itself (the binding resource and the bound resource can be the same resource).

A module MAY have a (non-member) oslc_rm:structure resource which MUST be an LDPC.

A structure resource an LDPC whose member resources link binding resources into an application-defined structure. Common structures include n-ary trees, ordered n-ary trees, ordered lists and unordered lists. (TODO: should we use unordered lists to unify requirementcollection?)

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.

Note: This spec does not place additonal requirements on access to non-member resource of a Module.

A server should define the structure resources it uses (HOW WOULD IT DO THIS?). This specification (OR IS IT A PROFILE?) defines vocabulary terms oslc_rm:parent and oslc_rm:siblingOrder sufficient to represent ordered n-ary trees, unordered n-ary trees, ordered lists and unordered lists.

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

@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 rdf:subject :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:isAppliedViewOf :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 <>.

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;
   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.

Note: The intention is that the members of the Applied View LDPC is a subset of the members of the linked Module LDPC, but this is NOT REQUIRED by this specification. The membership difference being those members which are “filtered out” of the associated data set.

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

TODO: Do we want to specific oslc_rm:relatedView to reference ??? Servers MAY use an oslc_rm:AppliedView to indicate that the Module resource is an applied view, and the properties oslc_rm:isAppliedViewOf to indicate what resource this is a view of, and oslc_rm:relatedView to indicate which view defines this 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.

[[RMOtherModuleDesigns]]

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

Overview

A Module resource is a container of binding resources; these binding resources refer to other “bound” resources. For example, a module might contain an ordered tree of requirements representing a specification document; a module could contain test cases or change requests, or any other linked data.

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

A module may oragnize its binding resources into structures (like a tree) by providing a separate structure container. Separating the content from the structure allows different modules to share or partially share the same content, and to allow different organizations of that content. Applied Views are a particular use case here, where module content is restructured and potentially filtered to result in a derived module.

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 spec does not describe a notion of view or applied view.

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

Spec

A Module is a LDPC with type oslc_rm:Module. A module contains binding resources - these are the LDPC member resources. A binding resource (or binding) MUST have an oslc_rm:bound property which references the bound resource.

Note: A binding can refer to itself (the binding resource and the bound resource can be the same resource).

A module MAY have a (non-member) oslc_rm:structure resource which MUST be an LDPC.

A structure resource an LDPC whose member resources link binding resources into an application-defined structure. Common structures include n-ary trees, ordered n-ary trees, ordered lists and unordered lists. (TODO: should we use unordered lists to unify requirementcollection?)

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.

Note: This spec does not place additonal requirements on access to non-member resource of a Module.

A server should define the structure resources it uses (HOW WOULD IT DO THIS?). This specification (OR IS IT A PROFILE?) defines vocabulary terms oslc_rm:parent and oslc_rm:siblingOrder sufficient to represent ordered n-ary trees, unordered n-ary trees, ordered lists and unordered lists.

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

@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 rdf:subject :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:isAppliedViewOf :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 <>.

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;
   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.

Note: The intention is that the members of the Applied View LDPC is a subset of the members of the linked Module LDPC, but this is NOT REQUIRED by this specification. The membership difference being those members which are “filtered out” of the associated data set.

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

TODO: Do we want to specific oslc_rm:relatedView to reference ??? Servers MAY use an oslc_rm:AppliedView to indicate that the Module resource is an applied view, and the properties oslc_rm:isAppliedViewOf to indicate what resource this is a view of, and oslc_rm:relatedView to indicate which view defines this 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.

[[RMOtherModuleDesigns]]

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

Overview

A Module resource is a container of binding resources; these binding resources refer to other “bound” resources. For example, a module might contain an ordered tree of requirements representing a specification document; a module could contain test cases or change requests, or any other linked data.

I suppose a module is bit like HTML and RDFa with an API that allows efficient update to structure and content and sharing. Why do we need this - how about HTML/RDFa and PATCH and DIFF?

A module may oragnize its binding resources into structures (like a tree) by providing a separate structure container. Separating the content from the structure allows different modules to share or partially share the same content, and to allow different organizations of that content. Applied Views are a particular use case here, where module content is restructured and potentially filtered to result in a derived module.

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 spec does not describe a notion of view or applied view.

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

Spec

A Module is a LDPC with type oslc_rm:Module. A module contains binding resources - these are the LDPC member resources. A binding resource (or binding) MUST have an oslc_rm:bound property which references the bound resource.

Note: A binding can refer to itself (the binding resource and the bound resource can be the same resource).

A module MAY have a (non-member) oslc_rm:structure resource which MUST be an LDPC.

A structure resource an LDPC whose member resources link binding resources into an application-defined structure. Common structures include n-ary trees, ordered n-ary trees, ordered lists and unordered lists. (TODO: should we use unordered lists to unify requirementcollection?)

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.

Note: This spec does not place additonal requirements on access to non-member resource of a Module.

A server should define the structure resources it uses (HOW WOULD IT DO THIS?). This specification (OR IS IT A PROFILE?) defines vocabulary terms oslc_rm:parent and oslc_rm:siblingOrder sufficient to represent ordered n-ary trees, unordered n-ary trees, ordered lists and unordered lists.

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

@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 rdf:subject :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:isAppliedViewOf :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 <>.

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;
   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.

Note: The intention is that the members of the Applied View LDPC is a subset of the members of the linked Module LDPC, but this is NOT REQUIRED by this specification. The membership difference being those members which are “filtered out” of the associated data set.

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

TODO: Do we want to specific oslc_rm:relatedView to reference ??? Servers MAY use an oslc_rm:AppliedView to indicate that the Module resource is an applied view, and the properties oslc_rm:isAppliedViewOf to indicate what resource this is a view of, and oslc_rm:relatedView to indicate which view defines this 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.

[[RMOtherModuleDesigns]]

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

Overview

A Module resource is a container of binding resources; these binding resources refer to other “bound” resources. A module may oragnize its binding resources into structures (like a tree) by providing a separate structure container. Separating the content from the structure allows different modules to share or partially share the same content, and to allow different organizations of that content. Applied Views are a particular use case here, where module content is restructured and potentially filtered to result in a derived module.

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 spec does not describe a notion of view or applied view.

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

Spec

A Module is a LDPC with type oslc_rm:Module. A module contains binding resources - these are the LDPC member resources. A binding resource (or binding) MUST have an oslc_rm:bound property which references the bound resource.

Note: A binding can refer to itself (the binding resource and the bound resource can be the same resource).

A module MAY have a (non-member) oslc_rm:structure resource which MUST be an LDPC.

A structure resource an LDPC whose member resources link binding resources into an application-defined structure. Common structures include n-ary trees, ordered n-ary trees, ordered lists and unordered lists. (TODO: should we use unordered lists to unify requirementcollection?)

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.

Note: This spec does not place additonal requirements on access to non-member resource of a Module.

A server should define the structure resources it uses (HOW WOULD IT DO THIS?). This specification (OR IS IT A PROFILE?) defines vocabulary terms oslc_rm:parent and oslc_rm:siblingOrder sufficient to represent ordered n-ary trees, unordered n-ary trees, ordered lists and unordered lists.

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

@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 rdf:subject :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:isAppliedViewOf :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 <>.

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;
   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.

Note: The intention is that the members of the Applied View LDPC is a subset of the members of the linked Module LDPC, but this is NOT REQUIRED by this specification. The membership difference being those members which are “filtered out” of the associated data set.

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

TODO: Do we want to specific oslc_rm:relatedView to reference ??? Servers MAY use an oslc_rm:AppliedView to indicate that the Module resource is an applied view, and the properties oslc_rm:isAppliedViewOf to indicate what resource this is a view of, and oslc_rm:relatedView to indicate which view defines this 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.

[[RMOtherModuleDesigns]]

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

A Module is a LDPC with type oslc_rm:Module. A module contains binding resources - these are the LDPC member resources. A binding resource (or binding) MUST have an oslc_rm:bound property which references the bound resource.

Note: A binding can refer to itself (the binding resource and the bound resource can be the same resource).

A module MAY have a (non-member) oslc_rm:structure resource which MUST be an LDPC.

A structure resource an LDPC whose member resources link binding resources into an application-defined structure. Common structures include n-ary trees, ordered n-ary trees, ordered lists and unordered lists. (TODO: should we use unordered lists to unify requirementcollection?)

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.

Note: This spec does not place additonal requirements on access to non-member resource of a Module.

A server should define the structure resources it uses (HOW WOULD IT DO THIS?). This specification (OR IS IT A PROFILE?) defines vocabulary terms oslc_rm:parent and oslc_rm:siblingOrder sufficient to represent ordered n-ary trees, unordered n-ary trees, ordered lists and unordered lists.

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

@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 rdf:subject :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:isAppliedViewOf :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 <>.

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;
   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.

Note: The intention is that the members of the Applied View LDPC is a subset of the members of the linked Module LDPC, but this is NOT REQUIRED by this specification. The membership difference being those members which are “filtered out” of the associated data set.

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

TODO: Do we want to specific oslc_rm:relatedView to reference ??? Servers MAY use an oslc_rm:AppliedView to indicate that the Module resource is an applied view, and the properties oslc_rm:isAppliedViewOf to indicate what resource this is a view of, and oslc_rm:relatedView to indicate which view defines this 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.

[[RMOtherModuleDesigns]]

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

A Module is a LDPC with type oslc_rm:Module. A module contains binding resources - these are the LDPC member resources. A binding resource (or binding) MUST have an oslc_rm:bound property which references the bound resource.

Note: A binding can refer to itself (the binding resource and the bound resource can be the same resource).

A module MAY have an oslc_rm:structure resource which MUST be an LDPC. The structure resource is a non-member resource of the LDPC which links binding resources into an application-defined structure. Common structures include n-ary trees, ordered n-ary trees, ordered lists and unordered lists. (TODO: should we use unordered lists to unify requirementcollection?)

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.

Note: This spec does not place additonal requirements on access to non-member resource of a Module.

A server should define the structure resources it uses (HOW WOULD IT DO THIS?). This specification (OR IS IT A PROFILE?) defines vocabulary terms for ordered n-ary trees.

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

@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 rdf:subject :r3;
     u:order "3";
     oslc_rm:parent :s11.
:s1 rdfs:member <>.

:av1 a ldp:Container, oslc_rm:AppliedView;
    oslc_rm:structure :avs1;
    rdfs:member :r1, :b2, :r3;
    oslc_rm:isAppliedViewOf :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 <>.

Applied Views

An applied view is a LDPC whose content is a subset of the members of the corresponding module content LDPC. (The membership difference being those members which are filtered out of the applied view.) The applied view MAY have an oslc_rm:structure resource to describe ordering of the bindings in the applied view.

??? Servers MAY use an oslc_rm:AppliedView to indicate that the Module resource is an applied view, and the properties oslc_rm:isAppliedViewOf to indicate what resource this is a view of, and oslc_rm:relatedView to indicate which view defines this applied view.

Structure in the applied view may be entirely unrelated to the structure of the module 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.

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.

[[RMOtherModuleDesigns]]

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

A Module is a LDPC with type oslc_rm:Module. A module contains binding resources - these are the LDPC member resources. A binding resource (or binding) MUST have an oslc_rm:bound property which references the bound resource.

Note: A binding can refer to itself (the binding resource and the bound resource can be the same resource).

A module MAY have an oslc_rm:structure resource which MUST be an LDPC. The structure resource is a non-member resource of the LDPC which links binding resources into an application-defined structure. Common structures include n-ary trees, ordered n-ary trees, ordered lists and unordered lists. (TODO: should we use unordered lists to unify requirementcollection?)

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.

Note: This spec does not place additonal requirements on access to non-member resource of a Module.

A server should define the structure resources it uses (HOW WOULD IT DO THIS?). This specification (OR IS IT A PROFILE?) defines vocabulary terms for ordered n-ary trees.

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

@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 rdf:subject :r3;
     u:order "3";
     oslc_rm:parent :s11.
:s1 rdfs:member <>.

:av1 a ldp:Container, oslc_rm:AppliedView;
    oslc_rm:structure :avs1;
    rdfs:member :r1, :b2, :r3;
    oslc_rm:isAppliedViewOf :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 <>.

Applied Views

An applied view is a LDPC whose content is a subset of the members of the corresponding module content LDPC. (The membership difference being those members which are filtered out of the applied view.) The applied view MAY have an oslc_rm:structure resource to describe ordering of the bindings in the applied view.

??? Servers MAY use an oslc_rm:AppliedView to indicate that the Module resource is an applied view, and the properties oslc_rm:isAppliedViewOf to indicate what resource this is a view of, and oslc_rm:relatedView to indicate which view defines this applied view.

Structure in the applied view may be entirely unrelated to the structure of the module 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.

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.