DOC: amendments to future_caosdb.md

src/doc/future_caosdb.md

@@ -70,21 +70,78 @@ Analogue, to what Pandas does. Provide bracket notation
 default attributes or contain spaces (or other forbidden characters).
 
 - Raise Exception if attribute does not exist but is accessed?
-- How to deal with lists? b has a list as value: `a.b[0].c = 5`
 
 [Discussion](https://gitlab.com/caosdb/caosdb-pylib/-/issues/60)
 
+We aim for a distinction between "concrete" Properties of Records/RecordTypes and "abstract" Properties as part of the definition of a data model. Concrete properties are always "contained" in a record or record type while abstract properties stand for themselves.
+
+Draft:
+```
+class ConcreteProperty:
+  def __init__(self, v, u):
+    self.value = v
+    self.unit = u
+    
+class Entity:
+  def __init__(self):
+    pass
+    
+  def __setattr__(self, name, val):
+    if name not in dir(self):
+        # setattr(self, name, ConcreteProperty(val, None))
+        self.properties[name] = ConcreteProperty(val, None)
+    else:
+        # getattribute(self, name).value = val
+        self.properties[name].value = val
+```
+
+The old "get_property" functions serves the same purpose as the new "[]" notation.
+
+Instead of `get_property` / `add_property` etc. functions belonging to class Entity, we should refactor the list of properties (of an entity) to be a special kind of list, e.g. PropertyList.
+This list should enherit from a standard list, have all the known functions like "append", "extend", "__in__" and allow for all property-related functionality as part of its member functions (instead of access via Entity directly).
+Same story for the parents.
+
+**GET RID OF MULTI PROPERTIES!!!**
+
+#### how to deal with "property metadata"
+
+Current suggestion: stored in a special field "property_metadata" belonging to the object.
+`property_metadata` is a dict:
+- importance
+- unit
+- description
+- ...
+
 ### Serialization
 What information needs to be contained in (meta)data? How compatible is it with 
 GRPC json serialization?
 
 
 ### Recursive Retrieval
+
+
+
 I can resolve later and end up with the same result:
 `recs =db.query("FIND Experiment", depth=2)`  equals `recs = db.query("FIND Experiment"); recs = resolve_references(recs, depth=2)`
 
 [Discussion](https://gitlab.com/caosdb/caosdb-pylib/-/issues/57)
 
+
+#### Alternative
+
+`FIND Experiment` with `depth=2` will retrieve all referenced entities from any experiment found. A typical use case could also be:
+
+```python
+recs = db.query("FIND Experiment")
+recs[0].resolve_references(depth=2)
+```
+
+#### Idea
+
+Recursive retrievel as functionality of the server.
+
+retrieve and query commands should support the `depth` argument.
+
 ### In-Place operations
 Default behavior is to return new objects instead of modifying them in-place.
 This can be changed with the argument `inplace=True`.
@@ -95,7 +152,7 @@ Especially the following functions operate by default NOT in-place:
 - resolve_references
 [Discussion](https://gitlab.com/caosdb/caosdb-pylib/-/issues/61)
 
-## Extend Example
+## Extended Example
 ``` python
 import caosdb as db
 
@@ -110,3 +167,14 @@ new_one.dataset.pulses = [5, 5.3]
 inserted = new_one.insert()
 print("The new record has the ID:", inserted.id)
 ```
+
+
+### References and sub entities
+
+Several possibilities exist for references:
+
+- value is the id of a referenced entity
+- value is a "sub object"
+- value is a reference to another (entity-)list element (similar to second variant, but with "sub object" always contained in container/entity-list)
+
+To be discussed: Which should be the obligatory/preferred variant?