Scenario: Shipment Discovery v2

From Swsc-WIKI
Jump to: navigation, search

Contents

This is a draft page

for an update of the original Shipment Discovery Scenario. It is under development and has not been released yet.

Introduction

The Discovery Scenario v2 is orthogonal to the integration/mediation problems. The integration problems can be solved with current syntactic technologies, however it shall be shown how semantic annotation can be used to make this task easier and more flexible. This discovery scenario - that a new supplier has to be found - is a more visionary scenario, since in present business scenarios this task always involves a human in the loop.

The task to be solved in this scenario is identifying shipping services relevant to a concrete shipping request, selecting the most suitable one and invoking it automatically with the proper inputs. Several concerete shipping requests focus on different functional challenges involved in this task, including the evaluation of discrete matchmaking rules, the handling of numbers, temporal reasoning, data mediation, lowering and lifting, or the inquiry of dynamic information during the matchmaking.

The [source code] for the complete scenario is available.

The scenario is complemented by the Hardware Purchasing Scenario, which focuses on user preferences and simple service composition, and by the Logistics Management Scenario, which further focuses on ranking of services via soft constraints and preferences and on mediating between different domain terminologies.

Shipping Services

You can have a look at the implementation at [1] in case you find any of the textual descriptions ambiguous, the behavior of the implementation is normative. With an invocation of one of the Web Services you can order a shipment by specifying, senders address, receivers address, package information and optionally a collection interval during which the shipper will come to your premises to collect the package.

The shippers of this scenario are characterized by the following properties:

Geographic operation range: Shippers operate in a specified geographic range. If a shipper specifies a list of countries in its interface definitions (WSDL) it only ships to this countries (Racer, Runner, Walker), otherwise: if the shipper lists a rate for a continent then it ships to each country in that continent.

All shipping services are valid only for collection in the United States!

We use the definition of continents and countries given by the United Nations, however since we do not regularly update this information, it might be the case that the behavior of the implementation and the official UN definition is apart, for the country/continent list used, see [2]. We use the following continents: 'Africa','Antarctica','Asia','Europe','North America','Oceania','South America'.

Date and time specifications: Shippers specify restrictions on the collection and shipping time. Note that all all dates and times in the advertised services are assumed to be local to the shippers' office. Thus the California sender can assume the local collection times are PDT or PST as appropriate. For simplicity we only regard Sundays as non-business days.

Pickup interval: A request may specify 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. We provide a textual description of this behavior for each shipper below. 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.

Delivery time: 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. E.g., if a shipper guarantees a shipment from Stanford/US in 2 days to Berlin/Europe this means if the package is picked up at 01.01.1970 08:00 PDT it is guaranteed to be in Berlin before 03.01.1970 24:00 CET, unless. If the shipper guarantees a shipment in 2 business days, Sundays (and only Sundays) do not count, i.e., the above mentioned shipment is guaranteed to be in Berlin only before 04.01.1970 if the 2nd or 3rd is a Sunday.

Dimensional weight: If your package has a large size-to-weight ratio, some shippers require 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, H=height, all values specified in inches] The formula yields an amount in cubic inches and is rounded up to the nearest pound. E.g., for a package with dimensions 40/24/10 (inch), the dimensional weight is 58 lbs.

Runner and Racer do not use the notion of dimensional weight, Muller, Walker and Weasel do (see service WSDLs)!

Price specifications: All prices are assumed to be in US dollars unless otherwise stated.

Prices are typically specified via a flat fee and a fee per pound, like "Rates(flat fee/each lb): Europe(41/6.75)". The flat fee covers the first pound of a package. Each additional started pound is charged the full fee per pound. I.e., a package of 3.7 pounds to Europe in the example above costs $ 61,25 ($ 41.0 flat fee for the first pound plus three times $ 6.75 for the next 2.7 pounds). One service, Muller, does not specify prices but requires to invoke an endpoint to dynamically inquire about the price of a shipment.

Multiple packages: Please note (see service's WSDLs) that Runner, Walker and Weasel do not support the ordering of multiple packages to be sent. Muller supports the sending of multiple packages, but only to the same address. Racer fully supports sending of multiple packages. In case multiple packages must be sent but a shipper does not support the sending of multiple packages, the order needs to be split such that one goal results in multiple service invocations.

Muller

  • Rates on Request (cf. invokePrice operation within the WSDL)
  • 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;
  • Endpoint: http://sws-challenge.org/shipper/v2/muller.wsdl
    For test purposes you may use Mindreef WSDL invoker

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;
  • Endpoint: http://sws-challenge.org/shipper/v2/racer.wsdl
    For test purposes you may use Mindreef WSDL invoker

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). For goals that require automatic invocation of the most suitable shipper (currently all goals) this implies that Runner does not qualify.
  • 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 (keep in mind that 12pm is noon!)
    • 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.
  • Endpoint: http://sws-challenge.org/shipper/v2/runner.wsdl
    For test purposes you may use Mindreef WSDL invoker

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
  • Endpoint: http://sws-challenge.org/shipper/v2/walker.wsdl
    For test purposes you may use Mindreef WSDL invoker

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
  • Endpoint: http://sws-challenge.org/shipper/v2/weasel.wsdl
    For test purposes you may use Mindreef WSDL invoker

Discovery Requests

In the following, we present different concrete shipping requests and their expected matches. The goals are organized in subsection according to their anticipated difficulty. Each shipping request must result in the invocation of a suitable shipper, i.e., a shipper that does not violate any of the constraints specified in the request. The shipper must be called with proper input data representing the information specified in the request.

If one of the shipment services is correctly invoked the order will be saved to our evaluation system (see our Web view). Correctly means in this sense that an invocation does not cause a SOAP fault message. One exception from this rule is the treatment of time constraints: If the SOAP fault is caused due to incorrect specification of the pickup time, the order will still be recorded, but with a note that an incorrect time was submitted.

We provide a simple interface that enables you to view the orders that have been submitted to the different shipment companies. You can filter the information by IP Address of the invoker, such that you can easily follow the behavior of your discovery system.

We have tested the services thoroughly, however if it some endpoint does not behave correctly please contact Srdjan Komazec. We have compiled a set of sample messages that are generate based on the information presented below.

For the goals (discovery requests) that have to be resolved we use a set of fixed addresses. The package are always sent from Michael Moon's address.

Moon:

Mr. Michael Moon, Moon Company
Moon Road 13, 1234 Moon City, California, US
Tel: +1 424242, Fax: +1 424243
EMail: michael.moon@moon.ie </dd>

Smithers:

Mr. Wayne Smithers, Computer Systems & Co
20 Denmark Street, Bristol, BS1 5DH, United Kingdom
Tel: +44 235 235, Fax: +44 235 236
EMail: Wayne.Smithers@example.org </dd>

Szyslak:

Mr. Moe Szyslak, 105, Avenue de la Libert.
Tunis, 10002, Tunisia
Tel: +71 235 235, Fax: +71 235 236
EMail: Moe.Szyslak@example.org</dd>

Gumble:

Mr. Barney Gumble, 320 East 79th Street.
New York, 10021, NY, United States
Tel: +71 235 235, Fax: +71 235 236
EMail: Barney.Gumble@example.org</dd>

Burns:

Mr. George Burns, 4 Avenue de la Gare.
1610 Luxembourg, Luxembourg
Tel: +352 152 152, Fax: +352 123 123
EMail: George.Burns@example.org</dd>

Soonie:

Ms. Electra Soonie, 5-3-1 Ginza
Tokyo, 104-0061, Japan
Tel: +81 3 123 456
EMail: Electra@soonie.jp</dd>


A - Discovery Based on Destination

These goals are designed such that they require checking the geographic coverage of shipping services but there is no necessity to check weight or dimension limitations, care of the dimensional weight rules or any rules related to price computations.

Goal A1

  • to: Szyslak (Tunis)
  • package dimensions: (l/w/h) 7/6/4 (inch)
  • package weight: 1 lb 
=> Muller, Runner, Walker
NOT: Racer (does not ship to Tunesia)
NOT: Weasel (does not ship to Tunesia)

Goal A2

  • to: Burns (Luxembourg)
  • package dimensions: (l/w/h) 7/7/5 (inch)
  • package weight: 1.5 lbs 
=> Muller
NOT: Runner (does not ship to Luxembourg)
NOT: Walker(does not ship to Luxembourg)
NOT: Racer (does not ship to Luxembourg)
NOT: Weasel (does not ship to Luxembourg)

B - Discovery Based on Weight

These goals require modeling the dimensional weight rules but do not require checking the destination address (all services operate in the U.S.).

Goal B1

  • to: Gumble (New York)
  • package dimensions: (l/w/h) 40/10/10 (inch) (dimensional weight 25 lbs)
  • package weight: 55 lbs 
=> Runner, Racer, Weasel
NOT: Muller (weight limit 50 lbs)
NOT: Walker (weight limit 50 lbs)

Goal B2

  • to: Gumble (New York)
  • package dimensions: (l/w/h) 40/24/10 (inch) (dimensional weight 58 lbs)
  • package weight: 40 lbs 
 => Racer, Runner, Weasel
NOT: Muller (dimensional weight limit 50 lbs)
NOT: Walker (dimensional weight limit 50 lbs)

Goal B3

  • to: Gumble (New York)
  • package dimensions: (l/w/h) 30/30/13 (inch) (dimensional weight 71 lbs)
  • package weight: 40 lbs 
 => Racer, Weasel
NOT: Muller (dimensional weight limit 50 lbs)
NOT: Runner (dimensional weight limit 70 lbs)
NOT: Walker (dimensional weight limit 50 lbs)

C - Discovery based on Destination and Price

These goals do not require to check for the weight or dimensional weight, but require to implement the price rules (including a dynamic request for quote by Muller) and check the geographic coverage of the shippers.

Goal C1

  • to Gumble (New York)
  • package dimensions: (l/w/h) 10/2/3 (inch)
  • package weight: 6 lbs
  • for less then 20$ 
=> Runner (price is 17.5$ = 15 + 5 * 0.5)
=> Weasel (price is 17.5$ = 10 + 5 * 1.5)
NOT: Muller (price is 35$)
NOT: Racer (price is 59.5$ = 26.25 + 5 * 4.15 + 12.5)
NOT: Walker (price is 49.5$ = 34.5 + 5 * 3)

Goal C2

  • to Gumble (New York)
  • package dimensions: (l/w/h) 10/2/3 (inch)
  • package weight: 10 lbs
  • package for 20$ or less 
=> Runner (price is 19.5$ = 15 + 9 * 0.5)
NOT: Muller (price is 47$)
NOT: Racer (price is 76.1$ = 26.25 + 9 * 4.15 + 12.5)
NOT: Walker (price is 61.5$ = 34.5 + 9 * 3)
NOT: Weasel (price is 23.5$ = 10 + 9 * 1.5)

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$ 
=>  Muller (price is 97$)
NOT: Racer (price is 181.75$ = 41 + 19 * 6.75 + 12.5)
NOT: Runner (price is 159.25$ = 50 + 19 * 5.75)
NOT: Walker (price is 145.5$ = 41 + 19 * 5.5)
NOT: Weasel (does not ship to UK)

Goal C4

  • to Soonie (Tokyo)
  • package dimensions: (l/w/h) 10/2/3 (inch)
  • package weight: 4.5 lbs
  • for less then 90$ 
=> Muller (price is 72$)
=> Racer (price is 88.6$ = 47.5 + 4 * 7.15 + 12.5)
NOT: Runner (price is 94$ = 60 + 4 * 8.5)
NOT: Walker (price is 105$ = 65 + 4 * 10)
NOT: Weasel (does not ship to Japan)

D - Discovery for multiple packages

These goals require shipping of multiple packages. Depending on whether services support this natively or not, this may require executing several service invocations for a single goal. Furthermore, the correct implementation of Racer's collection fee is tested.

Goal D1 (may be solved by a single or multiple service invocations)

  • 2 packages to Burns (Luxembourg)
  • Package 1:
    • package dimensions: (l/w/h) 7/7/5 (inch)
    • package weight: 1.5 lbs
  • Package 2:
    • package dimensions: (l/w/h) 7/5/1 (inch)
    • package weight: 0.5 lbs 
=> Muller
NOT: Runner (does not ship to Luxembourg)
NOT: Walker(does not ship to Luxembourg)
NOT: Racer (does not ship to Luxembourg)
NOT: Weasel (does not ship to Luxembourg)

Goal D2 (requires to be solved by a single service invocation)

  • 8 identical packages to Soonie (Tokyo)
  • package dimensions: (l/w/h) 8/5/1 (inch)
  • package weight: 0.8 lbs
  • for less then 400$ 
=> Racer (price is 392.5$ = 8 * 47.5 + 12.5, note that multiple invocations would result in a higher fee!)
NOT: Muller (price is 480$)
NOT: Runner (price is 480$ = 8 * 60)
NOT: Walker (price is 520$ = 8 * 65)
NOT: Weasel (does not ship to Japan)

Goal D3 (must be mapped to multiple service invocations)

  • to Szyslak (Tunis)
  • no of packages: 2
  • package dimensions: (l/w/h) 5/3/2 (inch)
  • package weight: 60 lbs (each)
  • destination: 
=>  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 D4 (requires to be solved by a single service invocation if Racer is used, but multiple if other combinations are used)

  • 1 package to Smithers (Bristol)
    • package dimensions: (l/w/h) 8/5/1 (inch)
    • package weight: 1.5 lbs
  • 2 packages to Soonie (Tokyo)
    • package dimensions: (l/w/h) 10/10/1 (inch)
    • package weight: 0.8 lbs
  • for less than 160$ 
=> Racer for the packages to Tokyo, Muller for the one to Bristol (price is 150,5$ = 12,5 + 2 * 47,5 + 43)
=> Racer for the packages to Tokyo, Walker for the one to Bristol (price is 154$ = 12,5 + 2 * 47,5 + 41 + 5,5)
=> Racer for all packages in single invocation (price is 155,25$ = 12,5 + 2 * 47,5 + 41 + 6,75)
NOT: Racer for all packages but single invocations (price at least 167,75$)
NOT: Weasel does not ship to Bristol or Tokyo
NOT: Runner and all other combinations are too expensive

Goal D5 (requires to be solved by a single service invocation in any case)

  • 1 package to Smithers (Bristol)
    • package dimensions: (l/w/h) 80/12/10 (inch)
    • package weight: 1.5 lbs
  • 2 packages to Soonie (Tokyo)
    • package dimensions: (l/w/h) 10/10/1 (inch)
    • package weight: 0.8 lbs
  • for less than 160$ 
=> Racer for all packages (price is 155,25$ = 12,5 + 2 * 47,5 + 41 + 6,75)
NOT: Muller, Walker (dimensional weight of package to Bristol is greater than 50)
NOT: Weasel (does not ship to Bristol or Tokyo
NOT: Runner (too expensive)

E - Discovery based on destination and temporal reasoning

These goals do not require the modeling of dimensional weight, no weight limitations need to be considered, there are no price constraints. The goals test the correct modeling of the constraints on the pickup interval. Some goals additionally require to reason about the constraints in the request and the services in order to determine a suitable pickup interval. Since shipping times may depend upon the destination address, the destination address needs to be checked, too.

Goal E1 (constraints on pickup interval by providers)

  • to Gumble (New York)
  • package dimensions: (l/w/h) 10/2/3 (inch)
  • package weight: 5 lbs
  • Current Time is 6:00 am on a business day
  • Collection between 6:00 am and 9:00 am today 
=> Muller (7:00 - 9:00 works)
=> Runner (7:00 - 9:00 works)
=> Walker (6:00 - 9:00 works)
NOT: Racer (earliest collection at 8:00, interval length at least 2 hours)
NOT: Weasel (earliest collection at 8:00, interval length at least 6 hours)


Goal E2 (constraints on pickup interval by providers, advance notification)

  • to Gumble (New York)
  • package dimensions: (l/w/h) 10/2/3 (inch)
  • package weight: 5 lbs
  • Current Time is 8:00 am on a Monday
  • Collection on Friday between 8:00 am and 13:00 am 
=> Racer (Friday, 8:00 - 13:00 is ok)
=> Runner (Friday, 8:00 - 12:00 is ok)
=> Weasel (Friday, 8:00 - 13:00 is ok)
NOT: Muller (collection can be ordered at most two business days in advance)
NOT: Walker (collection can be ordered at most two business days in advance)

Goal E3 (constraints on shipping time)

  • to Gumble (New York)
  • package dimensions: (l/w/h) 10/2/3 (inch)
  • package weight: 5 lbs
  • Current Time is 7:30 am on a business day
  • Collection between 7:30 am and 13 am today
  • Next business day delivery 
=>  Weasel (ships in 1 day if collected prior to 14:00)
NOT: Muller (2 days)
NOT: Racer (2 days)
NOT: Runner (3 days)
NOT: Walker (2 days)

Goal E4 (constraints on shipping time internationally, reasoning must figure out and provide suitable pickup times to guarantee fast collection)

  • to: Smithers (Bristol)
  • package dimensions: (l/w/h) 10/2/3 (inch)
  • package weight: 5 lbs
  • Current Time is 9:30 am
  • shipping is required in 2 business days 
=>  Walker (ships in 2 days if collected prior to 5 PM, Collection between 9:30 and 11:00 works, for instance)
NOT: Muller (3 days internationally)
NOT: Racer (3 days internationally)
NOT: Runner (3 days internationally)
NOT: Weasel (does not ship to Bristol)

Goal E5 (constraints on domestic shipping times, reasoning must figure out and provide suitable pickup times)

  • to Gumble (New York)
  • package dimensions: (l/w/h) 10/2/3 (inch)
  • package weight: 5 lbs
  • Current Time is 10 am
  • Next business day delivery 
=> From none of the description delivery is guaranteed.
PROBABLY: Weasel (requires 5 hours collection interval, only in case delivery happens by chance before 2 pm)
NOT: Muller (2 days)
NOT: Racer (2 days)
NOT: Runner (3 days)
NOT: Walker (2 days)

Main Contacts

If you are interested in presenting a solution to this scenario or have any questions, please don't hesitate to contact Ulrich Küster about general questions or Srdjan Komazec with any testbed related issues.

Credits

This scenario is an updated version of the original Shipment Discovery Scenario. The original scenario was designed by Holger Lausen, Michal Zaremba and Charles Petrie. The implementation has been done by Holger Lausen.

This updated version has been created by Ulrich Küster. Srdjan Komazec has implemented the necessary changes in the testbed.

Changes compared to the original version of the scenario

  • Clarification of Goal E1/E3 (changed "next day delivery" to "next business day delivery")
  • Clarification of Shipping Prices
    • Prices depended on destination, but not sender address. Scenario has been clarified to state that services are valid only for collection in the U.S.
    • Price specifications were inconsistent among the implementation, the WSDLs and the scenario specification. Specifications have been made clear and consistent.
  • Clarification that Runner does not qualify for packages exceeding 70 lbs if automatic service invocation is required.
  • Changes with respect to sending of multiple packages
    • Changed Racer's OrderOperationRequest to allow specifying multiple package weights.
    • Removed quantity element from Weasel's weaselOrderRequestType. (The original WSDL allows specification of multiple packages, but only of identical dimensions and weight. The changed WSDL does not support the specification of multiple packages).
    • Clarified which service do and do not support sending of multiple packages.
    • Clarified Muller's WSDL with respect to different options of specifying multiple packages and the meaning of the weight field in such cases.
  • Changes with request to dimensional weight (the usage of dimensional weight was inconsistent across the specifications, the WSDLs and the implementation). The new specifications are:
    • Racer and Weasel do not apply dimensional weight.
    • Muller, Runner and Walker apply dimensional weight. Muller and Walker require to provide the actual weight and compute the dimensional internally when checking for the price and any weight limitations. Runner requires to provide the maximum of the actual and the dimensional weight as the weight of a package in a shipping order.
  • Fixed bug in service implementations related to computation of pickup times.
  • Changes with respect to pickup times
    • Made provisioning of pickup times optional for all services. If no pickup time is provided, the shipper will determine a suitable pickup interval. This allows to have goals that do not require dealing with temporal aspects.
  • Changes in the goal hierarchy
    • A-Goals (Destination) unchanged
    • B-Goals (Weight), removed dependency from destination, added Goal B3 to check for correct rounding in computation of dimensional weight
    • C-Goals (Destination, Weight, Price), added Goal C4 to check for correct weight rounding in relation to price computations.
    • D-Goals (Multiple packages), added four goals to test various options with respect to mapping the shipment of multiple packages to multiple service invocations or handling it in a single service invocation (the latter is not supported by all services), for the correct implementation of Racer's collection fee, and the combination of different providers for different packages.
    • E-Goals (Temporal reasoning), redesigned to aim at clearer separation of concerns: E1 focuses on basic pickup time constraints, E2 adds advance notification requirements, E3-5 focus on shipping time. Generally, Goals E1-3 specify the collection interval in the request, E4-5 require to figure out a suitable interval autonomously.

Functional Challenge Matrix

Functional Challenge Matrix of the Shipment Discovery Scenario v2
Functional Challenge Related goals
A1 A2 B1 B2 B3 C1 C2 C3 C4 D1 D2 D3 D4 D5 E1 E2 E3 E4 E5
Basic discrete matchmaking
Discrete conditions
(Destinations address in the US, destination address in list of supported countries?) 		√ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √
Matching with hierarchical concept inclusions
(destination country in list of supported continents?) 		√ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √
Matching with numbers
Numeric comparisons
(weight smaller than, dimension larger than, price smaller than, ...) 		√ √ √ √ √ √ √ √ √ √ √
Arithmetic computations
(dimensional weight, price, ...) 		√ √ √ √ √ √ √ √ √
Matching with temporal reasoning
Special time instances (now, today, this week, next day, business days, ...) √ √ √ √ √
Basic Comparison of time instances (until, within interval, ...) √ √ √ √ √
Arithmetic computations with basic time aspects (current time + minimum advance notification interval = earliest possible pickup time) √ √ √ √
Arithmetic computations with advanced time aspects (within two business days = until now + two business days, ...) √ √
Rules
Conditional expressions
(shipping time depends on pickup time, ...) 		√ √ √
Conditional expressions including arithmetics
(price depends on weight, but formula to be chosen depends on destination, ...) 		√ √ √ √ √ √ √
Composition
Unrelated composition
(goal requires multiple invocations of the same service, goal can be split in independent subgoals) 		√ √
Correlated composition
(goal requires multiple invocations of the same service, goal can not be split in independent subgoals) 		√ √ √
Mediation
Data mediation between the semantic and syntactic level, lowering/lifting to/from differing XML element names and XML structures, lowering/lifting to/from differing string representations (e.g., for names and addresses, country names, etc.) √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √
Data mediation on the semantic level (goals and offers must be specified with respect to different terminologies)
Process mediation, determining whether a goal must be mapped dynamically to multiple service invocations or not √ √ √
Advanced matchmaking aspects
Inherently uncertain matching results sets (matching results can not be guaranteed, ...) √
performing and evaluating service calls, handling service invocation errors √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √
Inquiring for dynamic information, leveraging of that information during the matchmaking (request for price quote) √ √ √ √ √ √ √
Retrieved from "http://www.sws-challenge.org/wiki/index.php?title=Scenario:_Shipment_Discovery_v2&oldid=3397"
Personal tools