Use consistent terminology in ontology and frontend

[epatters]

After much discussion, we've decided to adopt PLT-style terminology (types, functions, etc.) instead of category-theoretic terminology (objects, morphisms, etc.) for the ontology. This choice is already reflected in the frontend, but not in the ontology data itself. That may seem a small matter but it creates a non-negligble barrier for new contributors.

To fix this, we need to update:

• the JSON schemas for concepts and annotations
• the concepts and annotations themselves
• the downstream tools that consume the ontology

[epatters]

I'm going to do this in two steps:

1. Update the JSON schemas for concept and annotations, and all downstream tools
2. Update the S-expressions themselves, and all downstream tools

[ioana-blue]

Sounds good. Clarifying question: what's S-expression?

[epatters]

By "S-expression" I mean the definitions appearing in function annotations, e.g., in read-sql-table

[
  compose,
  [ construct, [ pair, sql-table-database, sql-table-name ] ],
  read-table
]

So instead of pair, this will say apply, etc.

[epatters]

Step 1 is finished!

[epatters]

Step 2 is finished. We're done here.