Presentation at ITA 2009
•Als PPT, PDF herunterladen•
0 gefällt mir•329 views
Presentation given at the 3rd Internet Technologies and Applications Conference (ITA 09, http://www.ita09.org/), held in Wrexham, North East Wales, UK in september 2009.
![Introduction ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Presentation at ITA 2009
Ähnlich wie Presentation at ITA 2009 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Presentation at ITA 2009
- 1. Integrating semantic web knowledge and Service Oriented Architectures Jesús Soto-Carrión Elisa García Salvador Sánchez-Alonso
- 10. Benefits of a general semantic connector
- 13. An example of use GORSE
- 15. Example
Hinweis der Redaktion
- In SOA, component communication is implemented through messages exchange. These messages contain data structured according to fixed structures (schemas), rarely using the flexible knowledge expressions provided by emerging semantic web technologies JBI (Java Business Integration standard) defines 2 types of components: Service engine (components implementing main ESB functionalities such as a BPEL interpreter, data translation or data transformation services) Binding component (Enabling services to deploy over a SOA architecture) NMR (Normalized Message Router): provides a normalized message interchange between ESB plugged components
- In SOA, component communication is implemented through messages exchange. These messages contain data structured according to fixed structures (schemas), rarely using the flexible knowledge expressions provided by emerging semantic web technologies JBI (Java Business Integration standard) defines 2 types of components: Service engine (components implementing main ESB functionalities such as a BPEL interpreter, data translation or data transformation services) Binding component (Enabling services to deploy over a SOA architecture) NMR (Normalized Message Router): provides a normalized message interchange between ESB plugged components
- However: * Hidden development tasks: as there does not exist a common ontology access provider (similar to ADO or JDBC for data access), each semantic web framework provide their specific application programming interface * Besides, each framework (e.g. Jena, Protégé-OWL, Sesame or Redland) has been developed with a different programming language, which causes a strong dependency between the application logic and the semantic web framework. Coupled applications: common semantic web functionality implemented into different components. To illustrate this problem, let us think of a software architect that decides changing the underlying semantic web framework in the application, just to discover (to her horror) the huge effort necessary linked to changing most of the code, as it is strongly coupled to the old framework.
- Let us suppose that the CICS component receives a set of messages containing a sequence of medical patient records in OWL according to the open electronic health record ontology OEHR. Given that the COBOL language does not support a semantic library, the component cannot perform relevant operations depending on the data, such as checking the consistency of the data or retrieving all the instances of one specific class
- General Ontology Service Engine functionalities: - Consistency check: verifies if an ontology is well defined, not including inconsistencies between data types and duplicated entries among other problems. Using this operation, a software component can check the consistency of one or more individuals received. - Instances retrieval: retrieves individuals from the ontology making use of the SPARQL language.
- These parameters say how to access to the ontology persistent subsystem WSDL interfaces are automatically generated from this setup file
- 1) GIS coordination service receives a client request (e.g. “all oils on canvas by Velazquez”) 2) GIS uses a SOAP class including a SPARQL message to launch a query in GORSE. The proxy SOAP class is created with GORSE WSDL interface. 3) GORSE returns the results in result class internally using a XSD schema 4) GIS service decouples KML data and knowledge information to display the results in Google maps
- General Ontology Service Engine functionalities: - Consistency check: verifies if an ontology is well defined, not including inconsistencies between data types and duplicated entries among other problems. Using this operation, a software component can check the consistency of one or more individuals received. - Instances retrieval: retrieves individuals from the ontology making use of the SPARQL language.
- KML is a file format used to display geographic data in an Earth browser, such as Google Earth, Google Maps, and Google Maps for mobile. You can create KML files to pinpoint locations, add image overlays, and expose rich data in new ways. KML is an international standard maintained by the Open Geospatial Consortium, Inc. (OGC) .