Fixes to member extraction

specs/0-introduction.md

@@ -103,9 +103,10 @@ A View is a specific set of interlinked <code>tree:Node</code>s, that together c
 
 A <code>tree:search</code> form is an IRI template, that when filled out with the right parameters becomes a <code>tree:Node</code> IRI, or when dereferenced will redirect to a <code>tree:Node</code> from which all members in the collection that adhere to the described comparator can be found.
 
-# The member extraction algorithm # {#member-extraction-algorithm}
+## The member extraction algorithm ## {#member-extraction-algorithm}
 
-TREE uses the [shape templates algorithm](https://w3id.org/tree/specification/shape-templates) to define the set of quads that are part of their members.
-It uses the `sh:NodeShape` from the `tree:shape` property on the collection 
+The set of quads the are part of the member, are defined by the [shape templates algorithm](https://w3id.org/tree/specification/shape-templates), provided as a separate report to this specification.
+It is a combination of Concise Bounded Descriptions, named graphs and Shape Templates.
+The latter uses the <code>sh:NodeShape</code> from the <code>tree:shape</code> property on the collections as an indication of the topology of the member graph.
 
 Note: The way we process SHACL shapes into Shape Template is important to understand in order to know when an HTTP request will be triggered when designing SHACL shapes. A cardinality constraint not being exactly matched or a <code>sh:pattern</code> not being respected will not trigger an HTTP request, and instead just add the invalid quads to the Member. This is a design choice: we only define triggers for HTTP request from the SHACL shape to come to a complete set of quads describing the member the data publisher pointed at using <code>tree:member</code>.