DT211-4 DT228-4 Semester 2
2010
Pat Browne
Web Mapping http://www.archaeology.ie/smrmapviewer/mapviewer.aspx
http://www.openapp.ie/geospatial/demonstration
/
Firefox http://spatial.dcenr.gov.ie/imf/imf.jsp?site=GeoUrban
Location and geographical properties of resources has always been something of a dilemma for the World Wide
Web, which has served so well to unlink the global identity of a resource from its physical location on the globe. One of the Web's greatest values is its capacity for enabling the growth of communities which are not constrained by distance and geography. Nonetheless, physical location is at least an essential property if not a part of the identity of any real entity. When appropriate, the Local Web of resources identified by location and geography is an essential aspect of Web discovery and communication .
Joshua Lieberman, Geospatial Incubator Group Chair,
2007/10/3, http://www.w3.org/2005/Incubator/geo/
HTML Viewer
Java Viewer
(Internet)
GIS Desktop
Applications
Wireless
Mobile
Devices
Network
Custom
Applications
Map Renderer
Spatial
DB
Server Side
Applications
Question: What need to be done to allow geographic data to be available on the Web?
Answer: A lot!
The a typical Open Geo-Stack:
PostGIS for persistence: We need some structured way to hold spatial & non-spatial data.
Geoserver for server side map specific function WMS,WFS.
OpenLayers for client side programming to handle user interaction.
A web service (WS) is a software system designed to support interoperable machine-to-machine interaction over a network (W3C). A WS is any service that is available over the Internet, uses a standardized XML messaging system, and isn't tied to any one operating system or programming language.
Web services are software services identified by a URI that are described, discovered, and accessed using Web protocols. Web Services consume and produce XML. (smart data and meta-data). Web services provide the potential to increase interoperability, application integration, which make transacting business easier.
WS technology has established a common, vendor-neutral platform for integrating distributed computing applications.
As WS proliferate, they become similar to Web pages in that they are more difficult to discover.
Semantic Web technologies will be necessary to solve the Web service discovery problem.
Universal Description,
Discovery and
Integration ( UDDI ) is a platform-independent,
XML-based registry for businesses worldwide to list themselves on the
Internet.
Web Services
Description Language
( WSDL ) is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint.
The Semantic Web will enable Web Services to interact with other Web services. Advanced Web service applications involving comparison, composition, or orchestration of Web services will require Semantic Web technologies for such interactions to be automated.
Web services are based on a platform-neutral processing model for XML. The step after that is to make both the data and the processing model smarter. In other words, continue along the
“smart-data continuum.” In the near term, this will move along five axes: logical assertions, classification, formal class models, rules, and trust.
WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in this document
( http://www.w3.org/TR/wsdl ) describe how to use WSDL in conjunction with SOAP
1.1, HTTP GET/POST, and MIME.
As communications protocols and message formats are standardized in the web community, it becomes increasingly possible and important to be able to describe the communications in some structured way.
WSDL addresses this need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication.
A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:
A WSDL document uses the following elements in the definition of network services:
Types – a container for data type definitions using some type system (such as XSD).
Message – an abstract, typed definition of the data being communicated.
Operation – an abstract description of an action supported by the service.
Port Type –an abstract set of operations supported by one or more endpoints.
Binding – a concrete protocol and data format specification for a particular port type.
Port – a single endpoint defined as a combination of a binding and a network address.
Service – a collection of related endpoints.
The UDDI project encourages the inter operability and adoption of Web services. UDDI provides a standards-based set of specifications for service description and discovery, as well as a set of Internet-based implementations. UDDI continues to rapidly evolve and to gain industry support. The specification has developed quickly because it is backed with rapid implementation, which proves the concepts and provides a rich experience base for further refinement of the specification.
UDDI addresses a number of business problems. First, it helps broaden and simplify business-to-business (B2B) interaction. For the manufacturer who needs to create many relationships with different customers, each with its own set of standards and protocols, UDDI supports a highly flexible description of services using virtually any interface. For the flower shop in Australia that wants to get plugged in to every marketplace in the world but does not know how, UDDI provides a way to do this. The specifications allow the efficient and simple discovery of their business and the services they offer by publishing them in the registry.
Technical models, or tModels.
Technical models, or tModels.
UDDI can:
Make it possible to discover the right service from the millions currently online
Define how to enable transactions once the preferred service is discovered
Allow user-driven choice of service
Describes services programmatically in a single, open, and secure environment
Reach new user and increasing access to current users
The principle OGC web services are;
WMS; standardizes the display of map images. WMS can register and overlay maps from multiple remote sources.
WFS-T: standardizes the retrieval and update of features.
WPS: can describe calculations or processes (inputs and outputs, triggers, execution) as a Web Service. The processes can be supplied by a GIS (e.g. GRASS or special API)
WCS: standardizes access to spatially extended coverages, usually encoded in a binary format and offered by a server (typically remotely sensed data).
Web services have reached a level of sophistication that facilitates the delivery and use of spatial information. Web services for mapping enable sharing information.
Web services for mapping allow consumers and providers of information to integrate diverse data sets.
To access remote data we need specific knowledge about that data source: server address, data layers available, meta-data, required and available data format.
Once the system knows the details, application can request exactly maps and other information
We will GeoServer as our map server.
Another popular open source map server is simply called MapServer (http://mapserver.org/)
The course web site list many examples of data sharing. Many of the links show how government departments share data with the public and other departments. Which means data users don't need to store their data locally. In many cases centralizing data storage can lead to cost savings and avoid redundancy. Web services for mapping can facilitate integration, centralization and sharing.
The OpenGIS® Web Map Service Interface Standard
(WMS) provides a simple HTTP interface for requesting geo-registered map images from one or more distributed geospatial databases. A WMS request defines the geographic layer(s) and area of interest to be processed.
The response to the request is one or more georegistered map images (returned as JPEG, PNG, etc) that can be displayed in a browser application. The interface also supports the ability to specify whether the returned images should be transparent which allows layers from multiple servers can be combined.
Feature associated with a location relative to the Earth.
The starting point for modeling of geographic information. A feature is an abstraction of a real world phenomenon. A geographic feature is a feature associated with a location relative to the Earth. A digital representation of the real world can be thought of as a set of features.
Geographic features occur at two levels: feature instances and feature types. At the instance level, a geographic feature is represented as a discrete phenomenon that is associated with its geographic and temporal coordinates. These individual feature instances are grouped into classes with common characteristics feature types.
The OGS Web Feature Service Interface Standard (WFS) defines an interface for specifying requests for retrieving geographic features across the Web using platform-independent calls. The WFS standard defines interfaces and operations for data access and manipulation on a set of geographic features, including:
Get or Query features based on spatial and non-spatial constraints
Create a new feature instance
Get a description of the properties of features
Delete a feature instance (WFS-T)
Update a feature instance (WFS-T)
Lock a feature instance (WFS-T)
By default, the specified feature encoding for input and output is the
Geography Markup Language (GML) which in turn is written in XML.
Via the WFS interfaces, a web user or service can combine, use and manage features from different sources by invoking the following WFS operations on geographic features and elements:
Create a new feature instance
Delete a feature instance
Update a feature instance
Lock a feature instance
Get or query features based on spatial and nonspatial constraints
Web Services Description
Language is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.
WFS follows the web services model
Basic sequence of events
Data can be shared in a number of ways. A complete copy can be given to the remote user allowing them to use the data for any purpose.
Alternatively, a more limited form of access can be granted. For example, users of Google Map do not get the actual spatial data although they are granted a high degree of usage through the
Google Map API. OGC WMS (see later) provide to bitmap image rather than the vector map itself, whereas WFS provides vectors.
Some spatial data, such as hurricane locations, is constantly changing
(streamed). It does not make sense to download such data. It would be better to integrate the weather layer in your map that accesses a web service in realtime.
Web services can make very large data sets available to users, reducing the need for continual data storage upgrades.
GeoServer can request map data from a remote web server
OpenLayers is a JavaScript library for displaying map data in a web browser.
We will look at OpenLayers later
ModJK is the connector used to connect Tomcat servlet container with web servers such as Apache. We use
GeoServers servlet container called
Jetty and do not need to connect to
Apache.
GEOS (Geometry Engine, Open
Source) is a library used by
PostGIS to perform all the operations in the OpenGIS
Simple Features for SQL
Specification.
PROJ.4
is an open source library used by PostgIS to convert between geographic coordinate systems
MapInfo Interchange
Format (MIF) is a map and database exporting file format of MapInfo software product.
ArcSDE technology manages spatial data in a relational database management system (RDBMS) and enables it to be accessed by ArcGIS clients. It is the technology that provides the framework to support long transactions, which facilitates the versioned editing environment in multiuser geodatabases.
The JTS
Topology Suite is an API of 2D spatial predicates and functions.
GeoServer can access and provide data using a web services framework.
The Open Geospatial Consortium (OGC) has developed specifications for web services for mapping. The OGC aim to increase interoperability between applications by creating common interchange languages through common standards. GeoServer implements
OGC’s web mapping services.
Web Map Service (WMS) Share and request vector and raster map data in plain image format
Web Feature Service (WFS) Share and request vector map data and attributes in GML format
Web Feature Service –Transactional (WFS-T ) is a WFS that supports transactions - add, delete, or update features.
Web Coverage Service (WCS) Share image/raster data with original data value
Web Map Context (WMC) Save and load views of a WMS application as XML
Styled Layer Descriptors (SLD) Request particular symbolization and styling from a WMS
Geography Markup Language (GML) XML-based format for spatial and tabular data interchange
Filter: Encoding XML-based format for defining queries on spatial data
GeoServer 1.6.0 and above supports WFS 1.1
WFS 1.1 supports on the fly re-projection of data, which means data can be returned in a SRS other than the native one. We can check the WFS version as follows:
http://localhost:8080/geoserver/wfs?request=GetCapabilities&service=WFS&version=1.0.0
Here is the XML for the reference system
<SRS>EPSG:4326</SRS>
On Geoserve static web files are stored in the www subfolder of the GeoServer data directory, and they are served at http:/myhost:8080/geoserver/www.
In the www folder you can store html, images and Javascript and have
Geoserver provide them on the web with
AJAX callbacks.
Geoserver uses Jetty as a servlet container.
Jetty is an open-source embeddable web server and servlet container, written in Java.
http://www.mortbay.org/jetty/
Jetty can handle Java servlets and
JavaServerPages (JSP) technologies and traditional static web pages.
There is a Jetty Servlet tutorial at:
http://www.seas.upenn.edu/~cis550/jetty.html
Each GeoServer service is provided by a specific Servlet that intercepts the client requests and builds up the response in accordance to the GeoServer configuration.
Geoserver can be deployed as a standard
WAR package inside Java Servlet containers.
Universal Description,
Discovery and
Integration ( UDDI ) is a platform-independent,
XML-based registry for businesses worldwide to list themselves on the
Internet.
•A WFS must implement the following operations:
•GetCapabilities - queries the WFS service to determine available options.
•DescribeFeatureType - retrieves the XML schema to allow the WFS client to parse the result sets.
•GetFeature - performs the actual query - parameters such as bounding box and any other filters should be passed in, as appropriate, and the WFS service then returns a GML result set containing full geometry and feature attributes.
OpenLayers (OL) is an open source JavaScript library for displaying map data in web browsers. OL provides an
API for building complex web-based geographic applications. Data can be combined from a number of sources without requiring any server side processing as layers can be assembled and rendered on the client.
Client side programming includes panning and zooming of maps, client-side tiling, markers, popup windows, various adjustable navigation components, keyboard commands, an event handling mechanism and client server communications. Each part of OL is configurable.
OL can act as a Web Client for
See; http://www.bostongis.com/?content_name=openlayers_tut_01
OL can act as a Web Client for:
1. OGC web services (WFS-T,WMS, and WCS
(XML.GML)),
2. Commercial services such as Google Maps(KML),
MSN Virtual Earth, ESRI products
3. Cpen source initiatives or defacto standards such as
Geographically Encoded Objects for RSS feeds
(GeoRSS). The OL GeoRSS parser will automatically connect an information bubble to the map markers, similar to Google maps.
OL helps integrates a diverse set of heterogeneous data sources
(e.g. shape file and database). A variation on OL is Mapbulider built into GeoServer which supports OGC WFS and WMS.
OL facilitates a client-side JavaScript "map -mashup” style application; A mash-up is a Web application that combines data from one or more sources into a single integrated tool. The term
Mashup implies easy, fast integration, frequently done by access to open APIs and data sources to produce results that were not the original reason for producing the raw source data. An example of a mashup is the use of cartographic data from Google Maps to add location information to real estate data, thereby creating a new and distinct Web service that was not originally provided by either source.
OL can return projection information. A projection is a way of converting geographic coordinates (latitude and longitude) into a plane (Irish National Grid).
OL supports any projection, but needs PROJ4 for OL for projections on the fly. OL can request form map servers data in a particular projection. Strong support for the Spherical
Mercator projection used by Google Map, Open
Street Map, and Virtual Earth.
Two ways of getting data.
In one mode OL can request new data without refreshing an entire document, requests can be made to any origin. Another way to retrieve data from a server is to update the location of a document in a frame. These types of requests can also be made to any origin. However, the code running in the original document is restricted to reading data in documents that come from the same origin.
Underlying technology
The basic technology is Asynchronous JavaScript and XML
(AJAX) which includes of JavaScript and XML. XML is the W3C recommended standard for creating formats and sharing data on the
Web
OL normally uses XML for data interchange (though JavaScript
Object Notation (JSON) can be used as an alternative). Ajax is a way of developing Web applications that combines:
XHTML and CSS standards based presentation
Interaction with the page through the DOM
Data interchange with XML and XSLT
Asynchronous data retrieval with a XMLHttpRequest object which is used to read or send data on the server asynchronously.
JavaScript to tie it all together
The Ajax interpreter works within the Web browser
(through JavaScript and the DOM) to render the Web application and handle any requests that the user might have of the Web server. Because the Ajax runtime is handling the requests, it can hold much of the information in the Ajax environment, while allowing the interaction with the application and the customer to happen asynchronously and independently of any interaction with the server. This allows the browser to handle a lot of the map processing locally without reference to the server e.g. display, rendering, scaling, querying.
Asynchronous data transfers through the XMLHttpRequest object.
This allows websites to be refreshed in the background instead of having to be re-loaded after every modification. Because of this technology, a web mapping application is able to execute a user’s command in a fairly short time period, as the necessary steps can be completed in the background. As a result, the usability of interactive web mapping applications is approaching the features of classic Desktop (GIS) applications. The processing of web page formerly was only server-side, using web services or PHP scripts, before the whole page was sent within the network. But Ajax can selectively modify a part of a page displayed by the browser, and update it without the need to reload the whole document with all images, menus, etc... For example, fields of forms, choices of user, may be processed and the result displayed immediately into the same page.
Browsers execute JavaScript code in a sandbox, a sealed environment with little or no access to the computer’s resources. In general OL uses AJAX security features. All communication initiated by OpenLayers.
Request methods are restricted to the same origin policy: requests may only be issued with the same protocol, to the same domain, and through the same port as the document the code is running from. This is because of the underlying JavaScript security model.
JavaScript programs have control over their own page inside the browser, but that is where their abilities end.
The underlying AJAX security can limit interaction; this can be circumvented using proxy server.
<html>
<head>
<script src = "http://www.openlayers.org/api/OpenLayers.js"></script>
<script type = "text/javascript"> function test_Map_Zoom(t) t.plan(1); var map = new OpenLayers.Map("map"); var layer = new OpenLayers.Layer.WMS("ABC",
"http://example.com/123",
'layers':'test'); map.addLayer(layer); map.zoomTo(0); t.eq(map.zoom, 0, "Map zoomed to level 0 correctly.");
</script>
</head>
<body>
<div id="map" style="width: 512px; height: 512px;"/>
</body>
</html>
Osmarender is a rule-based rendering tool for generating SVG images of OSM data. It takes as its input an OpenStreetMap dataset and a rules file. It outputs an SVG image that is marked up in accordance with the styles defined in the rule file.
Mapnik is the Open Source map renderer which we use to render the main Slippy Map layer for OSM. The slippy map is an AJAX component. JavaScript runs in the browser, which dynamically requests tiles from the server in the background (without reloading the whole HTML page) to give a smooth slippy zoomy map browsing experience. The implementation of this is mostly provided by OpenLayers.
CycleMap contains cycling specific information, lanes, routes, networks.Cycle routes are named or numbered or otherwise signed routes , which may go along roads or dedicated cycle paths.
var DITKevinStreetLat=53.338
var DITKevinStreetLon=-6.268
var zoom=16 var map2; function init() { map2 = new OpenLayers.Map ("map2", { controls:[ new OpenLayers.Control.Navigation(), new OpenLayers.Control.PanZoomBar(), new OpenLayers.Control.LayerSwitcher(), maxExtent: new OpenLayers.Bounds(-20037508.34,-0037508.34,
20037508.34,20037508.34), maxResolution: 156543.0399, numZoomLevels: 19, units: 'm', projection: new OpenLayers.Projection("EPSG:900913"), displayProjection: new OpenLayers.Projection("EPSG:4326")} ); layerMapnik = new OpenLayers.Layer.OSM.Mapnik("Mapnik"); map2.addLayer(layerMapnik); layerCycleMap = new OpenLayers.Layer.OSM.CycleMap("CycleMap"); map2.addLayer(layerCycleMap); var lonLat = new OpenLayers.LonLat(DITKevinStreetL, DITKevinStreetL).transform(new
OpenLayers.Projection("EPSG:4326"), map2.getProjectionObject()); map2.setCenter (lonLat, zoom); }
OpenLayers.Map: is the main class of the OpenLayers API. It compiles the application's main map and provides numerous methods for the administration of the map display, including the display of layers and operating components, zooming and panning. In addition, this class allows for queries of current map status through numerous 'get' methods.
OpenLayers.Layer: All map displays are based on the Layer class. Layer.js produces individual layers, sets the transparency and resolution of each, and provides the basic 'get' methods.
OpenLayers.Control: Operating elements in OpenLayers are elements related to map navigation as well the display of map information (e.g. scale). The Control class serves as a base class for all operating elements, among them:Ajax avoids the traditional
Web client/server/web-page interaction between the customer and the server.
OpenLayers.Events: takes over the event handling from
OpenLayers.
OpenLayers.Pixel: displays monitor coordinates in n x- and y- pixel values.
OpenLayers.Size: displays a pixel size value pair in width and height.
OpenLayers.LonLat: displays geographic coordinates in longitude and latitude.
OpenLayers.Bounds: displays a rectangular area (bounding box) whose four sides (left, below, right, above) are indicated with geographic coordinates in float format. The Bounds class provides different get-functions (e.g. center and pixel dimensions of the bounding box) as well as comparative functions (e.g. whether a pixel is located within the defined bounding box).
OpenLayers.Util: contains the different functions and settings which cannot be assigned to any of the other OpenLayers classes.
OpenLayers.Events: takes over the event handling from
OpenLayers.
OpenLayers.Pixel: displays monitor coordinates in n x- and y- pixel values.
OpenLayers.Size: displays a pixel size value pair in width and height.
OpenLayers.LonLat: displays geographic coordinates in longitude and latitude.
OpenLayers.Bounds: displays a rectangular area (bounding box) whose four sides (left, below, right, above) are indicated with geographic coordinates in float format. The Bounds class provides different get-functions (e.g. center and pixel dimensions of the bounding box) as well as comparative functions (e.g. whether a pixel is located within the defined bounding box).
OpenLayers.Util: contains the different functions and settings which cannot be assigned to any of the other OpenLayers classes.
Mapbuilder is a client-side Javascript library for putting mapping in a web page, using an AJAX style of interaction. It works by retrieving XML data from the various sources and rendering that using the browser's built in XSL processor, so the initial HTML page never has to reload.
Server-side requirements are minimal: at minimum an HTTP server, at most 2 other server scripts which are provided (for PHP and J2EE environments).
<ViewContext>
<General>
<Window width="500" height="285" />
<BoundingBox SRS="EPSG:4326" minx="-179.14734" miny="17.884813" maxx="179.77847000000006" maxy="71.35256064399981" />
<Title>g4wd:st99_d00 Map</Title>
<KeywordList>
<Keyword>g4wd:st99_d00</Keyword>
</KeywordList>
<Abstract></Abstract>
</General>
<LayerList>
<Layer queryable="1" hidden="0" >
<Server service="OGC:WMS" version="1.1.1" title="g4wd:st99_d00 Preview" >
<OnlineResource xlink:type="simple" xlink:href="../wms" />
</Server>
<Name>g4wd:st99_d00</Name>
<Title>g4wd:st99_d00</Title>
<SRS>EPSG:4326</SRS>
<FormatList><Format current="1" >image/png</Format></FormatList>
</Layer>
</LayerList>
</ViewContext>
The OGC Web Map Context File
The Context file defines the viewable
Non-spatial attributes of the map such as the size and the title. It also identifies the data layers that should be included on the map.
The Context file is an OGC standard that can be shared across server implementations. Write this file once, and it is reusable from one server to the next.
The newer OWS Context documents support WFS and WCS layers as well as
WMS layers.
OGS Web Map Context (WMC) Implementation
Specification is a companion to the OGC Web
Map Service, it describes how to save a map view comprised of many different layers from different Web Map Servers. A 'context' can be encoded and saved so that Web maps created by users can be automatically reconstructed and augmented by the authoring user or other users in the future. A Context document is structured using eXtensible Markup Language (XML).
Visualization
Application or Tool A
Shareable content, session, area of interest
Context Visualization
Application or Tool B
WMS WMS WMS WMS
A WPS can be configured to offer any sort of GIS functionality to clients across a network, including access to pre-programmed calculations and/or computation models that operate on spatially referenced data. A WPS may offer calculations as simple as subtracting one set of spatially referenced numbers from another
(e.g., determining the difference in influenza cases between two different seasons), or as complicated as a global climate change model. The data required by the WPS can be delivered across a network, or available at the server.
This interface specification provides mechanisms to identify the spatially-referenced data required by the calculation, initiate the calculation, and manage the output from the calculation so that it can be accessed by the client. This Web Processing Service is targeted at processing both vector and raster data.
OGC WFS
GeoRSS
CSV
GML
KML
WKT
Vector
Layers, points, lines, polygons rendered with SVG
/ VML
OGC WMS
Google Maps
MSN Live
Local
Yahoo! Maps
Multimap
ka-Map
WorldWind
Raster
Layers, tiled
GetCapabilities – This operation allows a client to request and receive back service metadata (or Capabilities) documents that describe the abilities of the specific server implementation. The
GetCapabilities operation provides the names and general descriptions of each of the processes offered by a WPS instance.
This operation also supports negotiation of the specification version being used for client-server interactions.
DescribeProcess – This operation allows a client to request and receive back detailed information about the processes that can be run on the service instance, including the inputs required, their allowable formats, and the outputs that can be produced.
Execute – This operation allows a client to run a specified process implemented by the WPS, using provided input parameter values and returning the outputs produced.
Consider the case of a process that can intersect two polygons. The response to a GetCapabilities request might indicate that the WPS supports an operation called ―intersect, and that this operation is limited to intersecting one polygon with a second polygon. The response to a DescribeProcess request for the ―intersect process might indicate that it requires two inputs, namely: ―FirstPolygon and ―SecondPolygon, and that these inputs must be provided in
GML 2.2. Furthermore, the process will produce one output, in either
GML 2.2, or GML 3.1, and it can be delivered as a web-accessible resource.
The client would run the process by calling the Execute operation, and might choose to provide the two input polygons embedded directly within the request, and identify that the output should be stored as a web-accessible resource. After completion, the process would return an ExecuteResponse XML document that identifies the inputs and outputs, indicates whether or not the process executed successfully, and if successful, contains a reference to the webaccessible resource.
Describes the service interface, it specifies a request/response interface that defines how to:
encode requests for process execution
encode responses from process execution
embed data and metadata in process execution inputs/outputs
reference web-accessible data inputs/outputs
support long-running processes
return process status information
return processing errors
request storage of process outputs
Two basic knowledge representation approaches,
1. logic-based formalisms and
2. cognitive representations (using semantic networks and frames)
Logic-based systems were considered to be more powerful, network systems to be more practical.
Description Logics (DLs) are a fusion of 1 & 2.
In DL logic-based constructs are used to establish a basic terminology of the domain of discourse.
Description Logics are a family of languages, each with their own set of constructs. The basic notions of DLs draw upon first order predicate logic. They are concepts
(unary predicates) and roles (binary relations).