In the last post we saw several means of organizing data, namely templates, subsumption, and examplification. However, those means could be made more effective if there was more direction on how they operate.
For instance, examplify() should be able to feed a record without having to repeat type names explicitly, but we didn’t choose the solution of passing only ordered and separated values, and examplify() requires to repeat each column name as in make_full_record(). There’s a reason for this behaviour that is called non-coercion : we want the user to be able to subsume a record without having to match any predefined scheme; if examplify() was to populate its subdb according to the template only, our model would become coercive, and anomalous data would be excluded. In knowledge acquisition though, membership in a set isn’t always specified. Sometimes we know there is a set of similar objects without being able yet to declare which ones of their properties are essential, nor which ones are shared by all of them. Moreover, the answer to such questions may be the reason why a database was created in the first place. A non-coercive scheme is a help in making a database durable, even if it implies more typing…
Another question arises from the use of templatize() and get_subject() : in the absence of an existing subdatabase, get_subject() will create it but not the record the user wanted to subsume. This decision has a sense too : for it depends on the database policy to decide wether a subdatabase should have an empty template or not. The template being a record in the subdb, Unidatab took the option of having a meaningful template – properties are fed or copied as well as types at subdb creation – but in many occasions the record’s title acts as an identifier, and in such cases, templates with properties do not spare a first record after their creation.
In future releases, Unidatab will offer coercive alternatives to some functions. For example we’ll be able to pass a list of values to examplify() and the function will understand that in the absence of ‘:unid-protyp-sep:’ (the property/type separator), these values are to be parsed as an ordered list matching the record’s content in terms of types. Nevertheless, non-coercion will be kept as a guiding rule in functional syntax, taken for granted that it is always nicer to discover new tools free, than being trapped later with overstrict models of interpretation and data acquisition.