4. Electronic Institutions: The EI/EIDE Framework

On terminology: (i)“EI” refers to the “Electronic Institutions” metamodel. EI is a “conceptual model” in the sense that it describes the ideal languages, data structures, operations and operational semantics needed to describe electronic institutions but it is also a “meta-model” in the sense that any particular electronic institution may be “modelled” using those constructs. (ii) As we shall discuss in Sect. 4.4, the EI metamodel can be implemented in different ways, the ‘Electronic Institutions Development Environment” (EIDE) is the one we discuss in this paper, thus our use of “EI/EIDE” framework. (iii) In fact, EIDE refers to a computational architecture plus as a set of tools that implement the EI metamodel. However, abusing language, we variously use EIDE to refer to (a) the technological objects that permit implementation of any electronic institution that may be “modelled” in the EI “meta-model”, (b) a software “platform”, (c) the computational “environment” used to deploy electronic institutions, or (d) the “infrastructure” that supports running institutions.

Electronic institutions implement socio-technical systems, thus are part of a technological environment (EIDE platform, software agents, communication platforms, web services, etc.) embedded in a social environment (people, organisations, legal framework, etc.) that provides meaning and consequence to the actions that take place within the electronic institution.

http://​peerflow.​iiia.​csic.​es

http://​simple.​iiia.​csic.​es

A precise definition of these constructs is available in Arcos et al. (2005); a complete, formal specification of the whole EI conceptual model is in d’Inverno et al. (2012). See Sect. 4.6 below for discussion of some particular aspects.

The communication and domain languages of an institution presume the existence of constitutive conventions that establish the correspondence between institutional and brute facts and actions. Thus, for example, in the utterance below, there should be a contract that entitles supplier “B” to transfer the property of “T” and the regulation that establishes the obligation of the purchasing agency to pay 30.000 euros to “B”: declare < (?s: staff )(all); adjudicated(ItemT,supplierB,30.000); t _n  > 

This process may be to acquire (office supplies, build a nuclear plant) or to sell (e.g., radio-frequencies, privatise prisons), and the request would include the basic requirement: objective of the process (buy or sell), type of negotiation (e.g., public auction, arbitrated negotiation with three invited bidders), proposed deadlines, and the detailed request for quotations.

In W3, gatekeeper enters the Vestibulo scene and also moves into the new agreement process.

This is not altogether unnatural: think for example in “mail chess” where players are in different locations and play asynchronously by notifying moves through messages in a coded language.