Agenda

  • Motivation
  • Overview and Principles
  • Annotations
  • Ontologies
  • Web Services
  • Goals
  • Mediators
  • WSML
  • WSMX
  • Illustration by a larger example
  • Extensions
  • Summary
  • References 


Motivation for Semantic Web Service (SWS)

  • In traditional SOA the human needs to inspect manually service descriptions, understand service parameters, communication protocols, etc. All these task hinder scalability of SOA, therefore there is a need to go from syntax to semantics when deal with SOA.


Motivation for Semantic Web Service (contd')

  • Current technologies allow usage of Web Services
  • But:
    • Only syntactical information descriptions
    • Syntactic support for discovery, composition and execution  
    • Web Service usability, usage, and integration needs to be inspected manually
    • No semantically marked up content / services
    • No support for the Semantic Web 
  • Initial Web Service Technology Stack failed to realize the SOA Vision 
    • Problem : Lack of technologies to cope with the scale envisioned for WS  Solution : Techniques for automated support for service related tasks



So what is needed?

  • Mechanized support is needed for
    • Annotating/designing services and the data they use
    • Finding and comparing service providers
    • Negotiating and contracting services
    • Composing, enacting, and monitoring services
    • Dealing with numerous and heterogeneous data formats, protocols and processes, i.e. mediation
  • Conceptual Models, Formal Languages, Execution Environments
  • Existing approaches to SWS (OWL-S, SWSF, WSDL-S) do not provide a unifying solution for SWS
    • WSMO Approach


Approach Overview



Design Principles



Design Principles (contd')

  • Web Compliance
    • WSMO inherits the concept of URI (Universal Resource Identifier) for unique identification of resources as the essential design principle of the Word Wide Web
    • WSMO adopts the concept of Namespaces for denoting consistent information spaces, supports XML and other W3C Web technology recommendations, as well as the decentralization of resources
  • Ontology-Based
    • Ontologies are used as the data model throughout WSMO
    • All resource descriptions as well as all data interchanged during service usage are based on ontologies
    • WSMO supports the ontology languages defined for the Semantic Web
  • Strict Decoupling
    • WSMO resources are defined in isolation
    • Each resource is specified independently without regard to possible usage or interactions with other resources



Design Principles (contd')

  • Centrality of Mediation
    • Complementary design principle to strict decoupling
    • Mediation addresses the handling of heterogeneities that naturally arise in open environments
    • Heterogeneity can occur in terms of data, underlying ontology, protocol or process. 
    • Mediation a first class component of the WSMO framework
  • Ontological Role Separation 
    • Users, or more generally clients, exist in specific contexts which will not be the same as for available Web services
    • The underlying epistemology of WSMO differentiates between the desires of users or clients and available services
  • Description versus Implementation
    • WSMO differentiates between the descriptions of Semantic Web services elements (description) and executable technologies (implementation)
    • WSMO aims at providing an appropriate ontological description model, and to be complaint with existing and emerging technologies


Design Principles (contd')

  • Execution Semantics 
    • In order to verify the WSMO specification, the formal execution semantics of reference implementations like WSMX as well as other WSMO-enabled systems provide the technical realization of WSMO
  • Service versus Web service 
    • A Web service is a computational entity which is able (by invocation) to achieve a users goal. 
    • A service in contrast is the actual value provided by this invocation 
    • WSMO provides means to describe Web services that provide access (searching, buying, etc.) to services; WSMO is designed as a means to describe the former and not to replace the functionality of the latter


Top-level elements defined by WSMO



Web Service Modeling Framework (WSMF)

  • The Web Service Modeling Ontology (WSMO) is derived from and based on the Web Service Modeling Framework (WSMF)
  • WSMF provides the appropriate conceptual model for developing and describing web services and their composition
  • WSMF is based on the following principle:
    • Strong de-coupling of the various components that realize an e-commerce application
    • Strong mediation service enabling anybody to speak with everybody in a scalable manner.
  • WSMF consists of four main different 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
    • mediators which bypass interoperability problems.


Dublin Core

  • The Dublin Core metadata element set is a standard for cross-domain information resource description.
  • An architecture and abstract model that can be used to develop application profiles to describe resources in a machine processable manner.
  • 15 elements or attribute-value pairs – “simple DC”
  • 55 elements or attribute-value pairs – “qualified DC”
  • Elements may be displayed in any order
  • Extensible 
  • International in scope


Annotations

  • Annotations are used in the definition of WSMO elements (reuse of Dublin Core metadata elements)
  • Each WSMO element has an attached set of annotations




WSMO – Ontologies

In WSMO, Ontologies are the key to linking conceptual real-world semantics defined and agreed upon by communities of users

 Class ontology sub-Class wsmoElement
      importsOntology type ontology
     usesMediator type ooMediator
      hasConcept type concept
      hasRelation type relation
      hasFunction type function
      hasInstance type instance
      hasRelationInstance type relationInstance
      hasAxiom type axiom 

Examples:

  • The Location Ontology
    (http://www.wsmo.org/ontologies/location)
    contains the concepts “Country” and “Address”
  • The Location Ontology
    (http://www.wsmo.org/ontologies/location)
    contains the “Austria” and “Germany” instances



Ontology Specification

  • Non functional properties author, date, ID, etc. 
  • Imported Ontologies importing existing ontologies where no heterogeneities arise 
  • Used mediators OO Mediators (ontology import with terminology mismatch handling)
  • Ontology Elements:
    Concepts set of entities that exists in the world / domain 
    Attributes set of attributes that belong to a concept
    Relations define interrelations between several concepts
    Functions special type of relation (unary range = return value) 
    Instances set of instances that belong to the represented ontology
    Axioms axiomatic expressions in ontology (logical statement) 


WSMO Ontologies – Concepts

  • Concepts constitute the basic elements of the agreed terminology for some problem domain
    • From a high-level perspective, a concept – described by a concept definition – provides attributes with names and types
    • A concept can be a subconcept of several (possibly none) direct superconcepts as specified by the isA-relation

      Class concept sub-Class wsmoElement 
      hasSuperConcept type concept
      hasAttribute type attribute
      hasDefinition type logicalExpression multiplicity = single-valued
      Class attribute sub-Class wsmoElement

      hasRange type concept multiplicity = single-valued

  • Example: The concept “Border” defines the border between two countries. It is a subclass of a more general concept “GeographicLocation”. It has two attributes countryA and countryB whose ranges are instances of concept “Country”



Logical Expressions for the Definition of Concepts

  • The definition of a concept is a logical expression which can be used to define formally the semantics of the concept
    • The logical expression defines (or restricts, respectively) the extension (i.e. the set of instances) of the concept. If C is the identifier denoting the concept then the logical expression takes one of the following forms 
      forAll ?x ( ?x memberOf C implies l-expr(?x) ) 
      forAll ?x ( ?x memberOf C impliedBy l-expr(?x) ) 
      forAll ?x ( ?x memberOf C equivalent l-expr(?x) ) 
      where l-expr(?x) is a logical expression with precisely one free variable ?x
  • Example: The concept “Human” is defined as the intersection of the concepts “Primate” and “LegalAgent”



WSMO Ontologies – Relations

  • Relations are used in order to model interdependencies between several concepts (respectively instances of these concepts)

    Class relation sub-Class wsmoElement
    hasSuperRelation type relation 
    hasParameter type parameter
    hasDefinition type logicalExpression multiplicity = single-valued
    Class parameter sub-Class wsmoElement 
    hasDomain type concept multiplicity = single-valued
  • Example: The relation “distanceInKm” has three parameters: two concepts and an integer. The relation represents the distance between two cities. It is a sub-relation of the measurement relation.




Logical Expressions for the Definition of Relations

  • The definition of a relation is a logical expression defining the set of instances (n-ary tuples, if n is the arity of the relation) of the relation
    • If the parameters are specified, the relation is represented by an n-ary predicate symbol with named arguments If R is the identifier denoting the relation, then the logical expression takes one of the following forms:

      forAll ?v1,...,?vn ( R[p1 hasValue ?v1,...,pn hasValue ?vn] implies l-expr(?v1,...,?vn) ) 
      forAll ?v1,...,?vn ( R[p1 hasValue ?v1,...,pn hasValue ?vn] impliedBy l-expr(?v1,...,?vn) ) 
      forAll ?v1,...,?vn ( R[p1 hasValue ?v1,...,pn hasValue ?vn] equivalent l-expr(?v1,...,?vn) ) 
    • If the parameters are not specified, then the relation is represented by a predicate symbol where the identifier of the relation is used as the name of the predicate symbol. If R is the identifier denoting the relation, then the logical expression takes one of the following forms:

      forAll ?v1,...,?vn ( R(?v1,...,?vn)  implies l-expr(?v1,...,?vn) ) 
      forAll ?v1,...,?vn ( R(?v1,...,?vn)  impliedBy l-expr(?v1,...,?vn) ) 
      forAll ?v1,...,?vn ( R(?v1,...,?vn)  equivalent l-expr(?v1,...,?vn) ) 

      where l-expr(?v1,...,?vn) is a logical expression with precisely ?v1,...,?vn as its free variables and p1,...,pn are the names of the parameters of the relation


WSMO Ontologies – Instances

  • Instances are either defined explicitly or by a link to an instance store, i.e., an external storage of instances and their values
  • An explicit definition of instances of concepts is as follows:

    Class instance sub-Class wsmoElement
    hasType type concept

    hasAttributeValues type attributeValue

    Class attributeValue sub-Class wsmoElement
    hasAttribute type attribute multiplicity = single-valued
    hasValue type {instance, literal, anonymousId}

  • Example: Mary is parent of the twins Paul and Susan

  • Instances of relations (with arity n) can be seen as n-tuples of instances of the concepts which are specified as the parameters of the relation 

    Class relationInstance sub-Class wsmoElement 
    hasType type relation
    hasParameterValue type parameterValue

    Class parameterValue sub-Class wsmoElement
    hasParameter type parameter multiplicity = single-valued
    hasValue type {instance, literal, anonymousId} multiplicity = single-valued
  • Example: The distance between Innsbruck and Munich is 234 kilometers



  



WSMO – the Web Service Element

  • WSMO Web service descriptions consist of non-functional, functional, and the behavioral aspects of a Web service
  • A Web service is a computational entity which is able (by invocation) to achieve a users goal. A service in contrast is the actual value provided by this invocation


WSMO – Web Service Non-Functional Properties

  • Non-functional properties:
    • Accuracy - the error rate generated by the service
    • Financial - the cost-related and charging-related properties of a service 
    • Network-related QoS - QoS mechanisms operating in the transport network which are independent of the service
    • Performance - how fast a service request can be completed
    • Reliability - the ability of a service to perform its functions (to maintain its service quality)
    • Robustness - the ability of the service to function correctly in the presence of incomplete or invalid inputs. 
    • Scalability - the ability of the service to process more requests in a certain time interval
    • Security - the ability of a service to provide authentication, authorization, confidentiality, traceability/auditability, data encryption, and non-repudiation 
    • Transactional - transactional properties of the service
    • Trust - the trust worthiness of the service
  • Example: If the client is older than 60 or younger than 10 years old the invocation price is lower than 10 euro


WSMO – Web Service Capability

  • A capability defines the Web service by means of its functionality

    Class capability sub-Class wsmoElement
    importsOntology type ontology
    usesMediator type {ooMediator, wg
    Mediator}hasNonFunctionalProperties type nonFunctionalProperty
    hasSharedVariables type sharedVariables
    hasPrecondition type axiom
    hasAssumption type axiom
    hasPostcondition type axiom
    hasEffect type axiom
  • Example: The input for a birth registration service in Germany has to be boy or a girl with birthdate in the past and be born in Germany. The effect of the execution of the service is that after the registration the child is a German citizen.
  • Precondition - the information space of the Web service before its execution
  • Assumption - the state of the world before the execution of the Web service
  • Postcondition - the information space of the Web service after the execution of the Web service
  • Effect - the state of the world after the execution of the Web service
  • Shared Variables - variables that are shared between preconditions, postconditons, assumptions and effects


WSMO – Web Service Interface

  • An interface describes how the functionality of the Web service can be achieved (i.e. how the capability of a Web service can be fulfilled) by providing a twofold view on the operational competence of the Web service:
    • Choreography decomposes a capability in terms of interaction with the Web service
    • Orchestration decomposes a capability in terms of functionality required from other Web services

      Class interface sub-Class wsmoElement 
      importsOntology type ontology
      usesMediator type ooMediator 
      hasNonFunctionalProperties type nonFunctionalProperty
      hasChoreography type choreography
      hasOrchestration type orchestration


WSMO Choreography: An Abstract State Machine Model (1)

  • Why ASMs-based model?
    • Minimality: ASMs are based on a small assortment of modeling primitives
    • Expressivity: ASMs can model arbitrary computations
    • Formality: ASMs provide a formal framework to express dynamics
  • Basic mechanism in ASMs:
    • A signature defines predicates and functions to be used in the description. Ground facts specify the underlying database states. 
    • State changes are described using transition rules, which specify how the states change by falsifying (deleting) some previously true facts and inserting (making true) some other facts.


Abstract State Machines

  • Basic ASM are finite sets of conditional state transition rules of the form:
    if Condition then Updates
  • A state is represented by a first order structure; a set with relations and functions
  • Every algorithm can be rewritten as a finite number of transition rules
  • Signature is a finite collection of function names
    • each name comes with an indication of its arity
      \[ f(t_{1},...,t_{n}):=t \]
  • Updates is a finite set of assignments of the form
  • Execution can be understood as changing (or defining, if there was none) in parallel the value of the occurring functions f at the indicated arguments to the indicated value 
  • A guarded rule is a transition
    if Condition then Updates
    where Condition is the guard under which a rule is applied
  • A set of guarded updates are written usually as a list 
  • They are executed in parallel, so order is immaterial
  • All guarded updates on the list are performed simultaneously
  • Execution of an ASM
    • Check which rules apply
    • Randomly select a/all rule(s)
    • Perform update


WSMO Choreography: An Abstract State Machine Model (2)





WSMO Goals

  • Goals are representations of an objective for which fulfillment is sought through the execution of a Web service. Goals can be descriptions of Web services that would potentially satisfy the user desires

    Class goal sub-Class wsmoElement 
    importsOntology type ontology
    usesMediator type {ooMediator, ggMediator}
    hasNonFunctionalProperties type nonFunctionalProperty 
    requestsCapability type capability multiplicity = single-valued
    requestsInterface type interface 
  • Example: A person named Paul has to goal to register his son with the German birth registration board



Example: Web Service Discovery

  • Distinguish between abstract service and a specific one
    • Abstract service: a computational entity able to provide many services
    • Service: a concrete invocation of a Web service
  • The task
    • Client is interested in getting a specific service
    • Identify possible service providers, which may be able to provide the requested service S for its clients
  • Discovery
    • Given a goal and some Service repository determine the set of relevant service providers


Example: Web Service Discovery (cont’)



 



WSMO Mediators

  • Mediation
    • Data Level - mediate heterogeneous Data Sources 
    • Protocol Level - mediate heterogeneous Communication Patterns 
    • Process Level - mediate heterogeneous Business Processes
  • Four different types of mediators in WSMO
    • ggMediators: mediators that link two goals. This link represents the refinement of the source goal into the target goal or state equivalence if both goals are substitutable
    • ooMediators: mediators that import ontologies and resolve possible representation mismatches between ontologies
    • wgMediators: mediators that link Web services to goals, meaning that the Web service (totally or partially) fulfills the goal to which it is linked. wgMediators may explicitly state the difference between the two entities and map different vocabularies (through the use of ooMediators)
    • wwMediators: mediators linking two Web services
  • Examples
    • The ooMediator identified by http://example.org/ooMediator translates the owl description of the iso ontology to wsml and adds the necessary statements to make them memberOf> loc:country concept of the wsmo location ontology
    • The ggMediator identified by http://example.org/ggMediator links the general goal of getting a citizenship with the concrete goal of registering George


WSMO Mediators (cont’)

Class mediator sub-Class wsmoElements
importsOntology type ontology
hasNonFunctionalProperties type nonFunctionalProperty
hasSource type {ontology, goal, webService, mediator} 
hasTarget type {ontology, goal, webService, mediator}

hasMediationService type {goal, webService, wwMediator}

Class ooMediator sub-Class mediator
hasSource type {ontology, ooMediator}

Class ggMediator sub-Class mediator
usesMediator type ooMediator
hasSource type {goal, ggMediator}
hasTarget type {goal, ggMediator} 

Class wgMediator sub-Class mediator
usesMediator type ooMediator
hasSource type {webService, goal, wgMediator, ggMediator}
hasTarget type {webService, goal, ggMediator, wgMediator}

Class wwMediator sub-Class mediator
usesMediator type ooMediator
hasSource type {webService, wwMediator}

hasTarget type {webService, wwMediator}



Example: Process Mediation

  • Heterogeneity may exist between exposed communication interfaces of service providers and those expected by service requesters
    • Messages in the wrong order
    • Messages sent separately that are expected together
    • Messages sent together that are expected separately
    • Messages sent that are never expected
    • Messages expected but never sent
  • Process Mediation required to addresses these heterogeneity issues and enable dynamic communication between requester and provider


Example: Process Mediation (cont’)

  • Design-time Process Mediation
    • Input: 2 or more processes
    • Output:  1 mediator process
    • Advantage: No un-solvable mismatches
    • Disadvantage: Manual -> Semi-automatic
    • Example: Process Mediation (cont’)  


Example: Process Mediation (cont’)

  • Run-time Process Mediation
    • Input: 2 or more processes
    • Output: -
    • Advantage: Automatic
    • Disadvantage: Un-solvable mismatches   


Example: Process Mediation (cont’)



Example: Process Mediation (cont’)




Web Service Modeling Language

  • A set of concrete languages for the various tasks:
    • Ontology / Rule Languages (static view)  
      • WSML Core
        • efficiency and compatibility
      • WSML DL
        • decidability, open world semantics
      • WSML Rule
        • efficient existing rule engines
      • WSML Full
        • unifying language, theorem proving
    • Languages for dynamics
      • Transaction Logic over ASMs
    • Mapping languages
      • for dynamics (process mediation)
      • or data (data mediation)  


    WSMX – Web Service Execution Environment

    • WSMX – reference implementation for WSMO/L
    • Architecture and execution environment


    SWS Scenario – Shipment Discovery (1)

    Aim: automatically find shipment services

    • The scenario is about how to identify possibly relevant services.
    • With an invocation of one of the Web Services you can order a shipment by specifying, senders address, receivers address, package information and a collection interval during which the shipper will come to your premises to collect the package. 
    • The request contains the interval in which the shipper shall come to the requesters premises to pick up the package. 
    • A shipper either responses with the estimated pickup (respecting the given time constraints) or with a fault message indicating that a pick up is not possible in the requested time interval. 
    • If no constraints on the business hours (earliest and latest pick up time) are given one can assume 8am to 8pm. If a shipper specifies a constraint on how long in advance a shipment can be ordered, this means that the requested collection interval must end before this date. If no constraints on the length of the interval is given one can assume that a shipper requires at least an interval of 60 Minutes. 


    SWS Scenario – Shipment Discovery (2)

    • All dates and times in the advertised services are assumed to be local to the shippers' office. 
    • For simplicity we only regard Sundays as non-business days. 
    • All prices are assumed to be in US dollars unless otherwise stated. 
    • If your package has a large size-to-weight ratio, you may need to consider your package's dimensional weight. The weight that is used to determine the price of a package, respectively that is considered with respect to the maximum weight restriction of a shipper is the maximum value of its actual and its dimensional weight. The dimensional weight is calculated as follows: Dimensional Weight = (L*W*H)/166 [where L = length, W= width, and H=height] L*W*H yields an amount in cubic inches and is rounded up to the nearest pound. 
    • We use the definition of continents and countries given by the United Nations
    • Each shipper has a guaranteed delivery time. The delivery time is specified in days. The first day of delivery is the day after the package has been picked up. The times are always local.


    Examples of ontology elements for the shipment discovery scenario

    • Ontology ShipmentOntology has annotations, dc#title (has value "Shipment Domain Ontology“), dc#contributor (has value "Maciej Zaremba, Matt Moran“, dc#date (has value 2006.10.23), 
    • Ontology ShipmentOntology has concepts:
      • OrderRequest has annotation dc#description whose value is "Information provided for a pickup request“ and has a set of attributes: from (of type ContactInfo), to (of type ContactInfo), type (of type ShipmentType), package (of type Package)
      • Package has annotation dc#description whose value is "concept of a package“ and a set of attributes: quantity (of type integer), length (of type decimal), width (of type decimal), height (of type decimal), weight (of type decimal)
      • Country has annotation dc#description whose value is "concept of a country“ and attributes name (of type string), continent (of type Continent)


    Examples of ontology elements for the shipment discovery scenario (cont’)

    • Ontology ShipmentOntology has relations:
      • cityIsOnContinent (relation that holds between a city and the continent it belongs to) with two parameters whose types are City and Continent
      • cityIsInCountry (relation that holds between a city and the country it belongs to) with two parameters whose types are City and Country 
    • Ontology ShipmentOntology has instances:
      • Europe (member of Continent) whose name has value "Europe“
      • NY (member of City) whose name has value "New York“ and country has value USA
      • Luxembourg (member of City) whose name has value "Luxembourg“ and country hasvalue LuxembourgCountry
    • Ontology ShipmentOntology has the axiom:
      • cityIsOnContinentDef defined by a logical formula that states that if a given city is in a certain country and that country is in a certain continent, then the given city is part of that continent


    Examples of Shipping Services

    • Muller 
      Rates on Request 
      Only packages weighing 50 lbs or less are shipped 
      Ships to Africa, North America, Europe, Asia (all countries) 
    • Constraints on Collection: 
      • There must be at least an interval of 90 minutes for collection. 
      • Collection is possible between 7am and 8pm. 
      • Collection can be ordered max 2 working days in advance. 
    • Delivery Time: 
      • Ships in 2/3 (domestic/international) business days if collected by 5pm; 
    • In WSMO: 
      The WSMuller Web Service has a set of annotations: dc#title (has value "Muller Web Service“), dc#description (has value "We ship to Africa, North America, Europe, Asia (all countries).“), dc#contributor (has value "Maciej Zaremba, Matt Moran“.

      The WSMuller Web Service imports the ShipmentOntology and the ShipmentOntologyProcess ontologies.

      The WSMuller Web Service Capability WSMullerCapability has a precondition stating that before the execution of the service there must be an order request containing a request for a package weighing 50 lbs or less, and that the destination mentioned in the request should be a location in Africa, North America, Europe, or Asia. In case the request contains a collection, additional conditions are imposed on the request (e.g. the collection can be ordered max 2 working days in advance).

      The WSMuller Web Service Capability WSMullerCapability has a postcondition stating that after the execution of the service there will be an order response which will contain the shipping price for the package described in the precondition.

      The WSMuller Web Service Choreography will describe a state signature containing the order request and response concepts with the modes “in”, resp “out”. There will be one transition rule stating that for all requests a response will be added to the knowledge base.


    Examples of Shipping Services (cont')

    • Racer 
      Rates(flat fee/each lb): Europe(41/6.75), Asia(47.5/7.15), North America(26.25,4.15), Rates for South America like North America, Rates for Oceania like Asia
      Furthermore for each collection order 12.50 are added! 
      List of Countries Racer ships to is included in the WSDL file 
      Only packages weighing 70lbs or less are shipped 
      Constraints on Collection: 
      • There should be at least an interval of 120 minutes for collection. 
      • Latest Collection time is 8pm. 
      Delivery Time:
      • Ships in 2/3 (domestic/international) business days if collected by 6pm; 


    Examples of Shipping Services (cont')

    • Runner 
      Rates(flat fee/each lb): Europe(50/5.75), Asia(60/8.5), North America(15/0.5), South America(65.75/12), Africa (96.75/13.5), Oceania has the same rates then Asia 
      Exact list of countries included in WSDL file 
      When ordering a shipment using the Web Services, per invocation the shipment of one package can be ordered. 
      If package weight exceeds 70 lbs, weight, length and height are required (the order has to be done via phone or fax) 
      Constraints on Collection: 
      • Collection can be ordered max 5 working days in advance. 
      • Minimum Advance notice for collection is 1 hour 
      • Collection is possible between 1am - 12pm 
      • There must be at least an interval of 30 minutes for collection. 
      Delivery Time: 
      • Ships in 2 business days if collected by 10am; 
      • Ships in 3 business days otherwise.


    Examples of Shipping Services (cont’)

    • Walker 
      Rates(flat fee/each lb): Europe(41/5.5), Asia(65/10), North America(34.5/3), South America (59/12.3), Africa (85.03/13), Rates for Oceania like Asia 
      Only packages weighing 50 lbs or less are shipped 
      Exact list of countries included in WSDL file 
      Constraints on Collection: 
      • Shipment can be ordered maximum 2 business days in advance (the end of the pickup interval must be at most two business days in advance at the time of ordering). 
      • pickup time must be between 6 am and 11.00pm. 
      • There must be at least an interval of 30 minutes for collection. 
      Delivery Time 
      • Ships in 2 business days if collected by 5pm 
    • Weasel 
      Rates(flat fee/each lb): United States(10/1.5) 
      Delivery only in United States 
      Constraints on Collection 
      • the pick up interval must be at least 5 hours 
      • the max. pick up interval is 4 days 
      • collection can be ordered until 8pm 
      Delivery Time 
      • 1 day if collected before 2pm


    Examples of goals


    • Goal C3
      to Smithers (Bristol) 
      no of packages: 1 
      package dimensions: (l/w/h) 10/2/3 (inch) 
      package weight: 20 lbs 
      for less than 120$   

    Result of Discovery Process

    • Muller (includes a request For quote) 
      NOT: Racer (price is 176$) 
      NOT: Runner (price is 176$) 
      NOT: Walker (price is 151$)
      NOT: Weasel (ships not to UK
    • Goal D1
      to Szyslak (Tunis) 
      no of packages: 2 
      package dimensions: (l/w/h) 5/3/2 (inch) 
      package weight: 60 lbs (each)

    • Runner 2 invocations, since schema does not allow to order multiple packages in one invocation) 
      NOT: Racer (does not ship to Tunesia) 
      NOT: Muller(does only ship 50lbs) 
      NOT: Walker (does only ship 50lbs) 
      NOT: Weasel (does not ship to Tunesia)
     
    • Goal E1
      to Gumble (New York) 
      package dimensions: (l/w/h) 10/2/3 (inch) 
      package weight: 5 lbs 
      for less then 20$ 
      Current Time is 7:30 am 
      Next day delivery



    • Weasel NOT: Muller (2 days) 
      NOT: Racer (2 days) 
      NOT: Runner (3 days) 
      NOT: Walker (2 days)
    • Goal G3 in WSMO:   
      The Goal C3 has a set of annotations: dc#title (has value "Goal C3“), dc#description (has value "Goal of shipping a package to Smithers (Bristol), no of packages: 1, package dimensions: (l/w/h) 10/2/3 (inch), package weight: 20 lbs, for less than 120USD“), dc#contributor (has value "Maciej Zaremba, Matt Moran, Tomas Vitvar, Thomas Haselwanter“)
      The Goal C3 imports the ShipmentOntology and the ShipmentOntologyProcess ontologies.
      The Goal C3 requested capability has the postcondition stating that the user wants to ship one package with dimensions 10/2/3 (l/w/h) and weight 20 lbs to a specific destination in Bristol. Additionally, in the postcondition is stated that price of the shipment must be less than 120USD.


    WSMO-Lite

    • WSMO-Lite ontology of service semantics describes services for SWS automation
    • SAWSDL puts pointers to WSMO-Lite semantics in WSDL
    • MicroWSMO and hRESTS are lightweight equivalents for SAWSDL and WSDL for RESTful services  


    Semantics in Service Model

    • Using SAWSDL modelReferences, the four kinds of semantics are attached to the service model: functional and nonfunctional properties to the service, behavioral properties to the operations, and information model properties to the input and output messages (and the fault messages as well).


    MicroWSMO

    • Extends hRESTS
      • model for model references
      • lifting, lowering 
    • Applies WSMO-Lite semantics




    Summary

     
    • Semantic Web Services
      • Have the potential of improving the usability of services
      • Lots of progress in the last years
    • The WSMO Approach is an active initiative in the area of SWS
      • The WSMO conceptual model consists of four core elements: Ontologies, Web Services, Goals, and Mediators
    • Standardization based on the WSMO Approach is emerging
      • OASIS SEE TC



    References

    • http://www.wsmo.org/TR/d2/v1.3/
    • D. Fensel, H. Lausen, A. Polleres, J. de Bruijn, M. Stollberg, D. Roman, and J. Domingue. Enabling Semantic Web Services - The Web Service Modeling Ontology. Springer, 2006.
    • http://www.wsmo.org/TR/d3/d3.4/v0.1/
    • http://www.wsmo.org/
    • http://www.wsmo.org/TR
    • http://cms-wg.sti2.org/
    • http://www.wsmo.org/wsml
    • http://cms-wg.sti2.org/TR/d11/v0.3/
    • http://www.wsmx.org/
    • http://sourceforge.net/projects/wsmx
    • http://wsmt.sourceforge.net
    • http://www.wsmostudio.org 
    • http://www.oasis-open.org/committees/semantic-ex/
    • http://en.wikipedia.org/wiki/WSMO




    Creator: sidraaslam

    Contributors:
    -


    Licensed under the Creative Commons
    Attribution ShareAlike CC-BY-SA license


    This deck was created using SlideWiki.