Fandom

VroniPlag Wiki

Quelle:Saa/Vazquez 2007

< Quelle:Saa

31.379Seiten in
diesem Wiki
Seite hinzufügen
Diskussion0

Störung durch Adblocker erkannt!


Wikia ist eine gebührenfreie Seite, die sich durch Werbung finanziert. Benutzer, die Adblocker einsetzen, haben eine modifizierte Ansicht der Seite.

Wikia ist nicht verfügbar, wenn du weitere Modifikationen in dem Adblocker-Programm gemacht hast. Wenn du sie entfernst, dann wird die Seite ohne Probleme geladen.

Angaben zur Quelle [Bearbeiten]

Autor     Juan Ignacio Vázquez Gómez
Titel    A reactive behavioural model for context-aware semantic devices
Ort    Bilbao
Jahr    2007
Anmerkung    Universidad de Dusto: Tesis doctoral presentada por D. JUAN IGNACIO V´AZQUEZ G´O MEZ dentro del Programa de Doctorado en CIENCIA DE LA COMPUTACI´O N E INTELIGENCIA ARTIFICIAL
URL    http://paginaspersonales.deusto.es/ivazquez/phdthesis/ivazquez_thesis.pdf

Literaturverz.   

nein
Fußnoten    nein
Fragmente    12


Fragmente der Quelle:
[1.] Saa/Fragment 041 12 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:10:04 Hindemith
Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Vazquez 2007, Verschleierung

Typus
Verschleierung
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 41, Zeilen: 12-32
Quelle: Vazquez 2007
Seite(n): 24, 25, Zeilen: 24: 19 ff.; 25: 1 ff.
3.1 Evaluation Criteria

In this section, we define a set of evaluation criteria by analyzing and evaluating state-of-the-art architectures, and determine how our proposal ranks in comparison with these architectures. Most of the selected criteria can be found, implicitly or explicitly, throughout all the literature concerning ubiquitous and pervasive computing architectures. The examples of these criteria are decentralization, context-awareness, autonomy and/or standards adherence, while other criteria are more specific to our research goals, i.e. having reasoning capability (inferencing) on medical devices, and communication with other medical or mobile devices through Web Services technology. In the following sections, we have organized the criteria into three different categories, namely Architectural, Technological and Intelligence, depending on their nature.

Architectural

- Decentralization: At the core of any ubiquitous computing system, decentralization endorses a spontaneous and unanticipated nature, non-critical components in the architecture, ad-hoc reconfiguration according to the situation, and natural deployment of elements and scalability. However, the design and planning of decentralized systems is more difficult, as well as resulting in a higher load of network traffic due to synchronization and coordination messages.

- Lightness: The architectural elements and software components in particular should be designed in such a way that they could be easily embedded [in resource constrained systems, i.e. medical or mobile devices, as well as promote operational simplicity if possible.]

2.1 Evaluation criteria

In order to analyse and evaluate the state-of-the-art architectures as well as to determine how our proposal ranks, we need to define a set of evaluation criteria.

Most of the selected criteria can be found, implicitly or explicitly, throughout all the literature concerning ubiquitous and pervasive computing architectures: they represent core concepts and hot topics. Examples of these criteria are decentralisation, context-awareness, autonomy or standards adherence. Other criteria are more specific to our research goals such as reasonability or device implementation cost. However, the latter principles can also be easily found in similar related research.

We have organised the criteria into four different categories depending on their nature:

[Seite 25]

Architectural

Decentralisation: at the heart of any Ubiquitous Computing system, decentralisation promotes an spontaneous and serendipitous nature, non-critical components in the architecture, dynamic reconfiguration according to every situation, natural deployment of elements and scalability, among others. However, the design and planning of decentralised systems is more difficult, as well as resulting in a higher load of network traffic due to synchronisation and coordination messages.

Lightness: architectural elements and software components in particular should be designed in such a way that they can be easily embeddable in resource-constrained platforms and devices, as well as promote operational simplicity if possible.

Anmerkungen

Ein Verweis auf die Quelle fehlt. Der Text wurde z.T. angepasst, die Idee stammt jedoch erkennbar aus der ungenannten Quelle.

Sichter
(Hindemith), SleepyHollow02

[2.] Saa/Fragment 042 01 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:10:07 Hindemith
Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Vazquez 2007, Verschleierung

Typus
Verschleierung
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 42, Zeilen: 1-8, 13-46
Quelle: Vazquez 2007
Seite(n): 25, 26, 27, 28, Zeilen: 25: 10 ff.; 26: 1 ff.; 27: 1 ff.; 28: 13 ff.
[- Lightness: The architectural elements and software components in particular should be designed in such a way that they could be easily embedded] in resource-constrained systems, i.e. medical or mobile devices, as well as promote operational simplicity if possible.

Technological

- Standards Adherence: It represents the degree to which the envisaged system reuses and applies the widely accepted standards, thus taking advantage of previous R&D work and promoting re-usability in the industry and academia. The intention behind our research is to create new original work by assuring the highest possible degree of standards adherence. [...] - Technological Consistency: It represents the degree of coherence among the technologies used for the development of a system. The complementary technologies must be applied, if possible, in order to obtain synergistic performance and future re-usability.

Intelligence

- Reasoning Capability: It is the ability of the system to acquire and apply knowledge via reasoning (inferencing) process. In order to create the next generation of ambient intelligent medical or mobile devices, artificial intelligence techniques must be applied to a certain degree.

- Context-Awareness: In simple terms, it is the ability of the system to perceive and identify the relevant information from an environment and actively respond according to the defined rules. Context-awareness is inevitably required to meet the ultimate goals of ubiquitous computing and ambient intelligent environments.

The above-mentioned criteria are not completely isolated, rather certain dependencies exist among some of them in such a way that the degree of fulfillment in one concrete criterion can affect the other in a positive or negative manner. A high degree of decentralization favors the design of distributed lightweight components, instead of a bulky and heavy central controller. Lightweight components make the actual implementation feasible, but they also reduce the degree and quality of the embedded reasoning processes, which normally demand some amount of software complexity. The Reasoning Capability affects lightness negatively in the same way, since the more reasoning power the device is provided with, the heavier the component becomes. However, it promotes the context-awareness and autonomy, which can take advantage of the built-in intelligence to react accordingly. The Context-Awareness promotes autonomy, since architectural components can self-regulate their behavior depending on the context information provided by the surrounding entities. The Technological Consistency can significantly reinforce APIs reusability during the implementation, thus promoting more lightweight components that would be negatively affected by mixing up non-complementary technologies. At the same time, we consider that technological consistency simplifies the overall design by taking advantage of the existing mechanisms, procedures and interfaces.

Not all these criteria are equally important, but depending on the desired strengths of the resulting architecture, some of them must be promoted. We will focus primarily on maximizing decentralization, reasoning capability, lightness and standards adherence, [and, in a lesser extent, technological consistency and context-awareness.]

Lightness: architectural elements and software components in particular should be designed in such a way that they can be easily embeddable in resource-constrained platforms and devices, as well as promote operational simplicity if possible.

Intelligence

Reasonability: is the ability of the system to acquire and apply knowledge via reasoning processes. In order to create the intelligence-enabling component of any smart device or environment, artificial intelligence techniques must be applied to a certain degree.

Context-awareness: is the ability of the system to perceive and identify relevant information and perform reactive behaviour to provide the desired response. Intelligent context-awareness is the ultimate goal of Ubiquitous Computing and Ambient Intelligence.

[...]

Technological

Technological consistency: represents the degree of coherence among the technologies used in a system. If possible, complementary technologies must be applied in order to obtain synergistic performance and future reusability. For example, transporting XML messages over HTTP is more natural, standardised and desirable than doing it over CORBA.

[Seite 26]

Standards adherence: represents the degree to which the designed system reuses and applies widely accepted standards, thus taking advantage of previous works and promoting skill reuse within the industry and academia. It is a major intention of our research to create new original work while assuring the highest possible degree of standards adherence.

[...]

These criteria are not isolated. Certain dependencies exist among some of them in such a way that the degree of fulfilment in one concrete criterion can affect other in a positive or negative manner. These dependencies are illustrated in Figure 2.1, where rows represent influencing criteria while columns represent influenced criteria.

First, a high degree or decentralisation favours the design of distributed lightweight components, instead of a bulky and heavy central controller. Decentralisation also promotes a higher level of autonomy in architectural elements while reducing the scenario deployment cost, since environments are created by the emergent coordination of distributed elements.

Lightweight components make feasible the actual implementation and promote a lower device implementation cost, but they also reduce the degree and quality of the embedded reasoning processes which normally demand some amount of software complexity. Reasonability affects lightness negatively in the same way, since the more reasoning power the device is provided with, the heavier the component becomes. In a similar way, hosting reasoning processes in constrained devices increases their costs and the efforts in terms of specialised workforce to implement these features. However, reasonability promotes both

[Seite 27]

context-awareness and autonomy, which can take advantage of the builtin intelligence to better determine the behaviour to perform.

Context-awareness promotes autonomy, since architectural components can self-regulate their behaviour depending on context information provided by surrounding entities. The penalty for achieving a greater degree of awareness is, as usual, a higher device implementation cost.

[...]

Technological consistency can significantly reinforce APIs reusability during the implementation, thus promoting more lightweight components that would be negatively affected by mixing up non-complementary technologies. At the same time, we consider that technological consistency simplifies overall design by taking advantage of existing mechanisms, procedures and interfaces, thus reducing somehow the device implementation costs.

[Seite 28]

Not all these criteria are equally important, but depending on the desired strengths of the resulting architecture some of them must be promoted. We will focus primarily on maximising decentralisation, reasonability, contextawareness and, in a lesser extent, technological consistency.

Anmerkungen

Ein Verweis auf die Quelle fehlt.

In der untersuchten Arbeit findet man eine angepasste und gekürzte Version der entsprechenden Passage in der ungenannten Quelle.

Sichter
(Hindemith), SleepyHollow02

[3.] Saa/Fragment 043 01 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:10:11 Hindemith
Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Vazquez 2007, Verschleierung

Typus
Verschleierung
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 43, Zeilen: 1-2
Quelle: Vazquez 2007
Seite(n): 29, Zeilen: 1 ff.
Table 3.1 enumerates the criteria with relative weights depending on their importance to our goals.

Table 3.1: Criteria's relative weights of importance

Saa 043a diss.png

Table 2.1 enumerates the criteria with relative weights depending on their importance to our goals.

Saa 043a source.png

Table 2.1: Criteria’s relative weights of importance.

Anmerkungen

Ein Verweis auf die Quelle fehlt.

Dies ist das Ende einer längeren Übernahme von der Vorseite: Fragment 042 01‎‎.

Sichter
(Hindemith), SleepyHollow02

[4.] Saa/Fragment 050 03 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:02:07 Hindemith
Fragment, Gesichtet, KomplettPlagiat, SMWFragment, Saa, Schutzlevel sysop, Vazquez 2007

Typus
KomplettPlagiat
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 50, Zeilen: 3-30
Quelle: Vazquez 2007
Seite(n): 38, 39, Zeilen: 38: 4 ff.; 39: 1ff.
3.4 Task Computing

Task Computing3 (TC) technology is a joint effort by Fujitsu Laboratories of America and the MINDSWAP group, devoted to Semantic Web research, at the University of Maryland Institute for Advanced Computer Studies. The goal of TC is to "fill the gap between the tasks that users want to perform and the services that constitute available actionable functionality" [76]. TC presumes initially that users do not know how to achieve their goals when using computing facilities due to increased complexity at computing environments and tasks, and tries to ease the process by providing the user with an intelligent aid that hides the complexity of coordinating existing devices and services.

TC provides dynamic service discovery, service publishing and management, task creation and execution on the fly [77]. It even assists users in discovering what their goals are by suggesting possible tasks that can be performed with available facilities. All these features try to solve the frustration of users in application-rich environments, where they have to orchestrate a variety of devices and applications. Using Task Computing they can focus on their final goal and accomplish it with a reduced number of simple interactions.

Service composition can be seen as the "process of creating customized services from existing services by a process of dynamic discovery, integration and execution of those services in a planned order to satisfy a request from a client" [78]. Some examples of documented scenarios [79] that can be accomplished using TC technology are: exchanging business cards, showing and sharing a presentation, scheduling a future presentation or checking and printing directions to the airport. All of them are accomplished by sharing services on different devices and orchestrating those services to create a work flow in order to carry out the desired task. A prototype of TC has been implemented experimentally for Smart Conference Rooms and Home Multimedia Environments [80] and the first public results date back to 2003. It consisted in applying Semantic Web technologies to Pervasive Computing scenarios for semi-automatic composition of tasks, based on their previous research [77].


3 Task Computing - the Technology; http://taskcomputing.org/


[76] Ryusuke Masuoka, Yannis Labrou, Bijan Parsia, and Evren Sirin; Ontology-enabled pervasive computing applications, IEEE Intelligent Systems, 18(5): 68-72, September- October 2003.

[77] Evren Sirin, James Hendler, and Bijan Parsia. Semi-automatic composition of web services using semantic descriptions. In Web Services: Modeling, Architecture and Infrastructure workshop in ICEIS 2003, Angers, France, April 2003.

[78] Dipanjan Chakraborty, Filip Perich, Anupam Joshi, Tim Finin, and Yelena Yesha; A reactive service composition architecture for pervasive computing environments, Technical report, University of Maryland, Baltimore County, March 2002.

[79] Ryusuke Masuoka, Bijan Parsia, and Yannis Labrou; Task Computing - The Semantic Web meets Pervasive Computing. In Proceedings of 2nd International Semantic Web Conference (ISWC2003), Sanibel Island, Florida, October 2003.

[80] Zhexuan Song, Ryusuke Masuoka, Jonathan Agre, and Yannis Labrou; Task Computing for ubiquitous multimedia services. In MUM'04: Proceedings of the 3rd international conference on Mobile and ubiquitous multimedia, pages 257-262, New York, USA, 2004. ACM Press.

2.3 Task Computing

Task Computing is an ongoing joint effort by Fujitsu Laboratories of America and the MINDSWAP group, devoted to Semantic Web research, at the University of Maryland Institute for Advanced Computer Studies.

The goal of Task Computing is to “fill the gap between the tasks that users want to perform and the services that constitute available actionable functionality” [MLPS03]. Task Computing presumes initially that users do not know how to achieve their goals when using computing facilities due to increased complexity at computing environments and tasks, and tries to ease the process by providing the user with an intelligent aid that hides the complexity of coordinating existing devices and services.

Task Computing provides dynamic service discovery, service publishing and management, task creation and execution on the fly [SHP03]. It even assists users in discovering what their goals are by suggesting possible tasks that can be performed with available facilities.

All these features try to solve the frustration of users in application-rich environments, where they have to orchestrate a variety of devices and applications. Using Task Computing they can focus on their final goal and accomplish it with a reduced number of simple interactions.

Service composition can be seen as the “process of creating customized services from existing services by a process of dynamic discovery, integration

[Seite 39]

and execution of those services in a planned order to satisfy a request from a client” [CPJ+02].

Some examples of documented scenarios [MPL03] that can be accomplished using Task Computing technology are: exchanging business cards, showing and sharing a presentation, scheduling a future presentation or checking and printing directions to the airport. All of them are accomplished by sharing services on different devices and orchestrating those services to create a workflow in order to carry out the desired task. A prototype of Task Computing environment has been implemented experimentally for Smart Conference Rooms and Home Multimedia Environments [SMAL04] and the first public results date back to 2003, where the group of researchers led by Dr. Ryusuke Masuoka at Fujitsu Laboratories and Dr. James Hendler at the University of Maryland published several papers [MPL03, MLPS03, MMS+05] explaining the basics of their approach. It consisted in applying Semantic Web technologies to Pervasive Computing scenarios for semi-automatic composition of tasks, based on their previous research [SHP03].


[CPJ+02] Dipanjan Chakraborty, Filip Perich, Anupam Joshi, Tim Finin, and Yelena Yesha. A reactive service composition architecture for pervasive computing environments. Technical report, University of Maryland, Baltimore County, March 2002.

[MLPS03] Ryusuke Masuoka, Yannis Labrou, Bijan Parsia, and Evren Sirin. Ontology-enabled pervasive computing applications. IEEE Intelligent Systems, 18(5):68–72, September-October 2003.

[MMS+05] Ryusuke Masuoka, MohinderChopra, Zhexuan Song, Yannis Labrou, Lalana Kagal, and Tim Finin. Policy-based access control fortask computing using rei. In Proceedings of the Policy Management for theWeb Workshop, WWW2005, pages 37–43. W3C, May 2005.

[MPL03] Ryusuke Masuoka, Bijan Parsia, and Yannis Labrou. Task computing - the semantic web meets pervasive computing. In Proceedings of 2nd International Semantic Web Conference (ISWC2003), Sanibel Island, Florida, October 2003.

[SHP03] Evren Sirin, James Hendler, and Bijan Parsia. Semi-automatic composition of web services using semantic descriptions. In Web Services: Modeling, Architecture and Infrastructure workshop in ICEIS 2003, Angers, France, April 2003.

[SMAL04] Zhexuan Song, Ryusuke Masuoka, Jonathan Agre, and Yannis Labrou. Task computing for ubiquitous multimedia services. In MUM ’04: Proceedings of the 3rd international conference on Mobile and ubiquitous multimedia, pages 257–262, New York, NY, USA, 2004. ACM Press.

Anmerkungen

Ein Verweis auf die Quelle fehlt.

Sichter
(Hindemith), SleepyHollow02

[5.] Saa/Fragment 051 01 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:02:10 Hindemith
Fragment, Gesichtet, KomplettPlagiat, SMWFragment, Saa, Schutzlevel sysop, Vazquez 2007

Typus
KomplettPlagiat
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 51, Zeilen: 1 ff. (komplett)
Quelle: Vazquez 2007
Seite(n): 39, 40, Zeilen: 39: 25 ff.; 40: 1 ff.
Saa 051a diss.png

Figure 3.4: General Architecture of Task Computing Environment

3.4.1 Task Computing Architecture

Fig. 3.4 shows the TC architecture [81], which is composed of four different layers, performing complementary activities:

  • Realization Layer: It is the bottommost layer, directly representing available facilities. There are three different types of entities at this layer: devices, applications and e-services over the Web.
  • Service Layer: The available facilities from the Realization Layer are embodied into the form of service at this layer and services interfaces are constructed. Semantic Service Descriptions (SSD) comprising knowledge about these services are also created in order to disseminate information.
  • Middleware Layer: This layer is in charge of service discovery, service composition and execution, and other management activities such as Service Publishing. In some way, it glues services created at the Service Layer with available underlaying technologies to support transport and management functions over them.
  • Presentation Layer: It is considered to be the most important layer in the architecture. It provides the user with an abstraction of available tasks that can be performed in the environment, hiding underneath complexity, and allowing the user [to dynamically assemble components to perform the desired task.]

[81] Zhexuan Song, Yannis Labrou, and Ryusuke Masuoka; Dynamic service discovery and management in Task Computing. In First Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous'04), pages 310-318, 2004.

2.3.1 Task Computing architecture

The Task Computing architecture is composed of four different layers, performing complementary activities:

  • Realization layer: it is the bottommost layer, directly representing available facilities. There are three different types of entities at this layer: devices, applications and e-services over the Web.
  • Service layer: available facilities from the Realization layer are embodied into the form of service at this layer and services interfaces are constructed. Semantic Service Descriptions (SSD) comprising knowledge about these services are also created in order to disseminate information.
  • Middleware layer: this layer is in charge of service discovery, service composition and execution, and other management activities such as

[Seite 40]

Saa 051a source.png

Figure 2.8: Task Computing architecture. Source: [SLM04].

service publishing. In some way, it glues services created at the Service layer with available underlaying technologies to support transport and management functions over them.

  • Presentation layer: it is considered the most important layer in the architecture. It provides the user with an abstraction of available tasks that can be performed in the environment, hiding underneath complexity, and allowing the user to dynamically assemble components to perform the desired task.

[SLM04] Zhexuan Song, Yannis Labrou, and Ryusuke Masuoka. Dynamic service discovery and management in task computing. In First Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous’04), pages 310–318, 2004.

Anmerkungen

Ein Verweis auf die Quelle fehlt.

Sichter
(Hindemith), SleepyHollow02

[6.] Saa/Fragment 052 01 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:02:14 Hindemith
Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Vazquez 2007, Verschleierung

Typus
Verschleierung
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 52, Zeilen: 1 ff. (komplett)
Quelle: Vazquez 2007
Seite(n): 40, 43-45, Zeilen: 40: 8 ff.; 43: 7 ff.; 44: 1 ff.; 45: 1 ff.
A client implementing the Presentation Layer is usually referred to as Task Computing Client (TCC) and makes use of well-defined interfaces to the Middleware Layer.

Task Computing is implemented in concrete Task Computing Environments (TCEs), which are computational systems able to perform Task Computing functionality and composed of Task Computing Clients, Semantic Service Descriptions, Semantic Service Discovery Mechanisms and Service Controls. The detailed information about all of these components is given in the afore-mentioned literature.

3.4.2 Conclusion

Task Computing is primarily a framework for services orchestration, composition, and execution. All the mechanisms it features are aimed at service publishing and discovery, semantic descriptions, service-ization of resources to make them available to any requester, and so forth. These features can be implemented in multiple environments, not being specially addressed for Ubiquitous Computing scenarios. In fact, Task Computing applies well-known Internet-wide technologies such as UDDI for discovery or traditional Web Services at external servers as endpoints. In order to assume a more context-aware nature, Task Computing has embraced some pervasive computing technologies to complement existing ones, such as UPnP's Simple Service Discovery Protocol (SSDP) for discovery, so services can be found both at a global level via UDDI and at a local level via the group by subnet discovery range.

The following sections provide analysis of Task Computing technology against our defined evaluation criteria, and the conclusion is summarized in Table 3.4.

  • Decentralization: Task Computing is not aimed at creating a network of interconnected devices. The TCEs are intended to run in desktop computers or servers that can be connected to UPnP or Jini networks if device control is required. Low.
  • Lightness: The processes such as semanticization and serviceization as well as the need of the Task Computing Client result in complex and heavy software components. The devices need an amount of computing resources (i.e. processing power and screen size) presently not available in every embedded platform. Low.
  • Standards Adherence: In general, Task Computing honors the existing standards and technologies, i.e. OWL-S, WSDL, HTTP, UDDI, and even industry de facto standards such as SSDP. High.
  • Technological Consistency: Task Computing applies Web Services and Semantic Web technologies in a coherent and synergistic manner. High.
  • Reasoning Capability: Task Computing uses semantic information to annotate service descriptions and perform service composition, but neither reasoning nor domain ontologies are provided to understand context information. Low.
  • Context Awareness: No form of capturing context or sensing environmental conditions are provided directly by Task Computing, except for service discovery mechanisms which is a technical issue and not related to context-awareness. Low.
A client implementing the Presentation layer is usually referred to as Task Computing Client (TCC) and makes use of well-defined interfaces to the Middleware layer.

Task Computing is implemented in concrete TCEs (Task Computing Environments), which are computational systems able to perform Task Computing functionality and composed of Task Computing Clients, Semantic Service Descriptions, Semantic Service Discovery Mechanisms and Service Controls.

[Seite 43]

2.3.3 Conclusion

Task Computing is primarily a framework for services orchestration, composition, and execution. All the mechanisms it features are aimed at this goal: service publishing and discovery, semantic descriptions, service-ization of resources to make them available to any requester, and so forth. These features can be implemented in multiple environments, not being specially addressed for Ubiquitous Computing scenarios. In fact, Task Computing

[Seite 44]

applies well-known Internet-wide technologies such as UDDI for discovery or traditional Web Services at external servers as endpoints.

In order to assume a more context-aware nature, Task Computing has embraced some pervasive computing technologies to complement existing ones, such as SSDP for discovery, so services can be found both at a global level via UDDI and at a local level via the group by subnet discovery range. [...]

[...]

An analysis of Task Computing against the evaluation criteria leads to the following results:

Decentralisation: Task Computing is not aimed at creating a network of interconnected devices. The TCEs are intended to run in desktop computers or servers that can be connected to UPnP or Jini networks if device control is required. Low.

Reasonability: Task Computing uses semantic information to annotate service descriptions and perform service composition, but neither reasoning nor domain ontologies are provided to understand context information. TC only is aimed at matching required and offered services. Low.

[Seite 45]

Context-awareness: except for service discovery mechanisms (which strictly is a technical issue, not related to context-awareness), no other form of capturing context, sensing environmental conditions, and so forth, are provided directly by Task Computing. No form of automatic responsive behaviour is provided in the model, but user intervention is required. Low.

Technological Consistency: Task Computing applies web services and Semantic Web technologies in a coherent and synergistic manner. High.

Standards Adherence: in general terms, Task Computing honours standards and recommendations trying to reuse existing technologies. Standards such as OWL-S, WSDL, HTTP, UDDI, and even industry de facto standards such as SSDP are widely used. High.

[...]

Lightness: processes such as Semantic-ization and Service-ization as well as the need of the Task Computing Client, result in complex and heavy software components. Devices need an amount of computing resources (processing power and screen size, among others) not presently available in every embedded platform. Low.

Anmerkungen

Ein Verweis auf die Quelle fehlt.

Auch die "analysis of Task Computing technology against our defined evaluation criteria" ist identisch zur Quelle

Sichter
(Hindemith), SleepyHollow02

[7.] Saa/Fragment 053 01 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:02:17 Hindemith
Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Vazquez 2007, Verschleierung

Typus
Verschleierung
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 53, Zeilen: 1 ff. (komplett)
Quelle: Vazquez 2007
Seite(n): 46, 54, 55, Zeilen: 46: Tabelle; 54: letzter Abschnitt; 55: 1 ff.
Table 3.4: Analysis of Task Computing against the evaluation criteria

Saa 053a diss.png

3.5 Gaia

Since 2001, the research group at the Department of Computer Science of the University of Illinois at Urbana-Champaign, led by Dr. Roy H. Campbell has been working on the design of an infrastructure to support intelligent Ubiquitous Computing environments. The Gaia project is the result of these efforts, constituting a software infrastructure to support Active Spaces. An active space is a "model that maps the abstract perception of a physical space as a computing system, into a first class software entity" [82].

Thus, the active space acts as a mapping between the real and virtual space, connecting both in such a way that real world actions affect virtual world objects and vice versa. The active space hides the complexity of the real world elements into one unique entity that provides functions for manipulating the space, discovering and locating internal entities, storing and retrieving information from the space and so forth. The name Gaia was adopted from the Gaia theory by James Lovelock that advocated for the earth as a self-regulated super-organism, who in turn borrowed it from the Greek Earth Goddess. The Gaia project tried to replicate the same global awareness and self-regulated behavior for smart environments and their constituent elements.

3.5.1 Gaia Architecture

The Gaia Operating System (Gaia OS) is the core element of the whole architecture, which is defined as a meta-operating system, running at the top of others and providing a distributed communication model for coordinating active spaces [83]. Gaia is composed of three main components, as shown in Fig. 3.5.

  • Gaia Kernel: It provides basic services such as component life-cycle management or remote component execution and management. Gaia relies on CORBA as underlying distributed component model, and extends some CORBA services to provide the so-called Gaia services, such as Event Service, Context Service, Presence Service, Space Repository and Context File System.
  • Application Framework: It consists of a distributed component-based infrastructure following the MVC (Model View Controller ) model, including new functionality to manipulate component bindings, a mapping mechanism and policies/ rules for application customization.
  • Active Space Applications: These applications implement the desired functional behavior in the active space, such as the Presentation Manager application that lets the users present slides in multiple displays simultaneously, move slides from one display to another, as well as move the input device functionality.

[82] Manuel Román and Roy H. Campbell; Gaia: Enabling Active Spaces, In Proceedings of the 9th workshop on ACM SIGOPS European workshop, pages 229-234, New York, NY, USA, 2000.

[83] Manuel Román, Christopher Hess, Renato Cerqueira, Anand Ranganathan, Roy H. Campbell, and Klara Nahrstedt; A middleware infrastructure for active spaces; IEEE Pervasive Computing, 1(4): 74-83, 2002.

[Seite 46]

Saa 053a source.png

Table 2.3: Analysis of Task Computing against the evaluation criteria.

[Seite 54]

2.5 Gaia

Since 2001, the research group at the Department of Computer Science of the University of Illinois at Urbana-Champaign, led by Dr. Roy H. Campbell

[Seite 55]

has been working on the design of an infrastructure to support intelligent Ubiquitous Computing environments.

The Gaia project is the result of these efforts, constituting a software infrastructure to support Active Spaces. An active space is a “model that maps the abstract perception of a physical space as a computing system, into a first class software entity” [RC00].

Thus, the active space acts as a mapping between the real and virtual space, connecting both in such a way that real world actions affect virtual world objects and vice versa. The active space hides the complexity of the real world elements into one unique entity that provides functions for manipulating the space, discovering and locating internal entities, storing and retrieving information from the space and so forth.

[...]

The name Gaia was adopted from the Gaia theory by James Lovelock that advocated for the earth as a self-regulated superorganism, who in turn borrowed it from the Greek Earth Goddess. The Gaia project tried to replicate the same global awareness and self-regulated behaviour for smart environments and their constituent elements.

2.5.1 Gaia architecture

The Gaia Operating System (Gaia OS) is the core element of the whole architecture. It is defined as a meta-operating system, running at the top of others, providing a distributed communication model for coordinating active spaces [RHC+02b].

[Seite 55]

Gaia is composed of three main components as shown in Figure 2.14:

• Gaia kernel: provides basic services such as component life-cycle management or remote component execution and management. Gaia relies on CORBA as underlying distributed component model, and extends some CORBA services to provide the so-called Gaia services, such as Event service, Context service, Presence Service, Space repository and Context file system.

• Application framework: consists of a distributed component-based infrastructure following the MVC model, including new functionality to manipulate component bindings, a mapping mechanism and policies/rules for application customisation.

• Active Space Applications: implement the desired functional behaviour in the active space, such as the Presentation manager application, that lets users present slides in multiple displays simultaneously, move slides from one display to another, as well as move the input device functionality.


[RC00] Manuel Rom´an and Roy H. Campbell. Gaia: enabling active spaces. In Proceedings of the 9th workshop on ACM SIGOPS European workshop, pages 229–234, New York, NY, USA, 2000. ACM Press.

[RHC+02b] Manuel Rom´an, Christopher Hess, Renato Cerqueira, Anand Ranganathan, Roy H. Campbell, and Klara Nahrstedt. A middleware infrastructure for active spaces. IEEE Pervasive Computing, 1(4):74–83, 2002.

Anmerkungen

Ein Verweis auf die Quelle fehlt.

Sichter
(Hindemith), SleepyHollow02

[8.] Saa/Fragment 054 01 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:02:21 Hindemith
Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Vazquez 2007, Verschleierung

Typus
Verschleierung
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 54, Zeilen: 1 ff. (komplett)
Quelle: Vazquez 2007
Seite(n): 56, 57, Zeilen: 56: 17 ff.; 57: 1 ff.
Saa 054a diss.png

Figure 3.5: General Architecture of Gaia

The mapping mechanism of the Application Framework offers the possibility of describing requirements to find the suitable real device to assign a functional behavior (for example, audio output) so that matching devices can be found within the active space to perform that function during a task. The interesting part is how Gaia represented context in the form of a 4-components structure: Context(<ContextType>, <Subject>, <Relater>, <Object>) that in many ways resembles that of the Semantic Web, for example: Context(locatedIn; CoaguChekS; is; RoomLab123). Later, this model evolved into a predicate-based representation of context information:

  • Location(CoaguChekS; isOperating; RoomLab123)
  • InternetConnectionStatus(Gateway; is; OffLine)
  • User(Safdar; role; Admin)

During 2003, Gaia was extended with a semantic middleware layer for context awareness endorsing existing Semantic Web technologies in order to model and annotate context information, perform reasoning and carry out reactive behavior in response to context changes [84]. DAML+OIL (later OWL) was selected to represent the context information following a predicate model. In order to map the predicates onto the ontology, an ontology class is created for each predicate structure. So, the above-mentioned Location predicate becomes a Location ontology class with three possible relationships to denote the information that was previously enclosed in the predicate parameters.

Representing the context in this way, operations such as search, querying, fusion and so forth, become possible. There are several different entities involved in Gaia's context information infrastructure, as depicted in Fig. 3.6.

  • Context Providers: These are the sources of context information, probably obtained by sensors.
  • Context Synthesizers: They retrieve context information from different providers and perform some form of reasoning to infer new information making it available to other agents. Both static rules and machine learning techniques (such as Naive Bayes) can be applied to obtain new information.

[84] Anand Ranganathan and Roy H. Campbell; A middleware for context-aware agents in ubiquitous computing environments; In Proceedings of the ACM/IFIP/USENIX International Middleware Conference, 2003.

Saa 054a source.png

Figure 2.14: Gaia architecture. Source: [RHC+02b].

The mapping mechanism of the Application framework offers the possibility of describing requirements to find the suitable real device to assign a functional behaviour (for example, audio output) so that matching devices can be found within the active space to perform that function during a task.

Specially interesting is how Gaia represented context in the form of a 4-components structure: Context(<ContextType>, <Subject>, <Relater>, <Object>) that in many ways resembles that of the Semantic Web, for example: Context(temperature, roomlab21, is, 24 C) .

[Seite 57]

Later, this model evolved into a predicate-based representation of context information:

• Location(inaki, entering, roomlab21)

• Temperature(roomlab21, ‘‘=’’, 24 C)

• TVStatus(smallTV, is, off)

During 2003, Gaia was extended with a semantic middleware layer for context awareness endorsing existing Semantic Web technologies in order to model and annotate context information, perform reasoning and carry out reactive behaviour in response to context changes [RC03b]. DAML+OIL (later OWL) was selected to represent the context information following a predicate model [MRCM03b] [MRMC03].

In order to map the predicates onto the ontology, an ontology class is created for each predicate structure [RC03a]. So, the Location predicate becomes a Location ontology class with three possible relationships to denote the information that was previously enclosed in the predicate parameters [MRCM03b].

Representing the context in this way, operations such as search, querying, fusion and so forth, become possible.

There are several different entities involved in Gaia’s context information infrastructure depicted in Figure 2.15:

• Context Providers: they are sources of context information, probably obtained by sensors.

• Context Synthesisers: they retrieve context information from different providers and perform some form of reasoning to elicit new information making it available to other agents. Both static rules and machine learning techniques (such as Naïve Bayes) can be applied to obtain new information.


[MRCM03b] Robert E. McGrath, Anand Ranganathan, Roy H. Campbell, and M. Dennis Mickunas. Use of ontologies in pervasive computing environments. Technical Report Technical Report UIUCDCS-R-2003-2332, University of Illinois at Urbana-Champaign, April 2003.

[MRMC03] Robert E. McGrath, Anand Ranganathan, M. Dennis Mickunas, and Roy H. Campbell. Investigations of semantic interoperability in ubiquitous computing environments. In Proceedings of the 15th International Conference Parallel and Distributed Computing and Systems (PDCS), 2003.

[RC03a] Anand Ranganathan and Roy H. Campbell. An infrastructure for context-awareness based on first order logic. Personal and Ubiquitous Computing, 7(6):353–364, 2003.

[RC03b] Anand Ranganathan and Roy H. Campbell. A middleware for context-aware agents in ubiquitous computing environments. In Proceedings of the ACM/IFIP/USENIX International Middleware Conference, 2003.

[RHC+02b] Manuel Román, Christopher Hess, Renato Cerqueira, Anand Ranganathan, Roy H. Campbell, and Klara Nahrstedt. A middleware infrastructure for active spaces. IEEE Pervasive Computing, 1(4):74–83, 2002.

Anmerkungen

Ein Verweis auf die Quelle fehlt.

Sichter
(Hindemith), SleepyHollow02

[9.] Saa/Fragment 055 01 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:09:50 Hindemith
Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Vazquez 2007, Verschleierung

Typus
Verschleierung
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 55, Zeilen: 1 ff (komplett)
Quelle: Vazquez 2007
Seite(n): 57, 58, 60, 61, Zeilen: 57: 28 ff.; 58: 1 ff.; 60: 14 ff.; 61: 1 ff.
Saa 055a diss.png

Figure 3.6: The Context Infrastructure in Gaia

• Context Consumers: They gather context information from providers and synthesizers, reason about it and perform reactive behavior accordingly.

• Context Provider Lookup Service: It is used by the context providers, one per environment, in order to publish the kind of context information they provide in order to be found by context consumers.

• Context History Service: It contains database records, one per environment, of the past context information to make them available to the requesting parties.

• Ontology Server: It stores ontologies, one per environment, for different types of information.

3.5.2 Conclusion

Gaia fulfills many of the requirements established for a smart Ubiquitous Computing architecture, mainly those related to intelligence support. It makes use of context predicates for representing context information and OWL ontologies for taxonomical purposes. However, Gaia has two important drawbacks and several inconsistencies. The first main drawback is that, as a requisite, three different elements in the architecture must be deployed and properly configured in the environment: the Context Provider Lookup Service, the Context History Service and the Ontology Server. This constraint prevents Gaia from creating spontaneous emergent pervasive computing environments anywhere, since a deployment phase must me performed beforehand, enforcing an undesirable centralization. The second main disadvantage arises from the fact that core elements in the architecture, such as those three mentioned above, seem to be suitable for installation in desktop computers or servers, but not in embedded computers.

The main inconsistencies with Gaia are originated from the initial selection of technologies and the subsequent integration of newer ones, that result in a strange mixture. For instance, representation of context information through predicates was present at the very initial stages, but when OWL ontologies were integrated in Gaia, context predicates remained as knowledge representation mechanisms instead of shifting to RDF, which [could have sound more sensible.]

• Context Consumers: they gather context information from providers and synthesisers, reason about it and perform reactive behaviour accordingly.

• Context Provider Lookup Service: one per environment, it is used by context providers to publish the kind of context information they provide in order to be found by context consumers.

• Context History Service: one per environment, it contains database records of past context information to make them available to requesting parties.

[Seite 58]

• Ontology Server: one per environment, stores ontologies for the different information types.

Saa 055a source.png

Figure 2.15: Gaia Context Infrastructure. Source: [RAMC04].

[Seite 60]

2.5.3 Conclusion

Gaia fulfils many of the requirements established for a smart Ubiquitous Computing architecture, mainly those related to intelligence support. Gaia makes use of context predicates for representing context information and OWL ontologies for taxonomical purposes.

[...]

However, Gaia has two important drawbacks and several inconsistencies.

The first main drawback is that Gaia requires three different elements in the architecture to be previously deployed and properly configured in the environment: the Context Provider Lookup Service, the Context History Service and the Ontology Server. This constraint prevents Gaia from creating spontaneous emergent pervasive computing environments anywhere, since a deployment phase must me performed beforehand, enforcing an undesirable centralisation.

The second main disadvantage arises from the fact that core elements in the architecture, such as those three mentioned above, seem to be suitable for installation in desktop computers or servers, but not in embedded computers. [...]

The main inconsistencies with Gaia are originated from the initial selection of technologies and the subsequent integration of newer ones, that result in a strange mixture.

[Seite 61]

For instance, representation of context information through predicates was present at the very initial stages. When OWL ontologies were integrated in Gaia, context predicates remained as knowledge representation mechanisms instead of shifting to RDF, which would have sound more sensible.


[...]

Anmerkungen

Ein Verweis auf die Quelle fehlt.

Sichter
(Hindemith), SleepyHollow02

[10.] Saa/Fragment 056 01 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:09:53 Hindemith
Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Vazquez 2007, Verschleierung

Typus
Verschleierung
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 56, Zeilen: 1-24
Quelle: Vazquez 2007
Seite(n): 61, 62, Zeilen: 61: 6 ff.; 62: 11 ff.
Another strange mixture is related to the communication model, where Gaia uses CORBA as distributed computing architecture instead of the Web-based model.

The following sections provide analysis of Gaia against our defined evaluation criteria, and the conclusion is summarized in Table 3.5.

  • Decentralization: The prerequisite of deployment of three main components in the environment leads towards a centralized architecture in Gaia. Low.
  • Lightness: Some elements in the architecture are difficult to migrate to resource-constrained devices, such as the Context History Service or the Ontology Server. The Gaia architecture does not seem to be deployed on embedded devices, but in desktop computers. Low.
  • Standards Adherence: The standards and recommendation, i.e. CORBA and OWL are honored. High.
  • Technological Consistency: The technological evolution during the Gaia project resulted in lot of changes as new technologies were adopted, which created a strange mixture in the final outcome. The OWL is combined with predicate logics, instead of shifting to RDF. CORBA is applied as distributed computing architecture instead of newer more lightweight web-based communication models that would make the Semantic Web fit better. Low.
  • Reasoning Capability: The application of ontologies, rules, probabilistic logic, fuzzy logic and Bayesian networks in order to perform all sorts of reasoning about context information, promotes a very high degree of intelligence in Gaia. Very High.
  • Context Awareness: The integration of rules and confidence values contribute to situation identification and subsequent adaptation. High.

Table 3.5: Analysis of Gaia against the evaluation criteria

Saa 056a diss.png

Another strange mixture is related to the communication model. Gaia uses CORBA as distributed computing architecture, instead of the web model. [...]

An analysis of Gaia against the evaluation criteria leads to the following results:

Decentralisation: the requirement about a previous three-elements deployment in the environment contributes to a centralised architecture in Gaia. Low.

Reasonability: the application of ontologies, rules, probabilistic logic, fuzzy logic and Bayesian networks in order to perform all sorts of reasoning about context information, promotes a very high degree of intelligence in Gaia. Very High.

Context-awareness: the integration of rules and confidence values contribute to situation identification and subsequent adaptation. High.

Technological Consistency: technological evolution during the Gaia project, resulting in changes as new technologies were adopted, has created a strange mixture in the final outcome. OWL is combined with predicate logics, instead of shifting to RDF. CORBA is applied as distributed computing architecture instead of newer more lightweight web-based communication models that would make the Semantic Web fit better. [...] Low.

Standards Adherence: standards and recommendations such as CORBA and OWL are honoured. High.

[Seite 62]

Lightness: some elements in the architecture are difficult to migrate to resource-constrained devices, such as the Context History Service or the Ontology Server. The Gaia architecture does not seem to be intended for deployment in embedded devices, but in full computers. Low.

Saa 056a source.png

Table 2.5: Analysis of Gaia against the evaluation criteria.

2.6 Semantic

Anmerkungen

Ein Verweis auf die Quelle fehlt. Auch die "analysis of Gaia against our defined evaluation criteria" stammt aus der Quelle.

Sichter
(Hindemith), SleepyHollow02

[11.] Saa/Fragment 097 01 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:10:00 Hindemith
Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Vazquez 2007, Verschleierung

Typus
Verschleierung
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 97, Zeilen: 1 ff. (komplett)
Quelle: Vazquez 2007
Seite(n): 98, Zeilen: 1 ff.
Table 6.1: Comparison of SMDDP with State-of-the-art Discovery Protocols

Saa 097a diss.png

Saa 097a source.png

Table 3.1: Comparison of current discovery systems and mRDP.

Anmerkungen

Ein Verweis auf die Quelle fehlt.

Das Fragment ist im Zusammenhang mit Saa/Fragment 098 07 zu beurteilen.

Sichter
(Hindemith), SleepyHollow02

[12.] Saa/Fragment 098 07 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:09:57 Hindemith
Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Vazquez 2007, Verschleierung

Typus
Verschleierung
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 98, Zeilen: 7-22
Quelle: Vazquez 2007
Seite(n): 96, 97, Zeilen: 96: 7 ff.; 97: 1 ff.
6.5.2 Comparative Analysis

SMDDP provides a simple and powerful way for the semantic discovery of ambient intelligent medical devices in pervasive (healthcare) environments, utilizing and exploiting the advantages of HTTP protocol. Although, several discovery mechanisms for pervasive computing have been proposed in the past, but none of them is widely adopted. Edwards has published a comparative study [111] about SSDP, Jini, Bluetooth SDP, SLP, Bonjour, Salutation, INS and Ninja SSDS, including also infrared and RFID mechanisms. The comparison was based on different parameters, i.e. topology, transport, scope, search and security.

Table 6.1 shows a reproduction of the Edwards' comparison table with the additional row of SMDDP, which exhibits some distinct factors by comparing it with other alternatives, such as its powerful semantic discovery capabilities and the use of widely-adopted and reliable HTTP-based security mechanisms. This comparison shows and promotes SMDDP to be the best candidate for the semantic discovery of ambient intelligent medical devices in pervasive computing scenarios within the healthcare domain, and also a valuable and promising alternative in other networking environments as well.


[111] W. Keith Edwards, Discovery Systems in Ubiquitous Computing, IEEE Pervasive Computing, 5(2): 70-77, 2006.

3.8 Comparative analysis

mRDP provides a simple and powerful way for performing semantic queries in Ubiquitous Computing environments, taking advantage and reusing HTTP infrastructure. Several discovery mechanisms for Ubiquitous Computing have been proposed in the past, none of them widely accepted. Edwards published a comparative [Edw06] about SSDP, Jini, Bluetooth SDP, SLP, Bonjour, Salutation, INS and Ninja SSDS, including also infrared and RFID mechanisms. The comparison was based on the criteria of topology, transport, scope, search and security.

[Seite 97]

We reproduce in Table 3.1 the comparison table with an additional row for mRDP5.

mRDP exhibits some distinct factors from other alternatives, such as its powerful semantic search capabilities, and the use of well-proven and reliable HTTP-based security infrastructure.

We deem mRDP to be the best candidate for intelligent discovery in pervasive computing scenarios, and also a valuable and promising alternative in other networking environments.


5 The rows for eSquirt (infrared) and RFID are not included, since they are not relevant for the current research.


[Edw06] W. Keith Edwards. Discovery systems in ubiquitous computing. IEEE Pervasive Computing, 5(2):70–77, 2006.

Anmerkungen

Ein Verweis auf die Quelle fehlt.

Sichter
(Hindemith), SleepyHollow02

Auch bei Fandom

Zufälliges Wiki