public:ipaaca:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| public:ipaaca:start [2015/03/02 16:25] – ryaghoub | public:ipaaca:start [2023/02/27 14:29] (current) – stanges | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== IPAACA – Incremental processing architecture for artificial conversational agents ====== | ====== IPAACA – Incremental processing architecture for artificial conversational agents ====== | ||
| + | |||
| + | |||
| + | This page describes the basic concepts underlying IPAACA. For a theoretical background have a look at the research papers that were foundational to IPAACA' | ||
| + | |||
| + | * Schlangen, D. & Skantze, G. (2009). A general, abstract model of incremental dialogue process- ing. In // | ||
| + | * Schlangen, D. & Skantze, G. (2011). A general, abstract model of incremental dialogue processing. //Dialogue and Discourse,// | ||
| + | |||
| + | For a short documentation of the command line tools that can be used with IPAACA, see [[public: | ||
| ==== Overview ==== | ==== Overview ==== | ||
| Line 5: | Line 13: | ||
| === IUs and Messages === | === IUs and Messages === | ||
| - | The basic unit of information transmitted (shared) in the ipaaca system is the *Incremental Unit* (IU), based on the " | + | The basic unit of information transmitted (shared) in the ipaaca system is the **Incremental Unit** (IU), based on the " |
| - | * uid - a globally unique identifier | + | * //uid// - a globally unique identifier |
| - | * category - a string representing the broad category of data, e.g. " | + | |
| - | * owner - the buffer name (see below) that initially produced this IU | + | * //owner// - the buffer name (see below) that initially produced this IU |
| - | * committed - a flag that specifies whether the owner is committed to this IU and its contents (that it will remain valid and is final) | + | * //committed// - a flag that specifies whether the owner is committed to this IU and its contents (that it will remain valid and is final) |
| - | * payload - the IU payload: a map of string-> | + | |
| - | * links - a map of string-> | + | * //links// - a map of string-> |
| IUs are persistent objects. That means that they can be modified at any time (unless specified as read-only by the user), and any changes of published IUs are automatically transmitted as updates to all relevant parties. They can also be modified from the remote side, unless specified otherwise. | IUs are persistent objects. That means that they can be modified at any time (unless specified as read-only by the user), and any changes of published IUs are automatically transmitted as updates to all relevant parties. They can also be modified from the remote side, unless specified otherwise. | ||
| - | The Message is a special case of an IU: it is a non-persistent read-only version of the IU. It can be used whenever you just want to send current information (akin to lightweight message-passing systems, hence the name), without the possibility of later modification. The benefit is that Messages are only present for the time of reception and do not occupy additional cumulative recources. | + | The **Message** is a special case of an IU: it is a non-persistent read-only version of the IU. It can be used whenever you just want to send current information (akin to lightweight message-passing systems, hence the name), without the possibility of later modification. The benefit is that Messages are only present for the time of reception and do not occupy additional cumulative recources. |
| === Buffers === | === Buffers === | ||
| - | IUs are objects that exist in Buffers. A program can have any number of OutputBuffers and InputBuffers. When a new IU has been created, it has to be placed in an OutputBuffer. It is thereby published. | + | IUs are objects that exist in **Buffers**. A program can have any number of OutputBuffers and InputBuffers. When a new IU has been created, it has to be placed in an OutputBuffer. It is thereby published. |
| - | InputBuffers that components have initialized have a list of category interests, set by the user. Whenever an IU (or Message) of said categories is published or modified anywhere on the system, the corresponding InputBuffers will receive a notification of this, along with the updated IU contents. | + | InputBuffers that components have initialized have a list of **category interests**, set by the user. Whenever an IU (or Message) of said categories is published or modified anywhere on the system, the corresponding InputBuffers will receive a notification of this, along with the updated IU contents. |
| Changes to IUs that are not marked as read-only can be effected at both ends of the pipeline: by simply writing to an IU present in a Buffer. When an IU has been written to from the remote side, the owner of that IU will also be able to receive a notification of this on the OutputBuffer where the IU was originally placed. IUs that have not yet been published can be written to at leisure without generating any events anywhere. | Changes to IUs that are not marked as read-only can be effected at both ends of the pipeline: by simply writing to an IU present in a Buffer. When an IU has been written to from the remote side, the owner of that IU will also be able to receive a notification of this on the OutputBuffer where the IU was originally placed. IUs that have not yet been published can be written to at leisure without generating any events anywhere. | ||
| Line 41: | Line 49: | ||
| uid: c4f74af9-ac0f-44d6-9b04-b9294930f9bb | uid: c4f74af9-ac0f-44d6-9b04-b9294930f9bb | ||
| owner: / | owner: / | ||
| - | links: {" | + | links: {" |
| payload: { | payload: { | ||
| " | " | ||
| Line 52: | Line 60: | ||
| - | ===== Archived information ===== | + | === Windows |
| - | Relation | + | There are Windows builds of the C++ version of IPAACA. Currently, two flavors exist: |
| + | * old API version, built for Visual Studio 2010, and using rsb0.10 from pre-built ' | ||
| + | * Several Windows projects rely on this at the moment (2016-12), like DragonSpeech and EyeX | ||
| + | * new (JSON) API version, built for Visual Studio 2015 and using our own pre-built libs | ||
| + | * Contained dep versions (as of 2016-12): Boost 1_57, Protobuf 2.5, Spread 4.4, RSC/RSB 0.14 (static Boost linkage) | ||
| + | * Usage: | ||
| + | - Install Visual Studio 2015 (probably won't include / link using older VS versions) | ||
| + | - Create a repository folder somewhere (mine is Documents\Develop\repo in my home), and set the SOA_REPO_DIR environment variable for the current user to refer to it (via control panel). | ||
| + | - Unpack one of the following archives into that folder: | ||
| + | - 64-bit Release build (recommended): | ||
| + | - 32-bit Debug build: https:// | ||
| + | - The archive contains ipaaca, its dependencies, | ||
| - | ===== Open issues / notes ===== | ||
| - | * [Python] Component does not terminate properly when end of main execution is reached. | ||
| - | * [Python] Rewrite ipaaca-python internals to use weakrefs, so that objects are destructed when they leave scope. Transparent change, no API change needed. | ||
| - | * **WORKAROUND**: | ||
public/ipaaca/start.1425309904.txt.gz · Last modified: 2015/03/02 16:25 by ryaghoub