The Perspectives Language

In modeling Perspectives we answer the question “Which perspectives do roles in contexts need to achieve their goals?”. This means that the Perspectives Language is all about the Perspectives of Userroles on the Properties of other roles in particular Contexts. For humans it is extremely easy to recognise Context and their Roles. From early on we learn how to behave in our Role in certain Contexts and what to expect of others. Therefore learning the Perspective Language is quite easy. More on this in Perspectives on Human Cognition.

Here are some modeling principles in the Perspectives Language. First some principles concerning Roles:

Roles can be Userroles or Thingroles
Userroles have Perspectives on other Userroles or Thingroles
We call this an ON relation between the Userrole and the Role it has a Perspective on
If a Userrole has a Perspective on another Role, the User that embodies the Userrole can see the instances of the other Role
By default the User can then see all Properties of the other Role
By adding a View to the Perspective, the Properties the user can see are limited to the Properties of the role that are contained in the View
By default the User can Create and Update and the instances of the Role
By changing the permitted Actions of the Perspective the User can be prevented to Create and/or Update the Properties of the Role
Roles can be Single or Multi Roles
A Single Role will have only one instance, Multi Roles will have many
Single Roles will result in a Form on the User Interface
Multiroles will result in Tables on the User Interface

Contexts are the main components of a Perspectives application. To support modeling we distinguish five types of Contexts:

Domains: like the Health Domain or My Social Domain
Parties: like Organisations, Companies, Public Government Departments
Cases: like Application Requests or an Groceries List
Activities: like Request Something, perform a Review
States: like Preparation for an Activity or Finishing an Application

Domains typically contain Parties and generic User- and Thingroles. The Health Domain could for instance contain a Hospital as Party and Userroles like Patient or Doctor. Parties are Organisations, Companies or Shops that provide Products or Services. Typically someone can visit a Party to see which of these are provided and when interested can engage with members of the Party. Cases are management Contexts in which decisions are made concerning focus roles in the case and the Activities that are relevant. Activities typically have a place and time. If Activities have significant stages they contain States as Contexts. The same applies to Cases.

Some principles concerning Contexts:

Only Roles have Properties. Contexts also have Properties but they do not contain Properties themselves. Their Properties are represented by the Context Role of a Context. Every Context has a Context Role
The Context Role of a Context is visible from the outside of the Context and can be used in other Contexts.
Context can be nested. This means that a Context can contain one or more other Contexts. In this case we say that a Subcontext is IN another Context. Typical examples of this are:
- Domains that contain Parties and SubDomains
- Parties that contain Cases
- Cases that contain Activities or SubCases
- Cases or Activities that contain States

Nesting also applies to Roles. In Perspectives we say that a Role is IN another Role or in other words that a Role is filled with another Role. This means that the Properties and the Property Values of a Role that fills another Role are also present in the filled Role. An example is the Role Commerce Worker that is filled by Worker. Not only will Commerce Worker contain its own Properties, it will also contain the Properties of Worker. This nesting of Roles typically parallels the nesting of the Contexts they belong to. In other words: often the filled Role is a Role in a SubContext of the Context of the filler Role.

Filled Userroles will have their own Perspectives on other Roles but also the Perspectives of the filler Role. At least in case both Roles are in the same Context. If the filled Role is in a Subcontext this Role will only have the Perspectives it has in the Subcontext.

Furthermore, a Userrole can become another Userrole. If the Userrole can make itself another Userrole we call that a BE relation between both. A BE relation enables an end user to move from one role to another, thereby changing his perspective..

A Userrole can also make some (User)Role another (User)Role. This is possible if there is an IN relation between both Userroles and the Userrole has a Perspective on both. Note that this is true for Userroles as well as Thingroles.

In Perspectives we use five types of Properties:

Booleans: that can only have True (Yes) or False (No) as their values
Strings: this can be a single word or a small text
Numbers: that can be used to perform calculations
Dates, with or without Time
Files: Application Files like Images, Sounds, Spreadsheets etc.

This more or less concludes the definition of the Perspectives Language. The Perspectives Software supports both textual versions of an Application as well as graphical ones. More on this in the next parts: