#456 Handling of Primitive Concepts

[Rieks]

'Primitive concepts' are concepts for 'primitive types'. Examples are 'TEXT', 'BLOB', 'INTEGER', 'DATE', 'EMAIL' etc. There does not seem to be a need to have an atom table for such primitive types, and for certain there are no 'wide tables' that have such atoms as a key. Therefore, we can do without tables for primitive types. This saves a considerable amount of database queries in cases where many atoms of primitive concepts are used. This would speed up transaction handling in cases where such primitive types are used.

Note that primitive concepts are currently introduced already, because the (new) frontend needs to know them because they need to be treated specifically in the frontend.

[Michiel_s]

In the discussion in ticket #452 Martijn states the difference between the support for primitive concepts (in Ampersand) and the presentation of these primitive concepts in HTML. What do you think of the following approach:

1. We define primitive datatypes in Ampersand with the capitalized keywords STRING, BOOL, DATE, etc. I suggest that we adapt to the XML primitive datatypes that are commonly used for information exchange and also adapt their names? See http://www.w3.org/TR/xmlschema-2/#built-in-primitive-datatypes
2. Let's start with the string (3.2.1), boolean (3.2.2), decimal (3.2.3) and dateTime (3.2.7)
3. In ampersand we can build in support for computations on these datatypes
4. And for these primitive datatypes we define default templates (as we already did)
5. If we need specialized representations (e.g. not a checkbox for a BOOL, but a switch or a textual string) we can use the ISA functionality in ampersand and specify 'Switch ISA BOOL' and define the template Atomic-Switch.html
6. I strongly recommend to adapt the naming of the primitive datatypes to the W3 Consortium specification, because I foresee that we are going to relate to other Semantic technologies (like OWL ontologies, RDF data, etc) in the very near future. I think that the currently used TEXT and BLOB types have it origin in the MYSQL datatypes. Isn't it? It would be far more easier if our datatypes already line up with the datatypes as used in the semantic world. We then have to change:
7. TEXT into STRING
8. DATE into DATETIME
9. BOOL into BOOLEAN
10. introduce DECIMAL
11. downgrade BLOB to specialization of STRING -> Blob ISA STRING
12. downgrade PASSWORD to specialization of STRING -> Password ISA STRING

Let me know what you think of the above.

[Martijn Schrage]

There's basically three issues being discussed here: the names of our primitives, how they are handled at the database level, and how we specify their presentation.

About the names, I think BOOL is much better than BOOLEAN, but I'm not a fan in general of W3C's overly verbose standards. Then again, I don't know much about frameworks we might communicate with, and how much it would benefit to have exactly the same primitives.

I'm also not a fan of shouting primitive concepts in capitals. Since the 1980's, most programming languages moved away from capitalized primitive types. People have no problems understanding that some concepts/types are primitive, even when not reminded by capitalization. Also, since in Ampersand you can declare non-primitive concepts with capitalized names, a capitalized name would not even guarantee a primitive type. Is there a strong reason to enforce these capitals? Simply using String, Date, etc. will also maintain a visual distinction between concepts and Ampersand keywords.

Having a special treatment for primitive concepts at the database level sounds like a good idea. I believe something like this is currently happening for blobs, although it may not have been implemented completely.

Concerning the presentation, if we use the target concept for this, the presentation of a context will be encoded in the model, which is not a good idea. We could work around this by composing with an appropriate I in the interface. For example, if we have a function isAccepted[Order*Bool] which is to presented as a switch, we could write

INTERFACE ..
  BOX [ "Order is accepted": isAccepted;I[Switch] 
      ]

However, in this case Switch needs to be a generalization of Bool, rather than the other way round. It will work, but it is not a very elegant solution.

Another issue with using the target concept to select the template is that it inconsistent with the situation for boxes, for which we use the class. Also, we may want to have specialized presentations also for non-primitive concepts, which points us in the direction of views. (Simply using the target concept to select a template will not suffice, since we will also need to specify some relations to present the raw atom ids)

I have a couple of ideas about integrating the VIEW mechanism with the new front-end templates, for which I will create a GitHub issue.