This is the simplest way for a requirement to be linked to some other resource.

<oslc_rm:Requirement rdf:about="urn:req1">
 <dc:title>req1</dc:title>
 <oslc:implementedBy rdf:resource="urn:workitem1" />
</oslc_rm:Requirement>

(2) Link with properties

This is an extension of case (1) above: the only addition is the use of rdf:ID on the link, and then an RDF node describing that link:

<oslc_rm:Requirement rdf:about="urn:req1">
 <dc:title>req1</dc:title>
  <oslc:implementedBy rdf:ID="linkreqperspective" rdf:resource="urn:workitem1" />
  <rdf:Description about="#linkreqperspective">
   <dc:creator>Ian Green</dc:creator>
  </rdf:Description>
</oslc_rm:Requirement>

The design illustrated in (1) and (2) is sufficiently expressive for most applications. It is reasonable to assume that a client reading (1) could also read (2) but ignore the additional link properties.

(2b, variant of 2) Link with properties and identity

<oslc_rm:Requirement rdf:about="urn:req1">
 <dc:title>req1</dc:title>
 <oslc:implementedBy rdf:ID="linkreqperspective" rdf:resource="urn:workitem1" />
 <rdf:Description about="#linkreqperspective">
  <dc:isPartOf rdf:resource="urn:of_the_link"/>
  <dc:creator>Ian Green</dc:creator>
 </rdf:Description>
</oslc_rm:Requirement>

This is the same as (2) but addresses a need to identify a link.

In both (1) and (2) the resource is considered to change when links are added and removed.

In (2) clients may find it hard to add or remove a link because the XML structure is slightly complicated. Removing a link requires that the client remove both the link, and any of its properties. A client may want to remove only the properties of that link.

In (1) and (2) the link, since it is inline in the requirement would affect the ETag of the requirement.

Problem P1: In (1) and (2) it is hard to see what would happen if an application wanted to separate security on requirements and links - for example, what would happen if the requirement were readable and one of its links were not. The server would have to understand on PUT that a "missing" link was not being deleted, for example. It would also have to calculate ETags after security had been applied.

DOORS security model allows different security on links and requirements. I don't see then that (1) and (2) are good designs in this case.

Problem P2: In applications with different process on requirements and links, adding a link would require modification of the requirement. This design places constraints on the processes governing requirements and links. A server would have to understand that a PUT on a requirement was only changing the links part.

DOORS today does not support this use case, but we have customers that have argued that it should. (1) and (2) are not suitable in this case.

Problem P3: The link does not have an identity. Use case: 2D drawing of the links between resource (would struggle to draw a single line rather than two lines). Design 2b addresses this to some degree by introducting a dc:isPartOf to indicate that the link properties in the requirement are part of some other resource with the supplied URI.

The problem with PUT to update elements beloning to more than one security or process context.