Skip to content
Tomas Trescak edited this page Jan 2, 2014 · 3 revisions

EI 2.0 Specification

The Quadratic Formula

$$x = {-b \pm \sqrt{b^2-4ac} \over 2a}$$

The Lorenz Equations

\[\begin{aligned} \dot{x} & = \sigma(y-x) \
\dot{y} & = \rho x - y - xz \
\dot{z} & = -\beta z + xy \end{aligned} \]

ID Name Rank
1 Tom Preston-Werner Awesome
2 Albert Einstein Nearly as awesome

In this document, we provide a formal specification of all EI 2.0 parts, along with three sophisticated examples, representing the possibilities of our proposed system.

Ontology

The ontology captures the world in which institution exists. It provides comprehensive description of possibilities of all possibilities provided by the institution. As a result, agents can use this information to investigate if institution can help it to achieve its current goal.

Ontology consists of several types of concepts connected via arcs that represent relations between them. Concepts capture all roles and all their actions that given role can perform in the institution. They also define complex types (also called classes) used to store state information of any role or serve as input or output arguments of any action.

Ontology is expressed as directed graph where specific nodes are connected via relational arcs. All information specified within ontology is validated according to several factors.

Concepts

Ontology consists of following nodes (see Appendix A for the complete description):

  • Simple Type Node (Type) represents a data type (e.g. int, string).
  • Named Type Node (Property) is a node that holds a named value of a specific type.
  • Role Node describes an actor group of the system.
  • Action Node represents an action in the institution, where each action can be performed by specific roles, called with one or more input arguments, returning a specific value and possibly some output arguments.
  • Complex Type Node (Class or Concept) defines a concept in the system, which can have several properties and can perform several actions.

Relations

Ontology nodes can be connected via directional arcs, where each arc represents following relations adopted from ConceptNet 4:

| Name of relation | Meaning | --- | IsA | What kind of thing is it? | HasA | What does it possess? | PartOf | What is it part of? | UsedFor | What do you use it for? | AtLocation | Where would you find it? | CapableOf | What can it do? | MadeOf | What is it made of? | CreatedBy | How do you bring it into existence? | HasSubevent | What do you do to accomplish it? | HasFirstSubevent | What do you do first to accomplish it? | HasLastSubevent | What do you do last to accomplish it? | HasPrerequisite | What do you need to do first? | MotivatedByGoal | Why would you do it? | Causes | What does it make happen? | Desires | What does it want? | CausesDesire | What does it make you want to do? | HasProperty | What properties does it have? | ReceivesAction | What can you do to it? | DefinedAs | How do you define it? | SymbolOf | What does it represent? | LocatedNear | What is it typically near? | ObstructedBy | What would prevent it from happening? | ConceptuallyRelatedTo | What is related to it in an unknown way? | InheritsFrom | From what is it inherited?

Validation

Ontology provides following validations:

  1. Realisation: Check if all data types (concepts) are created (exists "CreatedBy" link to the datatype)
  2. Redundancy:
    1. Check if all concepts are used
    2. Check if each role performs at least one action
  3. Completeness: Check if all performs relationships are included in the workflow

Examples

In this section, we present three different examples which we'll use in the rest of this text. For each of the examples we present an ontology.

Example 1: Auction House

Our goal is to define the online solution for Electronic Online Auctions. In this system, users can obtain various goods by participating in online auctions. All users of the auction system can browse through catalog of auctioned items, and they can search for a specific item (anonymous users). To participate in the auction user has to register as buyer, providing personal details for security purposes and his/her identity is verified through email verification. In case a participant wins an auction, he/she is obliged to pay for the auctioned good. In case of not complying with this obligation, user is denied access for all other auctions.

Auctioned goods are offered by registered sellers. Sellers have to provide extra details, such as banking details or PayPal details, and their identity is verified. After sellers identity is verified, thay can create a new auction by registering item in the auction system. Auction is following the English auction system protocol, where users bid a price which has to be bigger than the previous one.

image

VALIDATION: Ontology is validated on correct use (creation) of datatypes and redundancy`

Example 2: e-Government - Spanstralian Driving License

In the world of burreaucracy, the path to the goal is often long, dark and painfull. In our example we focus on mapping the process of obtaining the driver's license in a fictional country Spanstralia, which is inspired by license system in Spain and Australia. We focus on process of obtaining the car and motorcycle license, which issue is interconnected, as for example car drivers after 5 years can automatically apply for a motorcycle license up to 125cc without examination. Using assistance layer in the electronic institution, a citizen can pose queries to the burreaucratic body, which can explain what needs to be done in order to issue a specific license.

The textual description of the process obtaining the license C is following:

  • This entitles the holder to drive a vehicle that weighs no more than 4.5 tonnes and seats a maximum of 12 people, including the driver.

The process of obtaining the license is separated into four steps:

  • Phase 1 Learner's permit
    • Minimum age is 16
    • Passed eye test
    • Computerised road rules test
      • Valid three years
    • Two pieces of documentation, one with signature
    • Medical declaration
      • Medical examination -> Medical evaluation
    • --> Obtained "L" license for driving lessons
      • Can drive with instructor or 4 year full icense holder
  • Phase 2 Learner's permit
    • Minimum age 16,5 years
    • Practical driving assessment
    • 25 hours of supervised driving in the log book
  • Permit "P"
    • Minimum 17 years
    • Hazard perception test
  • Full license
    • After 2 years minimum (year is complete with no offences)

Motorcycle permit has exactly the same process with following exceptions:

  • 3 year full license holders with no offence can automatically obtain P license for motorcycle up to 50 cc
  • 5 year full license holders with no offence can automatically obtain P license for Motorcycle up to 125 cc

In case that a driver is charged with an offence, driver loses demerit points (number of points varies for each offense). When driver loses all points, loses a license for a defined amount of time and rolls back 1 level for each time the license is lost (Full -> P -> L2 -> L1).

The goal of the system is to monitor a new driver and in any given time display possible options for obtaining any kind of license.

Example 3: Playing fetch with agents

Consortium of auction houses serves as an example for online possibilities of EI 2.0. In this example user is trying to obtain a specific good. Traditionally this is done through Google search and then byuing the goods either directly with an e-shop or in auction (e.g. eBay). EI 2.0 bring possibilities of having agents representing us on our behalf in such systems and negotiate the best deal for us. In this scenario:

  • We assume that there exist various Auction Houses implemented as EI 2.0 from the Example 1.
  • Below, we define a simple e-shop institution

The goal is to give agens a task to obtain a specific item (good) for us for the best price. Executing this task is a multiple step process explained below.

Part 1: Programming agents

In this step, we need to give agents specific orders that will drive their actions. These orders are specified in the language specifically given to agent in the form of an ontology.

We distinguish two types of agents:

  1. Workflow driven agents - Their orders come in the form of parametrised agent workflow graph. These agents strictly follow a given workflow and can communicate only with 100% matched (See next section) institutions.

    As a result, programming This type of agents is much similar to specifying institution, using the same set of tools.

  2. Goal driven agents are given following instructions according to their ontology. This approach requires to perform ontology matching and agents can only participate in the institution when matching was successful (see next section). Agent follows these instructions:

    • Requested-response instructions according to which agents respond to the given request.
    • Informed-handle instructions according to which agents updates its state a after it was informed about a specific action and also can counteract
    • Request-handle response instructions allow agent proactively perform actions in the institution
    • Inform-handle response instructions allow agent to inform institution participants to inform about a particular change of state

    Agent goal is specified as:

    • A change of state - agent plan is automatically generated in order to reach a required change of state
    • A request - agent plan is automatically generated

    Agent plan failure is specified similarily as

    • A change of state
    • An inform

Part 2: Running agents

  1. Agent connects to the institution which is either: *. Given explicitly by HTTP address or *. Selected from the list of institutions. Institution list shall be registered somewhere online. Each institution provides a public interfaces (similar to web services) which describe services provided by the institution (see chapter on assistance). Agent selects the institution that provides services that facilitate completion of its goal. Service example (buy product, buy vacation - negotiate deal, buy package, reserve hotel)

  2. Agent matches ontology with the institution ontology

    • Ma

Context

  • Creator Roles
  • Access roles
  • Join/Exit constraint (Role,constraint)
  • Join/Exit action (Role,action)
  • Join type? Static/One/Some/All
  • Opened / closed
  • Input/Output arguments
  • Extendible set of parameters ... Maybe not
  • Container for items
  • synchronization point, clones spawned within context cannot leave separately this context?

Explore synchronization, prepare examples

Components

Container

  • Holds 0/1 controls
  • Can, but does not have to define its own context

Sequence

  • Holds 0/n controls

Workflow

Name, Container

Flow Control

If

Name, Condition True container False container

For each, While, Do-While, For

Name, Condition Container

Assign

Parallel (or)

Split (and)

Select (xor - 1)

Dynamic (xor-n)

Extensions

Extension Point

Remote Connection

  • Authentification and authorization
  • complete set of Roles assigned

Cloning

Accessibility Layer

Synchronization of actions across multiple institutions

Synchronization of institution execution

Timeouts

Anything can be timed out, even contexts When timeout occurs, participants are notified and execution moves right after the timed out component

  • What if there are more possible ways of advancement?

Appendix A: Ontology Specification

  • Simple Type Node (Type) represents a data type and can have only following values:

    • String (string)
    • Int64 (int)
    • Double (double)
    • Boolean (bool)
    • Date (date)

    Each of the types can be defined also as an array [].

    In further text we also use one more type dynamic, that holds a value which can be of any of the previously mentioned types.

  • Named Type Node (Property) is a node that holds a value of a specific type, and identified by name

    | Property | Type | | ------------------ | Name | string | | Description | string | Type | Simple Type or Class
    | DefaultValue | dynamic | Required | bool | Value | dynamic |

  • Role Node describes an actor group of the system.

    | Property | Type | | --- | Name | string | Description | string | Properties | Property[] | Internal | bool | External | bool | CanReadStructure | bool | CanWriteStructure | bool

    | Relation | Cardinality | With | | --- | parent <-> child | 0 .. n | Role | notCompatible | 0 .. n | Role

  • Action Node represents an action in the institution, where each action can be performed by specific roles, called with one or more input arguments, returning a specific value and possibly some output arguments. Action can be executed as a consequence of some other action, and its execution can be notified to other roles.

    | Property | Type | | --- | Name | string | Description | string | Return | Type | | InputArguments | Property[] | OutputArguments | Property[]

    | Relation | Cardinality | With | | --- | performedBy <-> performs | 1 .. n | Role or Class | consequence <-> isConsequenceOf | 0 .. n | Action | notifies <-> isNotifiedBy | 0 .. n | Role

  • Complex Type Node (Class) defines a concept in the system, which can have several properties and can perform several actions:

    | Property | Type | | ------------------ | Name | string | | Description | string | Properties | Property []

    | Relation | Cardinality | With | | --- | hasAction <-> isActionOf | 0 .. n | Action