Note that the MyLittleDatabaseImplementation of panSL also uses the concepts Login and Message in order to log
log-in events and sending of messages. These are however automatically assumed, and not part of panSL at the moment.

AccessRole may also be specified as Role + PropertyID. In this case the user of an ApplicationImplementation needs to either
A) impersonate the given Property, or to
B) have a relationsship to it (for instance the Property could be a group "Account_department" with users as members)

It is not possible to log-in as a Family. Therefore Person-entities related to a given Family is given Role as Owner.
This makes it possible for a Person to edit his own Family.
(In this example log-in is performed by requesting a one-time password as SMS-message to a given mobil-phone number.)

Example B), giving a Person-entity role as Administrator (of the whole database):

By creating an Administrator_group and relating it to a Person-entity the Person-entity would be granted Administrator-rights after log-in.
(In this example log-in is performed in the traditional manner by Username and Password.)

Not every SubName needs to be specified. If a particular SubName within the PropertyName is not given
the name of its closest "right-hand neighbour" is used instead. As a minimum the IdentificatorName must be specified.
In other words, a SubName propagate from right to left until a new SubName is specified.

If for instance ER-modelling is not desired or important, the example above could have been written as:

The object-oriented style is usually preferred when functions are arguments to new functions (that is when you are nesting functions within functions).
For instance, Name.Left(10).Upper is usually easier to read than Upper(Left(Name,10))