additional changes to UC&R use cases
authorsteve.battle <steve.battle@sysemia.co.uk>
Mon, 08 Jul 2013 14:56:26 +0100
changeset 157 3117cd615572
parent 156 9dafe5f2b2e8
child 159 e098f668a10d
child 162 81335e7cf887
additional changes to UC&R use cases
ldp-ucr.html
--- a/ldp-ucr.html	Mon Jul 08 14:42:48 2013 +0100
+++ b/ldp-ucr.html	Mon Jul 08 14:56:26 2013 +0100
@@ -806,8 +806,8 @@
 			System and Software Development Tool Integration</a> user story. The
 		OSLC Change Management vocabulary allows bug reports to have
 		attachments referenced by the membership predicate
-		<code>oslc_cm:attachment</code>. The 'top-level-container' contains issues, and
-		each issue resource has its own container of attachment resources.
+		<code>oslc_cm:attachment</code>. This may be viewed as nested containment. The 'top-level-container' contains issues, and
+		each issue is itself a container of attachments.
 	</p>
 	<pre class='example'>
 @prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@@ -820,11 +820,7 @@
 :issue1234 a oslc_cm:ChangeRequest;
       dcterms:identifier &quot;1234&quot;;
       dcterms:type &quot;a bug&quot;;
-      dcterms:related :issue1235 ;
-      oslc_cm:attachments :attachments123.
-
-:issue1235 a oslc_cm:ChangeRequest;
-      dcterms:title &quot;a related bug&quot;.
+      oslc_cm:attachments :attachments.
 
 :attachments a oslc_cm:AttachmentList;
       oslc_cm:attachment :attachment324, :attachment251.
@@ -837,7 +833,7 @@
 	<p>
 		This use case addresses the managed lifecycle of a resource and is
 		concerned with resource <i>ownership</i>. The responsibility for
-		managing resources belongs with their container. For example, a
+		managing resources belongs to their container. For example, a
 		container may accept a request from a client to make a new
 		resource. This use case focuses on creation and deletion of
 		resources in the context of a container, and the potential for
@@ -846,19 +842,6 @@
 		managed in this way should ever be owned by more than one
 		container.
 	</p>
-	<p>
-		Once a new resource has been created it should be identified by a
-		URI. Clients may defer responsibility for establishing
-		dereferenceable URIs to the container of their data. The container
-		is a natural choice for the endpoint for this interface as it will
-		already have some application-specific knowledge about the
-		contained resources. While the server has ultimate control over
-		resource naming, some applications may require more control over
-		naming, perhaps to provide a more human-readable URI. An LDP
-		server could support something like the Atom
-			Publishing Protocol slug header to convey a user defined naming
-		'hint' [[RFC5023]].
-	</p>
 	<ul>
 		<li>Non-duplication of resources: "Eliminate multiple
 			copies", representing resources in a single place (from <a