discuss comparison of SEP 19 vs. 20 UML

sep_020.md

@@ -162,11 +162,11 @@ The first example covers the, presumably, most common use case of transmitting i
 
 ![Batch of plasmid DNA](images/sep_020_plasmid.png "Representation of one particular batch of plasmid DNA.")
 
-**Example 1a:** This example covers the, presumably, most common use case of transmitting information about one particular plasmid which may be shipped between labs or obtained from the iGEM registry or AddGene. Two scenarios are shown. Above the, by far, most common use case where the plasmid corresponds exactly to the given design. Below, a scenario as it may, for example, happen in intermediate stages of assembly processes, where a plasmid is tracked and found to not exactly correspond to its design.
+**Example 1a:** This example covers the, presumably, most common use case of transmitting information about one particular plasmid which may be shipped between labs or obtained from the iGEM registry or AddGene. Two scenarios are shown. Top: the by far, most common use case where the plasmid corresponds exactly to the given design. Bottom: a scenario as it may, for example, happen in intermediate stages of assembly processes, where a plasmid is tracked and found to not exactly correspond to its design.
 
 It is instructive to compare the above example to exactly the same information expressed according to SEP 19. Most UML diagrams in SEP 19 are highly simplified. So here is the same example with everything spelled out according to SEP 19 and the current prov-O documentation:
 
-![SEP 19 plasmid DNA](images/sep_019_plasmid.png "Representation of one particular batch of plasmid DNA **according to SEP 19**.")
+![SEP 19 plasmid DNA](images/sep_019_plasmid.png "Representation of one particular batch of plasmid DNA **according to SEP 19**.")<a name='sep19_example'></a>
 
 **SEP 19 Example**: The exact same data as in Example 1a shown in the notation suggested by SEP 19. Note that the same information expressed by a single `design` field in SEP 20, requires, in SEP 19, 6 prov-O fields, 2 prov-O class instances, and one novel sbol:"design" term. 
 
@@ -184,7 +184,7 @@ Note: SBOL currently has no clear rule for the identification of organisms. Pres
 
 Competing SEP 19 is putting all emphasis on documenting an idealized design - build - test workflow. I am skeptical as to how realistic this is at this point. For example, automated model building or automated sequence design from models is still the exception. In my experience, models are (if at all) built after a design has been made. I therefore find it problematic to connect Experimental Results -> Implementation, Implementation -> Design and Design -> Model with `prov:wasDerivedFrom` links as suggested in SEP 19. In 95% of use cases, this will be confusing or outright false. Moreover, SBOL *already* specifies proper fields for connecting Design and Model as well as Attachment. 
 
-The following is therefore the *minimal* representation of the actual result of a design - build - test workflow:
+The following is therefore, according to this proposal, the *minimal* representation of the actual result of a design - build - test workflow:
 
 ![Minimal workflow representation](images/sep_020_designbuildtest_min.png "Minimal workflow representation")
 
@@ -235,12 +235,17 @@ SEP 19 relies heavily on prov-O providence ontology terms which are freely mixed
 
 Key differences are:
 
- * no (redundant) `wasDerivedFrom` links between `Implementation` and `ComponentDefinition`
+ * No (redundant) `wasDerivedFrom` links between `Implementation` and `ComponentDefinition`
 
  * Instead, SEP 20 defines a direct and mandatory field `design`
 
- * all use of providence ontology terms and constructs is optional
+ * All use of providence ontology terms and constructs is optional
 
+ * Massive reduction of prov-O overhead and reference redundancy
+
+In SEP 19, the expression of the design link via a prov-O `Activity` comprises a massive overhead of, in many cases redundant, fields and classes (9 interlinked entities, likely translating to 20 to 40 lines of XML code) only so that additional meta information *could* theoretically be added on top of that. SEP 20 replaces this by a single pointer. This will be sufficient for most use cases. If, and only if, additional meta information is required, prov-O `Activities` can still be layered on top of that.
+
+The high number of redundant references in the SEP 19 prov-O model (see [the Figure](#sep19_example) in Example 1 above) also requires a very high number of new validation rules that verify that two different but equivalent prov-O pointers indeed reference the same `Implementation` or `ComponentDefinition` object. Realistically, we have to assume SBOL documents will not always meet all validation rules. SEP 19 therefore creates an abundance of possibilities for serious bugs where software tools receive conflicting references. 
 
 
 ### 5.2 Conflicts with versioning <a name='versioning'></a>