This specification defines a vocabulary and resource shapes for the OSLC Requirements Management domain.
This specification defines a vocabulary and resource shapes for the OSLC Requirements Management resources. The intent is to define resources needed to support common integration scenarios and not to provide a comprehensive definition of a Requirement. The resource formats may not match exactly the native models supported by requirement management service providers, but are intended to be compatible with them. The approach to supporting these scenarios is to delegate operations, as driven by service provider contributed user interfaces, as much as possible and not require a service provider to expose its complete data model and application logic.
Terminology is based on OSLC Core Overview [[!OSLCCore3]], W3C Linked Data Platform [[!LDP]], W3C's Architecture of the World Wide Web [[WEBARCH]], Hyper-text Transfer Protocol [[!HTTP11]]. Terminology for this specification is defined in part 1 of the multi-part specification.
In addition to the namespace URIs and namespace prefixes oslc
, rdf
, dcterms
and foaf
defined in the OSLC Core specification, OSLC RM defines the namespace URI of http://open-services.net/ns/rm#
with a namespace prefix of oslc_rm
This specification defines the root superclasses, properties and values. Servers may define additional subclasses and provide additional properties as needed.
The constraints on the Requirement resource properties are defined in the tables below. Requirement resource properties are not limited to the ones defined in this specification. Service providers may provide additional properties. It is strongly recommended that any additional properties be defined in XML namespaces distinct from those defined by OSLC in these specifications. Requirement creation through a Creation Factory resource in the Service Description is REQUIRED by this specification.
Any resource asserted to be of rdf:type
http://open-services.net/ns/rm#Requirement
MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a requirement resource are admitted by this specification (for example, in query results, or where oslc.properties
has been used), and such partial representations will in general not conform to these constraints.
The constraints on the RequirementCollection vocaubluary resource properties are defined in the tables below. RequirementCollection resource properties are not limited to the ones defined in this specification, service providers may provide additional properties. It is strongly recommended that any additional properties be defined in XML namespaces distinct from those defined by OSLC in these specifications. RequirementCollection creation through a Creation Factory resource in the Service Description is OPTIONAL in this specification.
Any resource asserted to be of rdf:type
http://open-services.net/ns/rm#RequirementCollection
MUST conform to the constraints and meaning of properties defined below. Notice that partial representations of a requirement collection resource are admitted by this specification (for example, in query results, or where oslc.properties
has been used), and such partial representations will in general not conform to these constraints.
For compatibility with OSLC Core 2.0 [[!OSLCCore2]], RM servers MAY accept relationship properties. This is however no longer recommended practice, since the necessary reification of relationship can have entailment and inferencing issues. OSLC Core 3.0 Link Guidance [[!OSLCCore3LinkGuidance]] details an alternative approach, where a separate resource is created to represent the relationship and its properties.
The following relationship properties are defined by this specification:
Prefixed Name | Occurs | Read-only | Value-type | Representation | Range | Description | |
---|---|---|---|---|---|---|---|
dcterms:title |
zero-or-one | unspecified | XMLLiteral | n/a | n/a | Title (reference: Dublin Core) of the link represented as rich text in XHTML content. SHOULD include only content that is valid inside an XHTML <span> element. | |
dcterms:creator |
zero-or-many | unspecified | Resource or Local Resource | Either Reference or Inline | any |
Creator(s) of resource (reference: Dublin Core). It is likely that the target resource will be a foaf:Person but that is not necessarily the case. |
|
dcterms:contributor |
zero-or-many | unspecified | Resource or Local Resource | Either Reference or Inline | any |
Creator(s) of resource (reference: Dublin Core). It is likely that the target resource will be a foaf:Person but that is not necessarily the case. |
|
dcterms:created |
zero-or-one | True | DateTime | n/a | n/a | Timestamp of link creation (reference: Dublin Core). | |
dcterms:modified |
zero-or-one | True | DateTime | n/a | n/a | Timestamp last latest link modification (reference: Dublin Core). |
When an RM relationship property is to be presented in a user interface, it may be helpful to provide an informative and useful textual label for that relationship instance. (This in addition to the relationship property URI and the object resource URI, which are also candidates for presentation to a user.) To this end, OSLC Servers MAY suppport a dcterms:title
link property in RM resource representations where a relationship property is permitted, using the anchor approach outlined in the OSLC Core Links Guidance.
Servers and Clients should be aware that the dcterms:title
of a link is unrelated to the dcterms:title of the object resource. Indeed, links may carry other properties with names in common to the object of the link, but there is no specified relationship between these property values.
Revision | Date | Editor | Changes Made |
01 | 2018-08-24 | Jad El-khoury | Committee Specification 01 Published |