Project Glossary
| Term | Explanation |
| 3rd Party Application | Application developed by externally parties that can be installed onto PSS framework and consequently shared and consumed by other PSSs. 3rd Party Application consist of 3rd Party service, Proxy and 3rd Party GUI. 3rd party GUI can be omitted and is only necessary if the app comes with a client graphical user interface. |
| 3rd Party GUI | A GUI can be developed by a external party as one of the parts of the 3rd Party Application. When another PSS consumes the 3rd Party service and starts a session on it, the GUI is transferred and deployed to that PSS. 3rd Party GUI is used by the client user to communicate with the 3P service. |
| 3rd Party Proxy | The 3rd Party Proxy is used for remote object invocation to hide the specific of the specific PSS communications based on ONM service messaging. The 3rd Party Proxy exposes the same interfaces as the corresponding 3rd Party service deployed in another PSS. The 3rd Party Proxy can also be called a stub. |
| 3rd Party Service | A service which is not part of the core PSS implementation and is provided by an external 3rd party. 3rd Party service can be deployed to the PSS as part of the 3rd Party application and can be shared with other PSSs. |
| Batch learning | A machine learning approach that is dependent on a priori training data and requires access to a store of all past training examples. Learning cycles are scheduled at intervals where all past training examples are processed with any new examples to completely re-learn the target function. Any previous target function is over-written. Such an approach requires a lag period at initial system usage in order to build up an initial training dataset. |
| Behaviour patterns | Common sequences of user behaviour that may be represented by preferences (e.g. when the user is at work they mute their phone) or user intent tasks (e.g. when the user starts service A, the user then starts service B). |
| Component testing | Tests to be carried out on the individual components of the PERSIST system |
| Conflict Resolution | Conflict resolution occurs at various decision points throughout the PSS platform however, here it refers to processes within the proactivity subsystem. Proactivity receives input from Preference Management, User Intent and Incremental Algorithms all proposing proactive adaptations to apply in the user's environment. Proactivity mediates the input received and resolves any conflicts between input streams before applying it appropriately. |
| Consumer DPI | A user DPI used to consume a service. |
| Context | Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application (ed. note: “service”), including the user and applications (ed. note: “services”) themselves (Dey). Not all context information that follows that definition must necessarily be stored by a context management subsystem. While a context management subsystem provides convenient access to context information for third party services or platform services, such services may directly obtain context information from context sources (e.g. for efficiency) if these sources allow such access. |
| Context Database | The Context Database is a navigational database that extends over all Peers of the PSS. |
| Context Entity | A context entity is a data storage object of a navigational database. Context entities are groups of Attributes (key-value pairs) that can be interconnected by Associations. Note that its name stems from Context Management system definitions, but it is not specific to Context Management. |
| Context Inference | The process of making context information explicitly available from other context sources (called lower-level context in this regard). It is part of Context Refinement, consists in drawing conclusions from existing information. |
| Context Inference Rule | A personalized rule that indicates how to process contextual input in order to obtain other context information, that is not known before. A Context Inference Rule in general can take any form, e.g. logical, conditional, probabilistic or a NN. |
| Context Management | Refers to the Context Management component block of Task 3.3. |
| Context Refinement | Any process to create new knowledge based on available context information. |
| Context Source Manager | The Context Source Manager is a Context Management component that manages (registration, de-registration, configuration) context sources. |
| Coordinator | The Peer responsible for certain coordination tasks within a PSS on a PSS level (i.e. regarding the entire PSS), e.g. the publishing and updating of PSS advertisements. |
| Database | A database is a collection of records, or pieces of knowledge. It is managed by a Database Management System. |
| Database Management System | A Database Management System (DBMS) is a system or software designed to manage a database, and run operations on the data requested by numerous clients. |
| Device | see PSS peer |
| Digital Personal Identity | A digital representation of the PSS owner, i.e. the person or organisation on whose behalf the PSS operates. |
| Distributed service | A service that is represented by many instances each residing on a different PSS Peer. |
| DPI | DPI (Digital Privacy Identifier) is the identifier that is used to pseudonymously identify the user in order to enforce different levels of privacy protection. |
| Dynamic Group Management | The functionality that allows PSS to be added or removed from PSS Groups automatically based on pre-defined criteria. |
| Enabling Service | A sub-system within the PSS architecture. |
| Grouping | PSSs can be grouped together into dynamic groups (with context-dependent membership criteria) or static groups (with context-independent membership criteria). Groups of PSSs enjoy greater sharing privileges of resources and information between members of the group. |
| History of Context | The term history of context (HoC) denotes the recorded past values of context information regarding users, devices, services or other entities that may be part of or interact with the PSS or is somehow related to it. |
| Home PSS node | For each piece of context information there is a single PSS peer that is considered to be its Home PSS device. The Home PSS node of context information X is responsible for originally collecting/measuring X and is the only (or most) relevant PSS peer to X. Each Home PSS device can be either the Master PSS node or a Slave PSS node. |
| Incremental algorithm | An algorithm that follows an incremental learning approach. (see incremental learning) |
| Incremental learning | A machine learning approach that is not dependent on a priori training data and does not require access to a store of all past training examples. Instead training examples are processed one at a time, through time as they become available. Further, a best estimate of the target function so far is available for request at anytime. |
| Integration testing | Planned "integration" tests will be carried out on a number of identified milestones/release milestones |
| Leader | A dedicated distributed service instance that performs orchestration or other tasks with respect to the way the distributed service is internally organized. |
| Learned Behavior | A behavior that can be predicted based on previously obtained knowledge. |
| Learning | A PSS self improves by employing mechanisms that allow it to learn how to tailor its behaviour to better meet the needs of the individual user based on previous user behaviour and contextual states. |
| Local DPI | The DPI used by the provider of the service to consume that service. |
| Master PSS node | A single device within a PSS, usually one with server capabilities, i.e. high processing power and storage capacity, is elected as the Master PSS node. It aggregates context information from all devices/nodes of the PSS and is responsible for maintaining HoC data in order to support inference of current and future context. Being the core of the CM framework, this node is intended to be always on and connected. |
| Membership Evaluation Rule | A set of conditions that must be evaluated to determine if a PSS should be automatically added to or removed from a PSS Group. |
| Mining algorithm | An algorithm that follows a batch learning approach. (see batch learning) |
| Negotiation | When PSS A attempts to make use of a service provided by PSS B the two PSSs must negotiate over what information is required to use the service and what information PSS A is willing to divulge. |
| Overlay Network Management | The management functionality for an overlay network of PSS devices, which includes peer group management, PSS advertisement publishing and discovery, and service messaging. |
| Peer group | A peer group is a set of individual peers that are grouped for a common purpose. |
| PerCom | Pervasive computing |
| Personal Smart Space | See PSS for a formal definition |
| Personalisable parameter | A 3rd party service can have a list of parameters that can be personalised for the user. These may include background colour, volume level, font size, etc. |
| Personalisation | Personalisation is the set of processes that adapt the behaviour of a system so it appears differently to different users or to the same user in different contexts. By "appears" we mean more than just the colour of the screen but the way in which the system reacts to the user. This includes the services it selects, chosen devices, how services are manipulated at runtime and any automatic triggering it my do on the user's behalf. |
| Pivot | The peer which holds the most up to date or relevant value of a shared memory cell; in case PSS was split in more partitions then they may have different values and the pivot value is used as the valid value when the partitions merge back into one. |
| Policy | An electronic document containing a list of actions, decisions or goals that need to be achieved in a specific domain. Policy does not define exact steps on how these goals should be reached and therefore differs from set of instructions or rules. Policies can be defined for different domains, such as privacy policies or Quality of Service policies. |
| Preference | A rule which indicates what the user prefers depending on their current context. Used to personalise both PSS services and enabling services. |
| Preference learning | A learning procedure specific to learning context-dependent preference rules based on monitored user behaviour and accompanying context states. |
| Privacy Agreement | Agreement about what data and under which conditions should be disclosed by the user to the service. |
| Privacy Policy | A legal document in electronic form stating in which way a data controller responsible for computer system is to use the gathered personal identifying information from data subject. It defines which information is going to be collected, for what purposes and what actions are going to be performed on it. |
| Privacy Transaction | Association between user (identifier by a consumer DPI), provider (identified by the public DPI) and their privacy agreement. |
| Private DPI | The confidential DPI used internally in PSS as a primary key to data structures. |
| Pro-activity | Pro-activity should take decisions on behalf of the user in order to personalise services and environments. |
| PSS | A Personal Smart Space (PSS) is defined by a set of services within a dynamic space of connectable devices where the set of services are owned/controlled or administered by a single user or organisation. It facilitates interactions with other PSS, is self improving and capable of pro-active behaviour. A PSS has the following characteristics: -it is user centric and can move with the user. - it has an “owner”, the person or legal entity on whose behalf the smart space operates. - it respects the privacy of the user and guard personal information disclosure. - it allows services and applications to be shared with other PSS. - it supports operation in an ad-hoc environment. - it learns from previous interactions, to partially automate recurring tasks or actions or suggest alternates. - it allows 3rd party applications deployed to a PSS to adapt to the current situation and context. |
| PSS 3P API | A set of Interfaces that expose a subset of the functionality provided by the PSS Platform API to 3rd party services that are either deployed within the PSS container on a device or within another device in the same PSS. |
| PSS Framework | The core layer of the PSS architecture responsible for discovering and composing PSS and 3rd party services, as well as, managing context data and user preferences. |
| PSS Group | A set of PSS and services; PSS Groups form the basis for the PSS owner applying access controls for services within his/her PSS. |
| PSS Manager | A Persist framework component that orchestrates other framework components to achieve goals such as initialising and shutting down a peer, listing other peers and PSSs and the addition and removal of a service. |
| PSS Peer | A device or node that can connect to a network, can support the PSS software and is part of a PSS. |
| PSS Peer Group | A PSS peer group describes the set of peers (devices) that makes up a PSS and are owned by the PSS user. Thus, it is a set of networked peer devices that jointly form the platform upon which a PSS is deployed. Each PSS is a peer group where the common purpose is to represent the user’s PSS. A PSS peer group could for example include a mobile device, laptop and home server. |
| PSS Platform API | The set of Interfaces that makes up the PSS Platform applicable to any PSS Platform components that reside either on the same device or on another device but within the same PSS. |
| PSS Service | A service which is part of the core PSS architecture. These services are enabling services for applications. |
| PSS2PSS API | A set of Interfaces, which is a subset of the PSS Platform API, with the purpose of exposing the necessary functionality for interactions between two or more different PSS instances. |
| PSS-Extended | A PSS distribution deployed on machines/devices with a high level of processing power available. |
| PSS-Lite | The minimum set of PSS software bundles deployed on peripheral devices that want to be part of a PSS. |
| PSS-Standard | A PSS distribution deployed on (usually light, mobile) user devices. It will not contain any components that require heavy processing. |
| Public DPI | The provider DPI used to advertise services. |
| Quality of Context | Quality of Context (QoC) denotes a set of parameters, used to describe the quality of certain Context Information elements. Examples of QoC parameters include: Accuracy, Probability of Correctness, Reliability, Resolution, Timeliness, Frequency, Price, etc. |
| Reasoning | See Context Inference |
| Recommender System | An information filtering technology (commonly used on e-commerce Web sites) that uses a collaborative filtering to present information on items and products that are likely to be of interest to the reader. In presenting the recommendations, the recommender system uses details of the registered user’s profile, as well as opinions/habits of all other members in their user community and compares the information to reference characteristics to present the recommendations. In PSSs, Recommender Systems are used to recommend the most preferable/suitable services to the PSS owners. |
| Resource Sharing | This mechanism is required when two PSSs attempt to use the same service in parallel. It may be the case that only one PSS can use the service at a time in which case access to the resource must be shared. It can also be the case that multiple PSSs can use the service at a time but personalisation must be mediated to adapt the service to best meet the needs of all PSSs involved. |
| Scenario testing | These tests to be carried out on the finished system on the demonstrator scenarios |
| Service Composition | The satisfying of a composite service's dependencies with existing candidate services irrespective of whether the service is local, on another peer or another PSS and its deployment. |
| Service Registry | An in-memory store of local, other peer and other PSS third party services. |
| Service Run-Time Environment | A container for the PSS services that supports service life cycle management features, provides a service registry and a common graphical framework. It also performs various low-level tasks such as sending events, installing, starting and stopping a 3rd party service, transferring its GUI, etc. |
| Service Session | It is a set of distributed service instances, which collaborate to deliver a useful application/service to the user, i.e something that could be charged for. If the application/service is atomic, this set contains exactly one service instance, for composed service/applications this set contains 1 or more service instances. Note: the service session can include service instances from other PSSs. |
| Session Management | The management of third party services by the PSS with particular relevance to composite services to ensure that they remain operational if member service(s) become unavailable. |
| Shared memory | A virtual memory maintained by synchronization of different memory pages from different Peers. |
| Slave PSS node | In addition to the Master PSS device, every PSS may have one or more Slave devices, which contribute to the collection of contextual data. Thus, from the point of view of context management, there is a single Master PSS node per PSS, and all other PSS peers are considered to be Slave PSS nodes. Slave devices periodically send collected data to the Master PSS node. If the Master device becomes unavailable, a slave one may be elected in replacement. |
| Smart Space | A collection of devices and software components which enable context awareness and proactively adapt to user’s preferences. |
| special constraints | Conditions under which data associated to some DPI should be handled by data controller. |
| SQL | SQL (commonly expanded to Structured Query Language) is the most popular computer language used to create, modify, retrieve and manipulate data from relational database management systems. The language has evolved beyond its original purpose to support object-relational database management systems. It is an ANSI/ISO standard. |
| Static Group Management | As opposed to the automatism of Dynamic Group Management, Static Group Management refers to the manual addition or removal of PSS and services from a PSS Group by the user. |
| System Run-Time Environment | An abstraction layer between the underlying device operating system and the PSS software in order to achieve as much platform independence as possible. |
| URI | A Uniform Resource Identifier is a compact string of characters used to identify or name a resource. The main purpose of this identification is to enable interaction with representations of the resource over a network, typically the World Wide Web, using specific protocols. URIs are defined in schemes defining a specific syntax and associated protocols (RFC 2396). |
| User Action | An act performed by the user that changes the state of an entity where an entity may be a service, network or device |
| User Intent | User Intent is the set of processes that identify and maintain a model of common sequences of user behaviour. The information held in the model is used to predict future user needs and drive system behaviour. |
| User intent learning | A learning procedure specific to learning common sequences of behaviour based on monitored user behaviour. |
| User intent task | A common sequence of user behaviour is called a user intent task and relates to some real-world task e.g. "going to work". Each task consists of a sequence of user actions that the user performs to complete the real-world task. |
- Login to post comments