Explain Pine's SBVR in docs/SBVR.md

[Ereski]

• Explain SBVR as understood by Pine in more programmer-friendly
  terms
• Map out how Pine interprets SBVR's structured english

[dfunckt]

For this document to stand on its own, I think it helps to provide an introductory paragraph and a tiny working example of an SBVR model that readers can carry in their minds as they read through the document. It could start as follows:

*SBVR* stands for "Semantics of Business Vocabulary and Business Rules" and
provides a way to capture specifications in natural language and represent
them in formal logic, so they can be machine processed. This document describes
how Pine understands SBVR. You can use the [sbvr lab](http://www.sbvr.co/) as a
companion to this document. For the deep dive, check out the [SBVR spec](http://www.omg.org/spec/SBVR/).

Here is an example model expressed in SBVR:

<a minimal pilot model>

[nazrhom]

This could be expanded a bit here: in what sense is a term a type?

[Ereski]

Here's the explanation I put:

Terms are types: they represent a collection of instances that obey an uniform "interface" defined through fact types and rules.

[nazrhom]

What implication does this have? Can this attribute only be applied to Terms?

[nazrhom]

This is interesting, never fully understood how we differentiate between the two. Can we add an example of a deontic rule here? Also, we should explicitly mention the runtime cost that is associated with the two: as the first comes for "free" since they are enforced by the DB, but we have to explicitly check for other rules after an insert/update. What happens in practice if a deontic rule is violated?

[Ereski]

Within SBVR, the difference is about what to expect: violations of alethic rules are not expected at all, while violations of deontic rules are not desired but possible. As far as the database is concerned, the difference is how you get an error: either the DB refuses to work (alethic, can't do anything about that unless you change the schema behind Pine's back) or a a validation check fails (deontic, user-driver check that can be ignored). I haven't gone down the code path dealing with validation checks though.

It's hard to talk about runtime costs and the alethic/deontic split in practice because it depends on the DB, the Pine version, and how you phrase your constraint. The basic gist seems to be that if Pine sees an opportunity to encode a constraint into the schema, it takes it. Everything else is put into validation checks.

But regardless, SBVR modalities are completely irrelevant in practice. You could scrap them without losing functionality (even impossible is treated as necessary), so I don't think it makes much sense to delve into that.