VroniPlag Wiki

This Wiki is best viewed in Firefox with Adblock plus extension.

MEHR ERFAHREN

VroniPlag Wiki
Semantic Interoperability of Ambient Intelligent Medical Devices and e-Health Systems

von Dr. Safdar Ali

vorherige Seite | zur Übersichtsseite | folgende Seite

Statistik und Sichtungsnachweis dieser Seite findet sich am Artikelende

[1.] Saa/Fragment 023 01 - Diskussion
Zuletzt bearbeitet: 2015-05-17 09:54:24 Hindemith
BauernOpfer, Fragment, Gesichtet, Klusch 2008, SMWFragment, Saa, Schutzlevel sysop

Typus
BauernOpfer
Bearbeiter
Hindemith
Gesichtet
Yes
Untersuchte Arbeit:
Seite: 23, Zeilen: 1-4
Quelle: Klusch 2008
Seite(n): 57, Zeilen: 1 ff.
[WSML-Full shall] unify the DL and LP paradigms as a superset of FOL with non-monotonic extensions to support nonmonotonic negation of WSML-Rule via Default Logic, Circumscription or Autoepistemic Logic. However, neither syntax nor semantics of WSML-Full have been completely defined yet. 5. WSML-Full shall unify the DL and LP paradigms as a superset of FOL with non-monotonic extensions to support the nonmonotonic negation of WSML-Rule via Default Logic, Circumscription or Autoepistemic Logic. However, neither syntax nor semantics of WSML-Full have been completely defined yet.
Anmerkungen

Fortsetzung von Saa/Fragment 022 26. Ohne direkten Hinweis auf eine Übernahme.

Auf Seite 20 (Z. 4-6) wird eine von Matthias Klusch verfasste Quelle erwähnt: "In the following sections, we briefly describe these approaches by taking the text snippets from [43], and refer the reader to this for detailed description."


[43] Matthias Klusch, On Agent-Based Semantic Service Coordination, Cumulative Habilitation Script 2008.

Sichter
(Hindemith), SleepyHollow02


[2.] Saa/Fragment 023 08 - Diskussion
Zuletzt bearbeitet: 2015-05-17 13:38:35 Schumann
BauernOpfer, Bishaj 2007, Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop

Typus
BauernOpfer
Bearbeiter
Hindemith
Gesichtet
Yes
Untersuchte Arbeit:
Seite: 23, Zeilen: 8-45
Quelle: Bishaj 2007
Seite(n): 2, 3, Zeilen: 2: r. Spalte: 31ff; 3: l. Spalte: 1ff
2.5.1 Universal Plug and Play

Universal Plug and Play (UPnP) [56] is an industry initiative by Mirosoft [sic] to provide simple, robust, peer-to-peer connectivity among devices and PCs. Plug and Play (PnP) made it easier to setup, configure, and add peripherals to a PC, while the purpose of UPnP is to extend this simplicity throughout the network, enabling discovery and control of devices. Its target is zero configuration, invisible networking, as well as automatic discovery for the devices of many vendors. UPnP encompasses many existing, as well as new scenarios, such as home automation, printing, audio/video entertainment, kitchen appliances, etc., and is independent of operating systems, programming languages, or physical media.

The basic components of a UPnP network are: devices, services, and control points. A UPnP device contains services and nested devices. An XML device description document is hosted by each device; this document lists the set of services and properties of the device. A service is the smallest unit of control in UPnP. It is described in the XML document of the device, which also contains a pointer to the service description. A service consists of a state table, a control server, and an event server. The state table controls the state of the service through state variables. The control server updates the state according to action requests. The event server notifies interested subscribers when the service state changes. A controller is capable of discovering and controlling other devices. For true peer-to-peer functionality, devices should incorporate control point functionality. There is no central registry in UPnP, at least not necessarily.

UPnP uses many existing, standard protocols, so that UPnP devices can fit seamlessly and without effort into the existing networks. TCP/IP is the base on which the UPnP protocols are built, as well as many protocols that go with it, such as UDP, ARP, DHCP and DNS. HTTP is a core part of UPnP and its aspects are based on HTTP or its variants. The Simple Service Discovery Protocol (SSDP) defines how to find network services. It is both for control points to locate services on the network, as well as for devices to announce their availability. A UPnP control point, when booting up, can send a search request to discover devices and services. UPnP devices, on the other hand, listen on the multicast port. If the search criteria match, a unicast reply is sent. In the same way, a device, when plugged in, will send out multiple SSDP presence announcements. Apart from the leasing concept that UPnP also shares, SSDP provides a way for a device to notify that it is leaving the network.

The Generic Event Notification Architecture (GENA) defines the concepts of subscribers and publishers of notifications. The GENA formats are used to create these announcements that are sent using SSDP. SOAPis [sic] used in UPnP to execute remote procedure calls, as well as to deliver control messages and return results or error messages to the control points. XML is used in UPnP in device and service descriptions, control [messages and eventing.]


[56] UPnP Specification, http://www.upnp.org/ resources/default.asp

[Seite 2]

2.2 UPnP

UPnP [9] is an industry initiative by Mirosoft [sic] to provide simple, robust, peer-to-peer connectivity among devices and PCs. Plug and Play (PnP) made it easier to setup, configure, and add peripherals to a PC, while the purpose of UPnP is to extend this simplicity throughout the network, enabling discovery and control of devices. Its target is zero-configuration, invisible networking, as well as automatic discovery for the devices of many vendors. UPnP encompasses many existing, as well as new scenarios, such as home automation, printing, audio/video entertainment, kitchen appliances, etc. UPnP is independent of operating systems, programming languages, or physical media.

The basic components of a UPnP network are: devices, services, and control points. A UPnP device contains services and nested devices. An XML device description document is hosted by each device; this document lists the set of services and properties of the device. A service is the smallest unit of control in UPnP. It is described in the XML document of the device, which also contains a pointer to the service description. A service consists of a state table, a control server, and an event server. The state table controls the state of the service through state variables. The control server updates the state according to action requests. The event server notifies interested subscribers when the service state changes. A controller is capable of discovering and controlling other devices. For true peer-to-peer functionality, devices should incorporate control point functionality. There

[Seite 3]

is no central registry in UPnP, at least not necessarily [3, 5].

UPnP uses many existing, standard protocols, so that UPnP devices can fit seamlessly and without effort into the existing networks [9]. TCP/IP is the base on which the UPnP protocols are built, as well as many protocols that go with it, such as UDP, ARP, DHCP and DNS. HTTP is a core part of UPnP. All UPnP aspects are based on HTTP or its variants.

The Simple Service Discovery Protocol (SSDP) defines how to find network services [9]. It is both for control points to locate services on the network, as well as for devices to announce their availability. A UPnP control point, when booting up, can send a search request to discover devices and services. UPnP devices, on the other hand, listen on the multicast port. If the search criteria match, a unicast reply is sent. In the same way, a device, when plugged in, will send out multiple SSDP presence announcements. Apart from the leasing concept that UPnP also shares, SSDP provides a way for a device to notify that it is leaving the network.

The Generic Event Notification Architecture (GENA) defines the concepts of subscribers and publishers of notifications. The GENA formats are used to create these announcements that are sent using SSDP [14]. Simple Object Access Protocol (SOAP) [13] is used in UPnP to execute remote procedure calls, as well as to deliver control messages and return results or error messages to the control points. XML is used in UPnP in device and service descriptions, control messages and eventing.


[3] Adrian Friday, Nigel Davies, Nat Wallbank, Elaine Catterall and Stephen Pink. Supporting Service Discovery, Querying and Interaction in Ubiquitous Computing Environments. Wireless Networks 10, 631-641, 2004.

[5] Choonhwa Lee and Sumi Helal. Protocols for Service Discovery in Dynamic and Mobile Networks. International Journal of Computer Research, 2002.

[9] UPnP Device Architecture. http://www.upnp.org/download/ UPnPDA10\_20000613.htm,09 April 2007.

[13] W3C Recommendation. 24 June 2003. http://www.w3.org/TR/soap12-part1/, 9 April 2007.

[14] Universal Plug and Play in Windows XP. http://www.microsoft.com/technet/prodtechnol/ winxppro/evaluate/upnpxp.mspx, 9 April 2007.

Anmerkungen

Ein Verweis auf die Quelle findet sich am Anfang des Kapitels. Eine wörtliche Übernahme des gesamten Kapitels wird durch diesen aber in keiner Weise gekennzeichnet. Aus Microsoft wird in beiden Texten "Mirosoft".

Sichter
(Hindemith), Graf Isolan



vorherige Seite | zur Übersichtsseite | folgende Seite
Letzte Bearbeitung dieser Seite: durch Benutzer:Graf Isolan, Zeitstempel: 20141123171848