Fandom

VroniPlag Wiki

Quelle:Saa/Cabral et al 2004

< Quelle:Saa

31.268Seiten 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     Liliana Cabral, John Domingue, Enrico Motta, Terry Payne, Farshad Hakimpour
Titel    Approaches to Semantic Web Services: An Overview and Comparisons
Sammlung    The Semantic Web: Research and Applications. First European Semantic Web Symposium, ESWS 2004 Heraklion, Crete, Greece, May 10-12, 2004. Proceedings
Herausgeber    Christoph J. Bussler, John Davies, Dieter Fensel, Rudi Studer
Jahr    2004
Nummer    3053
Seiten    225-239
Reihe    Lecture Notes in Computer Science
ISBN    978-3-540-21999-6 (Print) 978-3-540-25956-5 (Online)
URL    http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.101.9487&rep=rep1&type=pdf, http://books.google.de/books?id=4MXr17IStGMC&pg=PA225#v=onepage&q&f=false
Webcite    http://www.webcitation.org/6SMIPP6E3

Literaturverz.   

ja
Fußnoten    ja
Fragmente    11


Fragmente der Quelle:
[1.] Saa/Fragment 009 16 - Diskussion
Zuletzt bearbeitet: 2014-11-23 04:52:54 Hindemith
BauernOpfer, Cabral et al 2004, Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop

Typus
BauernOpfer
Bearbeiter
Graf Isolan
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 9, Zeilen: 16-20, 23-26
Quelle: Cabral et al 2004
Seite(n): 225, Zeilen: 25-26, 30-37
2.1 Web Services

In recent years, distributed programming paradigms have been [sic] emerged that allow generic software components to be developed and shared. Although ideal for some enterprise integration and e-Commerce, it has only been with the adoption of XML as a common data syntax that the underlying principles have gained wide scale adoption, through the definition of Web Service standards. According to the definition of W3C, "A Web Service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts" [31].

Web Services are well defined, reusable, software components that perform specific, encapsulated tasks via standardized Web-oriented mechanisms. They can be discovered, invoked, and the composition of several services can be choreographed, using well defined workflow modeling frameworks.


[31] L. Cabral et al.; Approaches to Semantic Web Services: An Overview and Comparison [sic]; LNCS 3053, pp. 225-239, 2004

Approaches to Semantic Web Services: An Overview and Comparisons

[...]

1 Introduction

In recent years, distributed programming paradigms have emerged, that allow generic software components to be developed and shared. [...] Although ideal for some enterprise integration and eCommerce, it has only been with the adoption of XML as a common data syntax that the underlying principals [sic] have gained wide scale adoption, through the definition of Web Service standards. Web services are well defined, reusable, software components that perform specific, encapsulated tasks via standardized Web-oriented mechanisms. They can be discovered, invoked, and the composition of several services can be choreographed, using well defined workflow modeling frameworks.

Anmerkungen

Art und Umfang der Übernahme bleiben ungekennzeichnet.

Die als Zitat gekennzeichnete Definition ist zwar korrekt, findet sich allerdings nicht einmal annähernd in der genannten Quelle: Cabral et al. stellen nur fest (S. 227):
"A Web Service is a software program identified by an URI, which can be accessed via the internet through its exposed interface. The interface description declares the operations which can be performed by the service, the types of messages being exchanged during the interaction with the service, and the physical location of ports, where information should be exchanged."

Die zitierte Definition findet man z.B. hier.

Sichter
(Graf Isolan), Hindemith

[2.] Saa/Fragment 015 38 - Diskussion
Zuletzt bearbeitet: 2014-09-15 21:43:25 Singulus
Cabral et al 2004, Fragment, Gesichtet, KomplettPlagiat, SMWFragment, Saa, Schutzlevel sysop

Typus
KomplettPlagiat
Bearbeiter
Graf Isolan
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 15, Zeilen: 38-41
Quelle: Cabral et al 2004
Seite(n): 229, Zeilen: 9-13
2.3 Semantic Web

The Semantic Web [38] is a vision of a Web of meaningful contents and services, which can be interpreted by computer programs. It can also be seen as a vast source of information, which can be modeled with the purpose of sharing and reusing knowledge.


[38] T. Berners-Lee, J. Hendler and O. Lassila; The Semantic Web, Scientific American 284(5):34-43, 2001

3 The Semantic Web

The Semantic Web is a vision of a Web of meaningful contents and services, which can be interpreted by computer programs (see for example [1]). It can also be seen as a vast source of information, which can be modelled with the purpose of sharing and reusing knowledge.


1. Berners-Lee, T. Hendler, J., Lassila, O.: The Semantic Web. Scientific American, Vol. 284 (4). (2001) 34-43

Anmerkungen

Ohne Hinweis auf eine Übernahme.

Sichter
(Graf Isolan) Schumann

[3.] Saa/Fragment 016 01 - Diskussion
Zuletzt bearbeitet: 2014-09-15 21:44:23 Singulus
Cabral et al 2004, Fragment, Gesichtet, KomplettPlagiat, SMWFragment, Saa, Schutzlevel sysop

Typus
KomplettPlagiat
Bearbeiter
Graf Isolan
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 16, Zeilen: 1-24
Quelle: Cabral et al 2004
Seite(n): 229-230, Zeilen: 229: 18ff - 230: 1ff
[Figure 2.3: General stack of Semantic Web enabling standards]

The Semantic Web users will be able to do more accurate searches of the information and the services they need from the tools provided. The Semantic Web provides the necessary infrastructure for publishing and resolving ontological descriptions of terms and concepts. In addition, it provides the necessary techniques for reasoning about these concepts, as well as resolving and mapping between ontologies, thus enabling semantic interoperability of Web Services through the identification and mapping of semantically similar concepts. Fig. 2.3 shows the general stack of Semantic Web enabling standards. Ontologies have been developed within the Semantic Web research community in order to facilitate knowledge sharing and reuse. They provide greater expressiveness when modeling domain knowledge and can be used to communicate this knowledge between people and heterogeneous and distributed application systems. As with Web Services, Semantic Web enabling standards fit into a set of layered specifications built on the foundation of URIs and XML Schema. The current components included in the Semantic Web framework are RDF [39], RDF Schema (RDF-S) [40] and the Web Ontology Language (OWL) [41]. These standards build up a rich set of constructs for describing the semantics of online information sources.

RDF is an XML-based standard from W3C for describing resources on the Web. RDF introduces a little semantics to XML data by allowing the representation of objects and their relations through properties. RDF-Schema is a simple type system, which provides information (metadata) for the interpretation of the statements given in RDF data. The OWL facilitates greater machine interpretability of Web contents than RDF and RDF Schema by providing a much richer set of constructs for specifying classes and relations. OWL has evolved from existing ontologies languages and specifically from DAML+OIL [42].


[39] Klyne, G., et al. Resource description framework (RDF): Concepts and Abstract Ssyntax, W3C recommendation 2004, http://www.w3.org/TR/rdf-concepts/

[40] RDF Schema Description Language (RDF-S); http://www.w3.org/TR/rdf-schema/

[41] Web Ontology Language (OWL); http://www.w3.org/2004/OWL/

[42] DAML+OIL Ontology Markup Language; http://www.daml.org

Semantic Web users will be able to do more accurate searches of the information and the services they need from the tools provided.

The Semantic Web provides the necessary infrastructure for publishing and resolving ontological descriptions of terms and concepts. In addition, it provides the necessary techniques for reasoning about these concepts, as well as resolving and mapping between ontologies, thus enabling semantic interoperability of Web Services through the identification (and mapping) of semantically similar concepts.

[Fig. 3. Semantic Web Enabling standards]

Ontologies have been developed within the Knowledge Modelling research community [11] in order to facilitate knowledge sharing and reuse. They provide greater expressiveness when modelling domain knowledge and can be used to communicate this knowledge between people and heterogeneous and distributed application systems.

[Seite 230]

As with Web Services, Semantic Web enabling standards fit into a set of layered specifications (fig. 3) built on the foundation of URIs and XML Schema. The current components of the Semantic Web framework are RDF [13], RDF Schema (RDF-S) [3] and the Web Ontology Language – OWL [4]. These standards build up a rich set of constructs for describing the semantics of online information sources.

RDF is a XML-based standard from W3C for describing resources on the Web. RDF introduces a little semantics to XML data by allowing the representation of objects and their relations through properties. RDF-Schema is a simple type system, which provides information (metadata) for the interpretation of the statements given in RDF data. The Web Ontology language – OWL will facilitate greater machine interpretability of Web content than RDF and RDF Schema by providing a much richer set of constructs for specifying classes and relations. OWL has evolved from existing ontologies languages and specifically from DAML+OIL [12].


3. Brickley D., Guha R.V. (eds.): RDF Vocabulary Description Language 1.0: RDF Schema, W3C Proposed Recommendation (work in progress). http://www.w3.org/TR/rdf-schema/. (2003)

4. Bechhofer, S., Dean, M., Van Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D., Patel-Schneider, P., Schreiber, G., Stein, L.: OWL Web Ontology Language Reference, W3C Proposed Recommendation (work in progress). http://www.w3.org/TR/owl-ref/. (2003)

12. Joint US/EU ad hoc Committee. Reference Description of the DAML-OIL Ontology Markup Language. http://www.daml.org/2001/03/reference. (2001)

13. Klyne, G., D., Carroll, J.J. (eds.): Resource Description Framework (RDF): Concepts and Abstract Syntax. W3C Proposed Recommendation (work in progress). http://www.w3.org/TR/rdf-concepts/. (2003)

Anmerkungen

Figure 2.3 stimmt mit Fig. 3 der Vorlage überein. Ohne Hinweis auf eine Übernahme, obwohl auch die Texte weitgehend identisch sind.

Sichter
(Graf Isolan) Schumann

[4.] Saa/Fragment 016 31 - Diskussion
Zuletzt bearbeitet: 2014-09-15 21:48:55 Singulus
Cabral et al 2004, Fragment, Gesichtet, KomplettPlagiat, SMWFragment, Saa, Schutzlevel sysop

Typus
KomplettPlagiat
Bearbeiter
Graf Isolan
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 16, Zeilen: 31-32
Quelle: Cabral et al 2004
Seite(n): 225-226, Zeilen: 225:38-39 - 226:1-2
2.4 Semantic Web Services

Whilst promising to revolutionize e-Commerce and enterprise-wide integration, current standard technologies for Web Services, i.e. WSDL provide only syntactic-level descrip[tions of their functionalities, without any formal definition to what the syntactic definitions might mean.]

[Seite 225]

Whilst promising to revolutionize eCommerce and enterprise-wide integration, current standard technologies for Web services (e.g. WSDL [6]) provide only syntac-

[Seite 226]

tic-level descriptions of their functionalities, without any formal definition to what the syntactic definitions might mean.

Anmerkungen

Ohne Hinweis auf eine Übernahme. Auf der nächsten Seite wird diese fortgesetzt (vgl. Fragment 017 01).

Sichter
(Graf Isolan) Schumann

[5.] Saa/Fragment 017 01 - Diskussion
Zuletzt bearbeitet: 2014-09-14 17:18:03 Singulus
Cabral et al 2004, Fragment, Gesichtet, KomplettPlagiat, SMWFragment, Saa, Schutzlevel sysop

Typus
KomplettPlagiat
Bearbeiter
Graf Isolan
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 17, Zeilen: 1-18
Quelle: Cabral et al 2004
Seite(n): 225-226, Zeilen: 225:38-39 - 226:1-19
[Whilst promising to revolutionize e-Commerce and enterprise-wide integration, current standard technologies for Web Services, i.e. WSDL provide only syntactic-level descrip]tions of their functionalities, without any formal definition to what the syntactic definitions might mean. In many cases, Web Services offer little more than a formally defined invocation interface, with some human oriented meta-data that describes what the service does, and which organization developed it, i.e. through UDDI [35] descriptions. The software applications may invoke Web Services using a common, extendible communication framework, i.e. SOAP [33]. However, the lack of machine-readable semantics necessitates human intervention for automated service discovery and composition within open systems, thus hampering their usage in complex business contexts.

Semantic Web Services (SWS) [44] relax this restriction by augmenting Web Services with rich formal descriptions of their capabilities, thus facilitating automated composition, discovery, dynamic binding, and invocation of services within an open environment. A prerequisite to this, however, is the emergence and evolution of the Semantic Web [38], which provides the infrastructure for the semantic interoperability of Web Services. Web Services will be augmented with rich formal descriptions of their capabilities, such that they can be utilized by software applications or other services without (or less) human assistance or highly constrained agreements on interfaces or protocols. Thus, SWSs have the potential to change the way knowledge and business services are consumed and provided on the current Web.


[33] SOAP 1.2 Part 1, W3C Working Draft; http://www.w3.org/TR/soap12-part1/

[35] Universal Description, Discovery and Integration specifications; http://www.uddi.org/specification.html

[38] T. Berners-Lee, J. Hendler and O. Lassila; The Semantic Web, Scientific American 284(5):34-43, 2001

[44] Semantic Web Services; http://www.daml.org/services/

[Seite 225]

Whilst promising to revolutionize eCommerce and enterprise-wide integration, current standard technologies for Web services (e.g. WSDL [6]) provide only syntac-

[Seite 226]

tic-level descriptions of their functionalities, without any formal definition to what the syntactic definitions might mean. In many cases, Web services offer little more than a formally defined invocation interface, with some human oriented metadata that describes what the service does, and which organization developed it (e.g. through UDDI descriptions). Applications may invoke Web services using a common, extendable communication framework (e.g. SOAP). However, the lack of machine readable semantics necessitates human intervention for automated service discovery and composition within open systems, thus hampering their usage in complex business contexts.

Semantic Web Services (SWS) relax this restriction by augmenting Web services with rich formal descriptions of their capabilities, thus facilitating automated composition, discovery, dynamic binding, and invocation of services within an open environment A prerequisite to this, however, is the emergence and evolution of the Semantic Web, which provides the infrastructure for the semantic interoperability of Web Services. Web Services will be augmented with rich formal descriptions of their capabilities, such that they can be utilized by applications or other services without human assistance or highly constrained agreements on interfaces or protocols. Thus, Semantic Web Services have the potential to change the way knowledge and business services are consumed and provided on the Web.


6. Christensen, E. Curbera, F., Meredith, G., Weerawarana, S. Web Services Description Language (WSDL), W3C Note 15. http://www.w3.org/TR/wsdl. (2001)

Anmerkungen

Ohne Hinweis auf eine Übernahme.

Sichter
(Graf Isolan) Schumann

[6.] Saa/Fragment 017 19 - Diskussion
Zuletzt bearbeitet: 2014-11-23 04:46:42 Hindemith
Cabral et al 2004, Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Verschleierung

Typus
Verschleierung
Bearbeiter
Graf Isolan
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 17, Zeilen: 19-43
Quelle: Cabral et al 2004
Seite(n): 230, Zeilen: 11ff
2.4.1 Why Semantic Web Services?

Semantic descriptions of Web Services are necessary in order to enable their automatic discovery, composition and execution across heterogeneous users and domains. Present technologies for Web Services provide descriptions only at the syntactic level, which makes it diffcult [sic] for the requesters and providers to interpret or represent nontrivial statements, i.e. the meaning of inputs and outputs or applicable constraints. This limitation may be relaxed by providing a rich set of semantic annotations that augment the service description. A Semantic Web Service is defined through a service ontology, which enables machine interpret-ability of its capabilities as well as integration with domain knowledge. The deployment of Semantic Web Services will rely on the further development and combination of Web Services and Semantic Web enabling technologies. Several initiatives have been started in the industry and academia, e.g. DIP [45], SWSI [46] which are investigating solutions for the main issues regarding the infrastructure for SWS. Fig. 2.4 shows the following three orthogonal dimensions as characterization of Semantic Web Service infrastructure:

Usage activities define the functional requirements, which a framework for Semantic Web Services ought to support.

Architecture of SWSs describes the components needed for accomplishing the activities defined for SWS.

Service ontology aggregates all concept models related to the description of a Semantic Web Service and constitutes the knowledge-level model of the information describing and supporting the usage of the service.

Usage Activities

From the usage activities perspective, SWS are seen as objects within a business application execution scenario. The activities required for running an application using SWS [include: publishing, discovery, selection, composition, invocation, deployment and ontology management, as described next.]


[45] Data, Information and Process Integration with Semantic Web Services (DIP); http://dip.semanticweb.org

[46] Semantic Web Service Initiative (SWSI); http://www.swsi.org

4 Semantic Web Services

Semantic descriptions of Web services are necessary in order to enable their automatic discovery, composition and execution across heterogeneous users and domains. Existing technologies for Web services only provide descriptions at the syntactic level, making it difficult for requesters and providers to interpret or represent nontrivial statements such as the meaning of inputs and outputs or applicable constraints. This limitation may be relaxed by providing a rich set of semantic annotations that augment the service description. A Semantic Web Service is defined through a service ontology, which enables machine interpretability of its capabilities as well as integration with domain knowledge.

The deployment of Semantic Web Services will rely on the further development and combination of Web Services and Semantic Web enabling technologies. There exist several initiatives (e.g. http://dip.semanticweb.org or http://www.swsi.org) taking place in industry and academia, which are investigating solutions for the main issues regarding the infrastructure for SWS.

Semantic Web Service infrastructures can be characterized along three orthogonal dimensions (fig. 4): usage activities, architecture and service ontology. These dimensions relate to the requirements for SWS at business, physical and conceptual levels. Usage activities define the functional requirements, which a framework for Semantic Web Services ought to support. The architecture of SWS defines the components needed for accomplishing these activities. The service ontology aggregates all concept models related to the description of a Semantic Web Service, and constitutes the knowledge-level model of the information describing and supporting the usage of the service.

From the usage activities perspective, SWS are seen as objects within a business application execution scenario. The activities required for running an application using SWS include: publishing, discovery, selection, composition, invocation, deployment and ontology management, as described next.

Anmerkungen

Ohne Hinweis auf eine Übernahme.

Sichter
(Graf Isolan), Hindemith

[7.] Saa/Fragment 018 01 - Diskussion
Zuletzt bearbeitet: 2015-05-16 09:35:05 Hindemith
Cabral et al 2004, Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Verschleierung

Typus
Verschleierung
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 18, Zeilen: 1ff (komplett)
Quelle: Cabral et al 2004
Seite(n): 6, 7, Zeilen: 6: 39ff; 7: 1ff
Saa 018a diss.png

Figure 2.4: Semantic Web Services Infrastructure Dimensions

[The activities required for running an application using SWS] include: publishing, discovery, selection, composition, invocation, deployment and ontology management, as described next. The publishing or advertisement of SWS will allow agents or applications to discover services based on its goals and capabilities. A semantic registry is used for registering instances of the service ontology for individual services. The service ontology distinguishes between information which is used for matching during the discovery and that is used during service invocation. In addition, domain knowledge should also be published or linked to the service ontology. The discovery of services consists of a semantic matching between the description of a service request and the description of published service. The queries involving the service name, input, output, preconditions and other attributes can be constructed and used for searching the semantic registry. The matching can also be done at the level of tasks or goals to be achieved, followed by a selection of services which solves the task. The degree of matching can be based on some criteria, such as the inheritance relationship of types. For example, an input of type Infusion Pump of a provided service can be said to match an input of type Medical Device of a requested service.

A selection of services is required if there is more than one service matching the request. Non-functional attributes such as cost or quality can be used for choosing one service. In a more specialized or agent-based type of interaction a negotiation process can be started between a requester and a provider, but that requires that the services themselves be knowledge-based.

The activities required for running an application using SWS include: publishing, discovery, selection, composition, invocation, deployment and ontology management, as described next.

[Seite 7]

The publishing or advertisement of SWS will allow agents or applications to discover services based on its goals and capabilities. A semantic registry is used for registering instances of the service ontology for individual services. The service ontology distinguishes between information which is used for matching during discovery and that used during service invocation. In addition, domain knowledge should also be published or linked to the service ontology.

The discovery of services consists of a semantic matching between the description of a service request and the description of published service. Queries involving the service name, input, output, preconditions and other attributes can be constructed and used for searching the semantic registry. The matching can also be done at the level of tasks or goals to be achieved, followed by a selection of services which solves the task. The degree of matching can be based on some criteria, such as the inheritance relationship of types. For example, an input of type Professor of a provided service can be said to match an input of type Academic of a requested service.

Saa 018a source.png

Fig. 4. Semantic Web Services infrastructure dimensions.

A selection of services is required if there is more than one service matching the request. Non-functional attributes such as cost or quality can be used for choosing one service. In a more specialized or agent-based type of interaction a negotiation process can be started between a requester and a provider, but that requires that the services themselves be knowledge-based.

Anmerkungen

Ein Verweis auf die Quelle fehlt.

Man beachte die Anpassung an die Thematik der untersuchten Arbeit:

"Professor" --> "Infusion Pump"

"Academic" --> "Medical Device"

Sichter
(Hindemith) Schumann

[8.] Saa/Fragment 019 01 - Diskussion
Zuletzt bearbeitet: 2015-05-16 20:01:57 Hindemith
Cabral et al 2004, Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Verschleierung

Typus
Verschleierung
Bearbeiter
Hindemith
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 19, Zeilen: 1ff (komplett)
Quelle: Cabral et al 2004
Seite(n): 231, 232, Zeilen: 231: 13 ff.; 232: 1 ff.
[In general, a broker would check that the preconditions] of tasks and services are satisfied and prove that the services post-conditions and effects imply goal accomplishment. An explanation of the decision making process should also be provided. The Composition or choreography allows SWS to be defined in terms of other simpler services. A workflow expressing the composition of atomic services can be defined in the service ontology by using appropriate control constructs. This description would be grounded on a syntactic description such as BEPL4WS [47]. Dynamic composition is also being considered as an approach during service request in which the atomic services required to solve a request are located and composed on the y. That requires an invoker which matches the outputs of atomic services against the input of the requested service.

The invocation of SWS involves a number of steps, once the required inputs have been provided by the service requester. First, the service and domain ontologies associated with the service must be instantiated. Second, the inputs must be validated against the ontology types. Finally the service can be invoked or a workflow executed through the grounding provided. It is also important to monitor the status of the decomposition process and notify the requester in case of exceptions. The deployment of a Web Service by a provider is independent of the publishing of its semantic descriptions since the same Web Service can serve multiple purposes. Also, the SWS infrastructure can provide a facility for the instant deployment of code for a given semantic description. The management of service ontologies is a cornerstone activity for SWS since it will guarantee that the semantic service descriptions are created, accessed and reused within the Semantic Web.

Architecture

From the architecture perspective, as shown in Fig. 2.4, SWSs are defined by a set of components which realize the activities above, with underlying security and trust mechanisms. The components gathered from the discussion above include: a register, a reasoner, a matchmaker, a decomposer and an invoker. The reasoner is used during all activities and provides the reasoning support for interpreting the semantic descriptions and queries. The register provides the mechanisms for publishing and locating services in a semantic registry as well as functionalities for creating and editing service descriptions. The matchmaker mediates between the requester and the register during the discovery and selection of services. The decomposer is the component required for executing the composition model of composed services. The invoker mediates between requester and provider or decomposer and provider when invoking services. These components are illustrative of the required roles in the SWS architecture for the discussion here as they can have different names and a complexity of their own in different approaches.

Service Ontology

The service ontology is another dimension under which we can define the SWS, for it represents the capabilities of a service itself and the restrictions applied to its use. The service ontology essentially integrates at the knowledge-level the information which has been defined by Web Services standards, such as UDDI and WSDL with related domain knowledge. This would include: functional capabilities such as inputs, output, pre-conditions and post-conditions; and non-functional capabilities such as category, cost and quality of service; provider related information, such as company name and address; task or goal-related information; and domain knowledge defining, for instance, the type of the inputs of the service. This information can, in fact be divided in several ontologies. However, the service ontology used for describing SWS will rely on the expressivity and inference power of the underlying ontology language supported by the Semantic Web.


[47] BPEL4WS Consortium. Business Process Execution Language for Web Services; http://www.ibm.com/developerworks/ library/specification/ws-bpel/

In general, a broker would check that the preconditions of tasks and services are satisfied and prove that the services post-conditions and effects imply goal accomplishment. An explanation of the decision-making process should also be provided.

Composition or choreography allows SWS to be defined in terms of other simpler services. A workflow expressing the composition of atomic services can be defined in the service ontology by using appropriate control constructs. This description would be grounded on a syntactic description such as BEPL4WS [5]. Dynamic composition is also being considered as an approach during service request in which the atomic services required to solve a request are located and composed on the fly. That requires an invoker which matches the outputs of atomic services against the input of the requested service.

The invocation of SWS involves a number of steps, once the required inputs have been provided by the service requester. First, the service and domain ontologies asso-

[Seite 232]

ciated with the service must be instantiated. Second, the inputs must be validated against the ontology types. Finally the service can be invoked or a workflow executed through the grounding provided. Monitoring the status of the decomposition process and notifying the requester in case of exceptions is also important.

The deployment of a Web service by a provider is independent of the publishing of its semantic description since the same Web service can have serve multiple purposes. But, the SWS infrastructure can provide a facility for the instant deployment of code for a given semantic description.

The management of service ontologies is a cornerstone activity for SWS since it will guarantee that semantic service descriptions are created, accessed and reused within the Semantic Web.

From the architecture perspective (fig. 4), SWS are defined by a set of components which realize the activities above, with underlying security and trust mechanisms. The components gathered from the discussion above include: a register, a reasoner, a matchmaker, a decomposer and an invoker.

The reasoner is used during all activities and provides the reasoning support for interpreting the semantic descriptions and queries. The register provides the mechanisms for publishing and locating services in a semantic registry as well as functionalities for creating and editing service descriptions. The matchmaker will mediate between the requester and the register during the discovery and selection of services. The decomposer is the component required for executing the composition model of composed services. The invoker will mediate between requester and provider or decomposer and provider when invoking services. These components are illustrative of the required roles in the SWS architecture for the discussion here as they can have different names and a complexity of their own in different approaches.

The service ontology is another dimension under which we can define SWS (fig. 4), for it represents the capabilities of a service itself and the restrictions applied to its use. The service ontology essentially integrates at the knowledge-level the information which has been defined by Web services standards, such as UDDI and WSDL with related domain knowledge. This would include: functional capabilities such as inputs, output, pre-conditions and post-conditions; non-functional capabilities such as category, cost and quality of service; provider related information, such as company name and address; task or goal-related information; and domain knowledge defining, for instance, the type of the inputs of the service. This information can, in fact be divided in several ontologies. However, the service ontology used for describing SWS will rely on the expressivity and inference power of the underlying ontology language supported by the Semantic Web.


5. BPEL4WS Consortium. Business Process Execution Language for Web Services. http://www.ibm.com/developerworks/ library/ws-bpel

Anmerkungen

Ein Verweis auf die Quelle fehlt.

Sichter
(Hindemith), SleepyHollow02

[9.] Saa/Fragment 021 03 - Diskussion
Zuletzt bearbeitet: 2014-11-23 05:00:37 Hindemith
Cabral et al 2004, Fragment, Gesichtet, KomplettPlagiat, SMWFragment, Saa, Schutzlevel sysop

Typus
KomplettPlagiat
Bearbeiter
Graf Isolan
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 21, Zeilen: 3-42
Quelle: Cabral et al 2004
Seite(n): 234-235, Zeilen: 234:3ff - 235:1ff
OWL-S

OWL-S [49] is an upper ontology used to describe the semantics of services based on the W3C standard ontology OWL and is grounded in WSDL. Its approach originated from an Artificial Intelligence background and has previously been used to describe agent functionality within several multi-agent systems as well as with a variety of planners to solve higher level goals. It consists of three main upper ontologies: the Profile, Process Model and Grounding.

The Profile is used to describe services for the purposes of discovery; service descriptions and queries are constructed from a description of functional properties (i.e. inputs, outputs, preconditions, and effects - IOPEs), and non-functional properties (human oriented properties such as service name, etc, and parameters for defining additional meta data about the service itself, such as concept type or quality of service). In addition, the profile class can be sub-classed and specialized, thus supporting the creation of profile taxonomies which subsequently describe different classes of services.

The Process Models describe the composition or orchestration of one or more services in terms of their constituent processes. This is used both for reasoning about possible compositions (such as validating a possible composition, determining if a model is executable given a specific context, etc) and controlling the enactment/invocation of a service. Three process classes have been defined: the composite, simple and atomic process. The atomic process is a single, black-box process description with exposed IOPEs. Inputs and Outputs relate to data channels, where data flows between processes. The preconditions specify facts of the world that must be asserted in order for an agent to execute a service. Effects characterize the facts that become asserted given a successful execution of the service, such as the physical side-effects that the execution the service has on the physical world. The simple process provides a means of describing service or process abstractions, which means that such elements have no specific binding to a physical service, and thus have to be realized by an atomic process (e.g. through service discovery and dynamic binding at run-time), or expanded into a composite process. The composite processes are hierarchically defined work-flows, consisting of atomic, simple and other composite processes. These process work-flows are constructed using a number of different composition constructs, including: Sequence; Unordered; Choice; If 􀀀 then 􀀀 else; Iterate; Repeat 􀀀 until; Repeat 􀀀 while; Split, and Split + join. The profile and process models provide semantic frameworks whereby services can be discovered and invoked, based upon conceptual descriptions defined within Semantic Web (i.e. OWL) ontologies.

The Grounding provides a pragmatic binding between this concept space and the physical data/machine/port space, thus facilitating service execution. The process model is mapped to a WSDL description of the service, through a thin grounding. Each atomic process is mapped to a WSDL operation, and the OWL-S properties used to represent inputs and outputs are grounded in terms of XML data types. Additional properties pertaining to the binding of the service are also provided (i.e. the IP address of the machine hosting the service, and the ports used to expose the service).


[49] OWL-S Semantic Markup for Web Services; http://www.w3.org/Submission/OWL-S/

[Seite 234]

6 OWL-S approach

OWL-S (previously DAML-S [9]) consists of a set of ontologies designed for describing and reasoning over service descriptions. OWL-S approach originated from an AI background and has previously been used to describe agent functionality within several Multi-Agent Systems as well as with a variety of planners to solve higher level goals.

OWL-S combines the expressivity of description logics (in this case OWL) and the pragmatism found in the emerging Web Services Standards, to describe services that can be expressed semantically, and yet grounded within a well defined data typing formalism. It consists of three main upper ontologies: the Profile, Process Model and Grounding. The Profile is used to describe services for the purposes of discovery; service descriptions (and queries) are constructed from a description of functional properties (i.e. inputs, outputs, preconditions, and effects - IOPEs), and non-functional properties (human oriented properties such as service name, etc, and parameters for defining additional meta data about the service itself, such as concept type or quality of service). In addition, the profile class can be subclassed and specialized, thus supporting the creation of profile taxonomies which subsequently describe different classes of services.

OWL-S process models describe the composition or orchestration of one or more services in terms of their constituent processes. This is used both for reasoning about possible compositions (such as validating a possible composition, determining if a model is executable given a specific context, etc) and controlling the enactment/invocation of a service. Three process classes have been defined: the composite, simple and atomic process. The atomic process is a single, black-box process description with exposed IOPEs. Inputs and outputs relate to data channels, where data flows between processes. Preconditions specify facts of the world that must be asserted in order for an agent to execute a service. Effects characterize facts that become asserted given a successful execution of the service, such as the physical side-effects that the execution the service has on the physical world. Simple processes provide a means of describing service or process abstractions – such elements have no specific binding to a physical service, and thus have to be realized by an atomic process (e.g. through service discovery and dynamic binding at run-time), or expanded into a composite process. Composite processes are hierarchically defined workflows, consisting of atomic, simple and other composite processes. These process workflows are constructed using a number of different composition constructs, including: Sequence, Unordered, Choice, If-then-else, Iterate, Repeat-until, Repeat-while, Split, and Split+join.

The profile and process models provide semantic frameworks whereby services can be discovered and invoked, based upon conceptual descriptions defined within Semantic Web (i.e. OWL) ontologies. The grounding provides a pragmatic binding between this concept space and the physical data/machine/port space, thus facilitating service execution. The process model is mapped to a WSDL description of the ser-

[Seite 235]

vice, through a thin grounding. Each atomic process is mapped to a WSDL operation, and the OWL-S properties used to represent inputs and outputs are grounded in terms of XML data types. Additional properties pertaining to the binding of the service are also provided (i.e. the IP address of the machine hosting the service, and the ports used to expose the service).


8. DAML-S Coalition: DAML-S 0.9 Draft Release. http://www.daml.org/services/damls/0.9/. (2003)

9. Fensel, D., Bussler, C. The Web Service Modeling Framework WSMF. Eletronic Commerce: Research and Applications. Vol. 1. (2002). 113-137

19. OWL-S Coalition: OWL-S 1.0 Release. http://www.daml.org/services/owl-s/1.0/. (2003)

Anmerkungen

Ohne Hinweis auf eine Übernahme.

Sichter
(Graf Isolan), Hindemith

[10.] Saa/Fragment 021 47 - Diskussion
Zuletzt bearbeitet: 2014-11-23 05:53:53 Hindemith
Cabral et al 2004, Fragment, Gesichtet, SMWFragment, Saa, Schutzlevel sysop, Verschleierung

Typus
Verschleierung
Bearbeiter
Graf Isolan
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 21, Zeilen: 47
Quelle: Cabral et al 2004
Seite(n): 235, Zeilen: 6ff
WSML

The Web Service Modeling Framework (WSMF) [50] provides a conceptual model and a formal language WSML (Web Service Modeling Language) for the semantic markup of Web Services together with a reference implementation WSMX (Web Service Execution Environment). Its main goal is to fully enable e-Commerce by applying Semantic Web [technology to Web Services.]


[50] Fensel, D., Bussler, C. The Web Service Modeling Framework (WSMF). Eletronic Commerce: Research and Applications. Vol. 1. pp. 113-137, 2002

7 WSMF approach

The Web Service Modeling Framework (WSMF) [9] provides a model for describing the various aspects related to Web services. Its main goal is to fully enable e-commerce by applying Semantic Web technology to Web services.


9. Fensel, D., Bussler, C. The Web Service Modeling Framework WSMF. Eletronic Commerce: Research and Applications. Vol. 1. (2002). 113-137

Anmerkungen

Ohne Hinweis auf eine Übernahme. Diese wird auf der nächsten Seite fortgesetzt (vgl. Fragment 022 01).

(Sichtung mit [1], Zeilenangaben der Quelle daher nicht überprüft)

Sichter
(Graf Isolan), Hindemith

[11.] Saa/Fragment 022 01 - Diskussion
Zuletzt bearbeitet: 2014-11-23 05:55:19 Hindemith
Cabral et al 2004, Fragment, Gesichtet, KomplettPlagiat, SMWFragment, Saa, Schutzlevel sysop

Typus
KomplettPlagiat
Bearbeiter
Graf Isolan
Gesichtet
Yes.png
Untersuchte Arbeit:
Seite: 22, Zeilen: 1-25
Quelle: Cabral et al 2004
Seite(n): 235, Zeilen: 9ff
WSMF is the product of research on modeling of reusable knowledge components. WSMF is centered on two complementary principles: a strong de-coupling of the various components that realize an e-commerce application; and a strong mediation service enabling Web Services to communicate in a scalable manner. The mediation is applied at several levels: mediation of data structures; mediation of business logics; mediation of message exchange protocols; and mediation of dynamic service invocation. WSMF consists of four main elements: ontologies that provide the terminology used by other elements; goal repositories that define the problems that should be solved by Web Services; Web Services descriptions that define various aspects of a Web Service; and mediators which bypass interoperability problems.

WSMF implementation has been assigned to two main projects: Semantic Web enabled Web Services (SWWS) [53], and Web Service Modeling Ontology (WSMO) [54]. SWWS provides a description framework, a discovery framework and a mediation platform for Web Services, according to a conceptual architecture. WSMO refines the Web Services Modeling Framework and develops a formal service ontology and language for SWS. WSMO Service Ontology includes definitions for goals, mediators and Web Services. The underlying representation language for WSMO is F-logic because it is a full first order logic language that provides second order syntax while staying in the first order logic semantics, and has a minimal model semantics. The main characterizing feature of the WSMO architecture is that the goal, Web Service and ontology components are linked by four types of mediators as follows:

OO mediators link ontologies to ontologies

WW mediators link Web Services to Web Services

WG mediators link Web Services to goals

GG mediators link goals to goals.


[53] Semantic Web enabled Web Services (SWWS); http://swws.semanticweb.org/

[54] Web Service Modeling Ontology (WSMO); http://www.wsmo.org/

WSMF is the product of research on modelling of reusable knowledge components [10].

WSMF is centered on two complementary principles: a strong de-coupling of the various components that realize an e-commerce application; and a strong mediation service enabling Web services to communicate in a scalable manner. Mediation is applied at several levels: mediation of data structures; mediation of business logics; mediation of message exchange protocols; and mediation of dynamic service invocation.

WSMF consists of four main elements: ontologies that provide the terminology used by other elements; goal repositories that define the problems that should be solved by Web services; Web services descriptions that define various aspects of a Web service; and mediators which bypass interoperability problems.

WSMF implementation has been assigned to two main projects: Semantic Web enabled Web Services (SWWS) [25]; and WSMO (Web Service Modelling Ontology) [28]. SWWS will provide a description framework, a discovery framework and a mediation platform for Web Services, according to a conceptual architecture. WSMO will refine WSMF and develop a formal service ontology and language for SWS.

WSMO service ontology includes definitions for goals, mediators and web services. A web service consists of a capability and an interface. The underlying representation language for WSMO is F-logic. The rationale for the choice of F-logic is that it is a full first order logic language that provides second order syntax while staying in the first order logic semantics, and has a minimal model semantics. The main characterizing feature of the WSMO architecture is that the goal, web service and ontology components are linked by four types of mediators as follows:

• OO mediators link ontologies to ontologies,

• WW mediators link web services to web services,

• WG mediators link web services to goals, and finally,

• GG mediators link goals to goals.


10. Fensel, D. and Motta, E.: Structured Development of Problem Solving Methods. IEEE Transactions on Knowledge and Data Engineering, Vol. 13(6). (2001). 913-932.

25. SWWS Consortium. Report on Development of Web Service Discovery Framework. October 2003. http://swws.semanticweb.org/public_doc/D3.1.pdf

28. WSMO Working Group. Web Service Modelling Ontology Project. DERI Working Drafts. http://www.nextwebgeneration.org/projects/wsmo/ (2004)

Anmerkungen

Fast vollständig wörtlich übereinstimmend, aber dennoch ohne Hinweis auf eine Übernahme.

(Sichtung mit [2], Zeilenangaben der Quelle daher nicht überprüft)

Sichter
(Graf Isolan), Hindemith

Auch bei Fandom

Zufälliges Wiki