Jra ldm review

.gitignore

@@ -1,3 +1,5 @@
 *~
 .DS_Store
 /.venv
+/.vscode
+.vscode/settings.json

.vscode/settings.json

@@ -1,4 +1,5 @@
 {
     "editor.rulers": [120],
-    "html.format.wrapLineLength": 120
+    "html.format.wrapLineLength": 120,
+    "java.compile.nullAnalysis.mode": "automatic"
 }

specs/config/config-resources.html

@@ -146,8 +146,7 @@
           CORS: {
             title: "Fetch standard",
             authors: ["WHATWG contributors"],
-            href:
-              "https://fetch.spec.whatwg.org/commit-snapshots/d070ea245c6eb66cf4196324f063dc6ab608d9e6/#http-cors-protocol",
+            href: "https://fetch.spec.whatwg.org/commit-snapshots/d070ea245c6eb66cf4196324f063dc6ab608d9e6/#http-cors-protocol",
             status: "Living Standard",
             publisher: "WHATWG",
           },
@@ -461,9 +460,7 @@ <h2>Supported Operations on Components</h2>
         A configuration server SHOULD support, and a global configuration server MUST support one or more component
         creation factories declared in one or more OSLC service providers.
       </p>
-      <p class="conformance">
-        A configuration server SHOULD support one or more query capabilities for components.
-      </p>
+      <p class="conformance">A configuration server SHOULD support one or more query capabilities for components.</p>
     </section>
     <section id="configoperations">
       <h2>Supported Operations on Configurations</h2>
@@ -586,9 +583,7 @@ <h2>Supported Operations on Change Set Delivery</h2>
       </p>
       <section id="creationfactorydelivery">
         <h2>Delivering change sets using a creation factory</h2>
-        <p>
-          There are several key aspects of change set delivery that OSLC Configuration Management should support:
-        </p>
+        <p>There are several key aspects of change set delivery that OSLC Configuration Management should support:</p>
         <ol>
           <li>Delivery is atomic. Either all the changed/new/removed resources are delivered, or none are.</li>
           <li>A delivery might be a long-running operation.</li>
@@ -659,9 +654,7 @@ <h2>Delivery Conflicts</h2>
       </section>
       <section id="deliveryhistory">
         <h2>Change Set Delivery History</h2>
-        <p>
-          There are several common uses cases for finding information about change set deliveries:
-        </p>
+        <p>There are several common uses cases for finding information about change set deliveries:</p>
         <ul>
           <li>When was a specified change set delivered to a specified stream, and by whom?</li>
           <li>Which streams has a specified change set been delivered to?</li>

specs/config/oslc-config-mgt.html

@@ -494,7 +494,7 @@ <h2>Acknowledgements</h2>
         The following individuals have participated in the creation of this specification and are gratefully
         acknowledged:
       </p>
-      <p style="margin-left: 40px;">
+      <p style="margin-left: 40px">
         David Honey (Persistent)<br />
         Ian Green (Persistent)<br />
         Geoff Clemm (Persistent)<br />

specs/config/versioned-resources.html

@@ -229,9 +229,9 @@ <h2>Delegated UIs</h2>
     <section id="vcompact">
       <h2>Compact Rendering</h2>
       <p class="conformance">
-        A versioned resource server SHOULD implement compact rendering (resource preview), both for concept resources and version
-        resources. See <a href="config-resources.html#compact">Compact Rendering</a> for the handling of configuration
-        context in such rendering.
+        A versioned resource server SHOULD implement compact rendering (resource preview), both for concept resources
+        and version resources. See <a href="config-resources.html#compact">Compact Rendering</a> for the handling of
+        configuration context in such rendering.
       </p>
     </section>
     <section id="vtrs">

specs/ldm/link-discovery-management-spec.html

@@ -55,10 +55,6 @@
 
         // Other parts of multi-part spec
         additionalArtifacts: [
-          {
-            title: "OSLC Link Discovery Management Version 1.0. Part 1: Specification",
-            href: thisBase + "/link-discovery-management-spec.html",
-          },
           {
             title: "OSLC LDM Version 1.0: Part 2: Machine-readable OpenAPI yaml",
             href: thisBase + "/ldm-service.yaml",
@@ -231,8 +227,8 @@
   <body>
     <section id="abstract">
       <p>
-        OSLC Link Discovery Management service defines an OSLC RESTful web services API for the discovering incoming
-        links to a set of possibly versioned resources. To support these scenarios, this specification defines a set of
+        OSLC Link Discovery Management service defines an OSLC RESTful web services API for the discovering incoming and outgoing
+        links to a set of optionally versioned resources. To support these scenarios, this specification defines a set of
         HTTP-based RESTful interfaces in terms of HTTP methods: GET, POST, PUT and DELETE, as well as HTTP response
         codes, content type handling and resource formats.
       </p>
@@ -247,12 +243,13 @@ <h2>Introduction</h2>
       <p>
         OSLC specifications do not currently specify where links between resources are stored, or which server owns
         which links. OSLC specifications also do not address which links are stored for properties that might be
-        considered inverses such as implements or implementedBy. Some implementations may choose to store both of these
-        links, other implementations may store one link and use OSLC Query or other mechanisms to get incoming links.
+        considered inverses such as implements and implementedBy. Some implementations may choose to store both of these
+        links, other implementations may store typically the outgoing link and use OSLC Query or other mechanisms to get incoming links.
       </p>
       <p>
         With the introduction of OSLC Configuration Management, the simple technique of storing redundant backlinks
-        becomes problematic for maintaining data consistency and is not recommended. Project Note <a href="https://docs.oasis-open-projects.org/oslc-op/link-guidance/v1.0/link-guidance.html">
+        becomes problematic for maintaining data consistency and is not recommended. Project Note 
+        <a href="https://docs.oasis-open-projects.org/oslc-op/link-guidance/v1.0/link-guidance.html">
         OSLC Link Guidance</a> recommends storing
         the link on only one side and using some mechanism to query incoming links from the other direction. One
         approach in common practice is to use OSLC query where a client queries each of its related servers for incoming
@@ -269,24 +266,24 @@ <h2>Introduction</h2>
       </p>
       <p>
         OSLC link Discovery Management is an OSLC specification that defines a standard means for client applications to
-        discover incoming links to resources. This specification follows existing practices for incoming links discovery
+        discover incoming and optionally outgoing links to/from resources. This specification follows existing practices for incoming links discovery
         and specifies the following services:
       </p>
       <ul>
         <li>
-          How to inquire incoming links to versioned resources for a provided set of concept resource URIs
-          and a given configuration context
+          How to inquire incoming and optionnally outgoing links to resources for a provided set of resource URIs.
         </li>
         <li>
-          Incoming links service providers operate in configuration enabled contexts. Therefore, the incoming link
-          inquiries specify configuration contexts for the links
+          Incoming links service providers may operate in configuration enabled contexts, returning incoming and outgoing
+          as concept URIs resolved to versions using a Configuration-Context.
         </li>
         <li>A means of discovering service providers that contribute links to an LDM server.</li>
       </ul>
       <p>
-        The specification does not specify how link discovery services ingest data from the various lifecycle providers,
-        in order to effectively support the inquiries. That said, a common way of ingesting and maintaining a link index
-        to support the inquiries uses already standardized OSLC Tracked Resource Sets [[OSLCTRS]]
+        A common way of ingesting and maintaining a link index
+        to support the inquiries uses already standardized OSLC Tracked Resource Sets [[OSLCTRS]]. However, this specification 
+        does not specify how link discovery services ingest data from the various lifecycle providers,
+        to support the link discovery services. LDM Server implementations may use any means for populating their required content. 
       </p>
       <p>
         This specification is a [[!OSLCCore3]] compliant specification, and as such most of its content are references
@@ -299,7 +296,26 @@ <h3>Terminology</h3>
           <dt><dfn>Link</dfn></dt>
           <dd>
             An assertion or RDF triple consisting of a (subject, predicate, object) that manifests an instance of a
-            relationship between the referenced subject and object OSLC resources.
+            relationship between the referenced subject and object OSLC resources. The subject in the triple is often 
+            referred to as the source resource of the Link. The object in the triple if often referred to as the target 
+            resource of the Link. 
+          </dd>
+
+          <dt><dfn>Link Type</dfn></dt>
+          <dd>
+            The predicate or RDF property of a Link.
+          </dd>
+
+          <dt><dfn>Incoming Links</dfn></dt>
+          <dd>
+            All Links matching set of Link predicates and target (object) resources, i.e., (?, predicate, object)
+            triples, the links where the given resources are objects of the predicates.
+          </dd>
+
+          <dt><dfn>Outgoing Links</dfn></dt>
+          <dd>
+            All Links matching a given set of source (subject) resources and Link predicates, i.e., (subject, predict, ?)
+            triples, the links where the given resources are subjects of the predicates.
           </dd>
 
           <dt>LDM Client</dt>