Scenario: Logistics Management

Scope

In order to provide a fully featured test for semantic Web services, a structured knowledge-intensive description of a real domain is necessary. The logistic operator domain has all the features to attain a complete testing for semantic Web services:

• well defined terminology;
• well defined processes;
• complex normative;
• different points of views between the service provider and the requester.

This realistic description has been realized within the Networked Peers for Business (NeP4B) project through (i) the analysis of several real-world logistic operator prices and service offer lists, (ii) several phone and face to face interviews with logistic operators and client companies and (iii) the analysis of the normative that regulates the logistic operator activities.

Technical Scope: Discovery Aspects Covered By The Logistic Operator Scenario

This scenario focuses primarily on two aspects concerning the service discovery process, namely the problem of considering heterogeneity between the provider and the requester perspectives and the problem of ranking discovered WSs on the basis of a set of soft contraints. Both aspects are detailed below.

Bridging the Gap Between Providers and Users Perspectives

In this scenario, providers and customers use different terminologies, because they have different points of view. In fact a Logistic Operator uses a terminology that a client company may not know or understand. For example, on the one side a Logistic Operator states that it provides a transport service through its internal fleet, which is made up of several trucks, each one characterized by specific features. It does not state anything about the goods that it is allowed to transport because this list can be very long and difficult to write, and furthermore can be derived by from the characteristics of the operator's truck fleet. On the other side, a Client Company wants to move a specific good from one location to another, no matter which truck can do that.

Developers that create solutions for this domain should not force one party (e.g. customers) to understand and use the terminology of the other party (e.g. Logistic Operators). Instead, the application should allow a user to use his/her favorite terminology and manages terminology alignments internally. This is particularly desirable, if the rules that allow to link a term of one terminology to a term (or structure of terms) of another terminology are very complex. Indeed, in the logistic domain, such virtual "links" between terminologies must take into consideration complex legal regulations, which a customer may not know and does not want to deal with. With respect to not forcing one party to understand the terminology of the other party, please note the section on mandatory requirements for solutions.

Soft Constraint Based Discovery and Service Ranking

In cases where several SWSs meet some basic requirements specified by a requester, the requester needs to be supported in choosing which of those better fulfills a set of desiderata. This selection can be automatic, e.g. automatically proceeding to invoke the best service (best according to a set of chosen criteria), or left to the discretion of a human requester. The basic requirements that a requester wants to be fulfilled by a WS can be considered hard constraints of a goal, while the desiderata express the preferences of the requester; such preferences can be considered soft constraints that need to be taken into account to rank those WSs satisfying the hard constraints.

Such soft constraints need to be expressed in the requests and matched against the given descirptions of WSs. The problem of soft constraints-based discovery is related to the problem of representing and evaluating so called non functional properties (NFPs) of WSs. In fact, NFPs have often been exploited to refine the discovery process and rank the retrieved WSs. We prefer the terms soft and hard constraints over functional and non functional properties since it is difficult to define the difference between functional and non functional properties objectively.

Soft constraints may require quite sophisticated descriptions, possibly including a full set of constraint operators, such as "≤","≥" and range. Moreover, different soft constraints may have to be expressed in the same request. With respect to soft constraints such combinations of constraint expressions present some peculiarities for the matching process. In fact, the problem is often not that much that of discovering which services match or do not match the hard constraints, but which service fulfills the set of given soft constraints best (none of them mandatorily required). To evaluate the overall matching degree, methods to express priorities among soft constraints are needed. Soft constraints may concern both qualitative and quantitative properties of WSs but here quantitative ones play often a major role.

Finally some of these constraints may refer to properties of WSs whose actual value can be known only at runtime (e.g. bandwidth availability). However, even in cases where precise values needed for the evaluation of soft constraints are not known at discovery time, providers expecting such requests may want to publish at least some information about the expected values, e.g. that the bandwidth is guaranteed to be in a specific range, even if the precise value can not be statically determined.

Description

In this scenario there are two different actors:

• A Logistic Operator provides logistic support to third parties, which can be freight transports or storage into warehouses.
• Client Companies need a Logistic Operator for their transportations, in order to fulfill a single or a continuous need, i.e. an organizational emergency or the outsourcing of the logistic coordination.

Freight transport and warehousing regard different kinds of goods. Beside the so-called ordinary goods, there are:

• perishable goods, which can be fresh, frozen or deep-frozen and need particular temperatures that must be maintained for all the transport duration;
• dangerous goods, which need particular planning for the freights and particular treatments;
• cumbersome goods, which are characterized by big dimensions and weights and therefore their transport is regularized by the local rules of the road (exceptional transport).

In order to transport goods, a Logistic Operator must have a fleet (i.e. a set of vehicles) and/or a logistic platform (i.e. a set of warehouses) in different locations. Each truck can have some specific features, which can comply with a particular normative (see the subsections below).

If the delivery date of an order is far away from the pickup date while the pickup and delivery locations are close, then the carrier needs a warehouse where the goods can be temporarily stored. The warehouse has to be located in the same city of either pickup or delivery location stated in the order description.

Let us define the following values, which are used by carriers to establish when a warehouse is needed:

• KM = distance between the delivery location and the pickup location
• HOURS = number of hours between the delivery and the pickup
• MGMT = number of hours used by the carrier to manage the order (load/unload of the goods)
• SPEED = average speed of the truck (in km/h)

Then, the following mathematical expression are used:

• If (KM / SPEED) + MGMT < HOURS then the carrier is able to delivery the goods in time.
• If HOURS - ((KM / SPEED) + MGMT) > 24 then a warehouse is needed.

A.T.P.

The Accord Transport Perishable (A.T.P.) normative enforces specific rules for the transport of perishable goods at monitored temperatures and describes several classes of trucks with their temperature range. It is the result of an European accord signed 1970 by several countries.

The A.T.P. normative defines a set of vehicle classes for each temperature interval:

• The insulated vehicles are vehicles of which the body is built with insulating material. They are classified as:
  • class "IN" = normally insulated vehicle,
  • class "IR" = heavily insulated vehicle.
• The refrigerated vehicles are vehicles which, using a source of cold (such as natural ice, eutectic plates, dry ice, liquefied gases, etc.) other than a mechanical or "absorption" unit, are capable, with a mean outside temperature of + 30 °C, of lowering the temperature inside the empty body and thereafter maintaining it with the aid of appropriate refrigerants and fittings. They are classified with respect to the lowest internal temperature that they are able to maintain (so that a vehicle belonging to a specific category is allowed to transport any freight that requires a temperature that satisfies the constraint associated to that category):
  • classes "RNA" and "RRA" --> internal temperature greater than or equal to +7 °C
  • class "RRB" --> internal temperature greater than or equal to -10 °C
  • class "RRC" --> internal temperature greater than or equal to -20 °C
  • class "RRD" --> internal temperature greater than or equal to 0 °C
• The fridge vehicles (a.k.a. mechanically refrigerated vehicles) are insulated vehicles fitted with its own refrigerating appliance (i.e. a stand-alone fridge), which is capable, with a mean outside temperature of + 30 °C, of lowering the temperature inside the empty body and thereafter maintaining it continuously. They are classified with respect to the range of temperatures that can be chosen as the internal temperature. For the first three classes (i.e. A, B and C) the vehicle can set any desired fixed internal temperature, but only within the specified limits; for the others (i.e. D, E and F) the vehicle cannot set a particular fixed temperature, but it ensures that it will be a practically constant value.
  • classes "FNA" and "FRA" --> internal temperature between +12 °C and 0 °C (inclusive)
  • classes "FNB" and "FRB" --> internal temperature between +12 °C and -10 °C (inclusive)
  • classes "FNC" and "FRC" --> internal temperature between +12 °C and -20 °C (inclusive)
  • classes "FND" and "FRD" --> internal temperature greater than or equal to 0 °C
  • classes "FNE" and "FRE" --> internal temperature greater than or equal to -10 °C
  • classes "FNF" and "FRF" --> internal temperature greater than or equal to -20 °C
• The heated (or radiator) vehicles are insulated fitted with a heat-producing appliance which is capable of raising the temperature inside the empty body to, and thereafter maintaining it for not less than 12 hours without renewal of supply at, a practically constant value of not less than + 12 °C when the mean outside temperature of the body is that indicated below for the two types:
  • classes "CNA" and "CRA" --> for an average external temperature equal to -10 °C
  • class "CRB" --> for an average external temperature equal to -20 °C

In addition, the A.T.P. normative enumerates those substances that must be transported at specified temperatures. For fresh foodstuffs see the first table below, while for frozen or deep-frozen foodstuffs, see the second table. Generally, a vehicle qualified to transport perishable goods as listed in the following tables is not used to transport non-perishable goods (not listed in those tables). With respect to this scenario it means that it must not be used.

Temperature intervals to observe during the transport of fresh foodstuffs

Substance	Temperature
Guts	[ -1°C , +3°C ]
Butter	[ +1°C , +6°C ]
Game	[ -1°C , +3°C ]
Milk in cistern (crude milk or pasteurized milk) for immediate consumption	[ +0°C , +4°C ]
Industrial milk	+8°C
Milk derivatives (yoghurt, kefir, cream and cheese)	[ +0°C , +4°C ]
Products based on meat	+6 °C
Meat (excluding guts)	[ -1°C , +7°C ]
Poultry and rabbit	[ -1°C , +4°C ]
Fresh products from fishing (to be transported always along with ice)	[ +0°C , +4°C ]
Mollusc like clam, oyster, cuttlefish	+6°C

Temperature intervals to observe during the transport of frozen or deep-frozen foodstuffs

Substance	Temperature
Ice cream	[ -15°C , -12 °C ]
Frozen fish, frozen products based on fish, frozen mollusk, frozen crustacean, and any deep-frozen foodstuff	[ -18°C , -15°C ]
Any frozen foodstuff, excluding butter	-12°C
Butter or other fatty substances	[ -10 °C , -7°C ]
Guts, eggs without eggshell, poultry and game	[ -10 °C , -7°C ]
Other foodstuffs	[ -18 °C , -15°C ]

A.D.R.

The A.D.R. normative (Accord européen relatif au transport international des marchandises Dangereuses par Route) groups the dangerous materials into classes (see table below) and specifies the features that a vehicle must have in order to be able to carry that class of materials.

The classes of dangerous goods according to A.D.R.

Class identifier	Goods
Class 1	Explosive substances and articles
Class 2	Gases
Class 3	Flammable liquids
Class 4.1	Flammable solids, self-reactive substances and solid desensitized explosives
Class 4.2	Substances liable to spontaneous combustion
Class 4.3	Substances which, in contact with water, emit flammable gases
Class 5.1	Oxidizing substances
Class 5.2	Organic peroxides
Class 6.1	Toxic substances
Class 6.2	Infectious substances
Class 7	Radioactive material
Class 8	Corrosive substances
Class 9	Miscellaneous dangerous substances and articles

Restrictions and Simplifications

The transportation of goods that require cooling or otherwise specially featured trucks (e.g., according to A.D.R.) is likely more expensive than the transportation of goods that are not subject of legal limitations. For the time being, we abstract from this issue and in the goal and service descriptions provided below do not consider prices on the level of specific trucks, but only on the level of logistics providers, regardless of which truck a given logistics provider has to use to provide the requested transportation.

Furthermore, this scenario does not require to be able to deal with all kinds of goods. Those that are necessary to solve the scenario are the ones involved in the goal descriptions, that is:

• books;
• roman candles (ADR class 1);
• cuttlefishes;
• clothes;
• ice cream.

Moreover, the scenario uses the formulas defined in the chapter titled "Description", which assumes the knowledge of the spacial distance between several locations. To solve the scenario the following distances have to be taken into account:

Distances between the locations involved in this scenario

From	To	Distance (in Km)
Salzufer 13, 10587, Berlin (Germany)	Alexanderplatz 7, 10178, Berlin (Germany)	20
Avinguda Diagonal 338, 08013, Barcelona (Spain)	Calle del General Ricardos 176, 28025, Madrid (Spain)	620
Rue de la Cité 5, 75004, Paris (France)	Boulevard Carnot 68, 06400, Cannes (France)	905
Viale Matteotti 48, 50132, Firenze (Italy)	Via Lucchese 57, 56123, Pisa (Italy)	100
Via Fucini 2, 20133, Milano (Italy)	Rue de la Cité 5, 75004, Paris (France)	850

Evaluation Procedure

Basic Evaluation

The scenario consists of various goal definitions (see below). For each goal we provide the list of WSs that match it. A correct solution for a given goal must retrieve the listed WSs and, in case, in the exact order as specified, nothing else.

For some goals, multiple different WS lists or one list with multiple different orderings are provided that are equally acceptable. In those cases, it is sufficient to retrieve one out of the acceptable WS lists in the correct ordering.

Participating solutions need to be demonstrated at a SWS-Challenge evaluation workshop. A solution passes a given goal, if the workshop verifies that the solution outputs the correct set (or, if applicable, sequence) of WSs for the given goal and additionally meets the general requirements on solutions listed below.

Mandatory Requirements on Scenario Solutions

This scenario is, among other things, intended to test the ability of a solution to mediate between different perspectives of requesters and providers of services. Most basically, a provider states the desire to transport a specific good (e.g. milk) whereas a requester states the ability to provide certain transports according to ADR and ATP regulations. The discovery solution needs to mediate these perspectives and determine whether the provider is capable of transporting milk by taking into consideration the applying ADR and ATP regulations and comparing them with the provided specifications from the logicistic operator. The scenario does not presuppose how this is done. However, it requires that the imaginary requesters do not have to deal with ADR and ATP regulations and that the imaginary providers do not need to deal with specific goods, most explicitly they must not need to list all goods they are able to transport. I.e., the formal request descriptions will have to state that, for instance, milk is transported but will not explicitly state that milk requires transport according to a specific ATP class. The formal offer descriptions will have to state that transport of goods falling under particular ATP classes is provided, but will not explicitly state that, for instance, milk can be transported.

The information whether the good requested to be transported falls under the ATP/ADR classes that a provider is capable of transporting needs to be provided by some third artifact apart from the offer and request descriptions. This may be a rule knowledge base or some other kind of ontology. It is also fine to provide as part of a solution a web service which, given a good computes the required ADR and ATP classes of suitable transport vehicles, or to find some other solution for the problem.

The only mandatory requirement is that a requester is able to state service requests without knowing of ADR and ATP and that a provider is allowed to provide offer descriptions that are expressed only in terms of ADR and ATP but not in terms of concrete goods.

Evaluation Process for Requirements on Solutions

• As previously, we will perform code reviews at the workshops to verify that a solution actually solves the problem scenario by reasoning over the formlized goal and WS specifications and not by hard-wiring the correct solution. The workshop will decide by consensus whether a solution is acceptable.
• The evaluation workshop will also decide by consensus whether the restriction with respect to mandatory requirements on solutions are met by a solution. Please consider also the examples below.
• We may ask participants to implement surprise changes during the demonstration of their solution. Solutions that successfully implement the changes will get additional corresponding certification. Such changes could involve
  • to remove one of the WS descriptions from the system (a provider goes offline)
  • to add a new WS description to the system (a new provider appears)
  • to change a property of a provider (a provider changes his terms)
  • to change a property of a goal or execute a new goal (the requester spontaneously submits a different request)
  • to change some of the ATP or ADR rules (regulatory change).

Evaluation Examples

Illustration of basic evaluation procedure

As specified below, a correct solution for Goal A3 must return the following set of services: WS2, WS5, WS6. Goal A3 does not specify any preference, therefore, a successful solution can return the services belonging to the set in any order. On the other hand, Goal C1, for instance, specifies some preferences (about payment method and price), so a successful solution has to return the following ordered list: WS2, WS5, WS6. A solution succeeds if and only if it returns WS2, WS5, WS6 - in this sequence. Any other solution (like the following ones) is wrong:

• WS2, WS3, WS5, WS6 --> (WS3 excess)
• WS2, WS6, WS5 --> (WS5 and WS6 swapped)
• WS2, WS5 --> (WS6 missing)

Example of an incorrect goal formalization

The following set of triples is an inacceptable goal specification, because the "hasGood" parameter includes a hint to an ATP class, whereas the scenario requires that requesters, i.e. goal specifications, do not need to deal with ATP classes:

GoalA3 ofType Goal .
GoalA3 hasPickupDateTime "08/09/2008 10:00" .
GoalA3 hasPickupLocation Paris .
GoalA3 hasDeliveryDateTime "09/09/2008 13:00" .
GoalA3 hasDeliveryLocation Cannes .
GoalA3 hasGood cuttlefishesAtpPlusSix .

Imaginary Scenario Service Offers

This section introduces a set of services that represent the knowledge base which the discovery process will use to identify the best services matching a given goal.

A service describes what a logistic operator offers. For this reason the service is characterized by a name, which is the name of the logistic operator offering the service, and a URL corresponding to the endpoint that can be used to invoke the service. In addition, a logistic operator operates in a specified geographic area (CoveredGeographicalAreas) and picks up and delivers package only during the specified operating hours (DailyOperatingHours). As the name suggests, these operating hours are daily (including Sundays and other holidays). To manage each order, a logistic operator has to deal with an extra effort which includes for example the time spent to load/unload the packages or to coordinate the staff. The average effort is calculated in number of hours (AverageHoursForOrderManagement) and has to be considered as additional to the time spent by a truck to fulfill an order.

Every logistic operator adopts a pricing model. The price of a shipment depends on specific features of the order (e.g., type and weight of goods). However, the price always includes a "BasePrice" that is the minimum amount of money that users must pay for each freight indepentently from specific features of the order. Logistic operators indicate accepted "PaymentMethods". In the logistic domain the common payment methods are: (i) "carriagePaid" (the seller pays the freight for the delivery); (ii) "carriageForward" (the recipient pays the freight for the delivery). Payments are required to be made within a deadline specified by the logistic operator ("PaymentDeadline"). Different "Insurance" facilities are offered to the users: (i) "refundForLoss" (protection against loss); (ii) "refundForDamage" (protection against damage). User can choose one or both the insurance facilities. Logistic operator may choose to offer different BasePrice, PaymentMethod, PaymentDeadline and Insurance settings depending on the frequency of the collaboration with the user ("NumberOfShipments").

Every logistic operator owns a set of vehicles (Fleet) used to ship goods. The description of a service does not provide the full list of every single vehicle owned by the logistic operator, rather it describes the types of vehicles it owns. For example, the description does not says that the logistic operator named XYZ owns three vans and five refrigerator trucks, instead it just states that the company has both vans and refrigerator trucks. We assume that for every type of vehicle the service description reports its average speed (AverageSpeed) as well as, optionally, the classes of A.T.P. and A.D.R. regulations for which it is qualified (SupportedAtpClass and SupportedAdrClass). Unless explicitly stated, a vehicle does not support any A.T.P. or A.D.R. class.

Finally, a logistic operator may have several warehouses (LogisticPlatform) located in different cities (Address) and complying with some regulations (SupportedAtpClasses and SupportedAdrClasses).

Service WS1:

• Name: Liteworld
• URL: http://liteworld.example.com
• CoveredGeographicalAreas: Africa, Europe, North America, Asia
• DailyOperatingHours
  • StartHour: 06:00
  • EndHour: 19:00
• AverageHoursForOrderManagement: 4
• PriceList
  • Base Price: 100 EURO
  • Price/Kg: 15 EURO
  • Price/Km: 0.50 EURO
• AcceptedPaymentMethod: carriageForward
• PaymentDeadline:
  • 30 days (if requested shipments ≤ 5)
  • 60 days (if requested shipments > 5)
• Insurance: refundForDamage and refundForLoss
• Logistic Platform:
  • Warehouse #1
    • Address: Rue La Fayette 48, 75009, Paris (France)
    • SupportedAtpClasses: FNC
  • Warehouse #2
    • Address: Park Ave 11, 10016, New York (USA)
• Fleet:
  • Dump Trucks
    • AverageSpeed: 45 km/h
    • Qualifications: None
  • Ballast Tractors
    • AverageSpeed: 55 km/h
    • Qualifications:
      • SupportedAdrClass: 1
  • Refrigerator Trucks
    • AverageSpeed: 37.5 km/h
    • Qualifications:
      • SupportedAtpClass: FNC
  • Big Refrigerator Trucks
    • AverageSpeed: 30 km/h
    • Qualifications:
      • SupportedAtpClass: FNA

Service WS2:

• Name: Hello
• URL: http://hello.example.com
• CoveredGeographicalAreas: Italy, France, Germany, Asia
• DailyOperatingHours
  • StartHour: 07:30
  • EndHour: 20:30
  • AverageHoursForOrderManagement: 6
• PriceList
  • Base Price: 200 EURO
  • Price/Kg: 25 EURO
• AcceptedPaymentMethod: carriageForward, carriagePaid
• PaymentDeadline: 60 days
• Insurance: refundForLoss
• Fleet:
  • Trailer Trucks
    • AverageSpeed: 32.5 km/h
    • Qualifications: None
  • Articulated Lorries
    • AverageSpeed: 35 km/h
    • Qualifications: None
  • Refrigerator Trucks
    • AverageSpeed: 42.5 km/h
    • Qualifications:
      • SupportedAtpClass: FNC

Service WS3:

• Name: Fresh 'n' fast
• URL: http://fandf.example.com
• CoveredGeographicalAreas: Spain, France, Italy, Germany
• DailyOperatingHours
  • StartHour: 04:00
  • EndHour: 19:00
• AverageHoursForOrderManagement: 8
• PriceList
  • Base Price: 120 EURO
  • Price/Kg: 15 EURO
  • Price/Km: 0.20 EURO
• AcceptedPaymentMethod: carriagePaid
• PaymentDeadline: 60 days
• Insurance: refundForLoss
• Logistic Platform:
  • Warehouse #1
    • Address: Avenue Francis Tonner 13, Cannes (France)
    • SupportedAtpClasses: FNB
  • Warehouse #2
    • Address: Rue de Grands Moulins 16, Paris (France)
    • SupportedAtpClasses: FNC, RRC
• Fleet:
  • Pickup Trucks
    • AverageSpeed: 47.5 km/h
    • Qualifications:
      • SupportedAtpClass: RRA
  • Refrigerator Trucks
    • AverageSpeed: 42 km/h
    • Qualifications:
      • SupportedAtpClass: RNA
  • Big Trucks
    • AverageSpeed: 35 km/h
    • Qualifications:
      • SupportedAdrClass: 1

Service WS4:

• Name: Safe transport
• URL: http://safe.example.com
• CoveredGeographicalAreas: Spain, Italy, Germany
• DailyOperatingHours
  • StartHour: 07:30
  • EndHour: 17:30
• AverageHoursForOrderManagement: 4
• PriceList
  • Base Price: 170 EURO (if requested shipment ≤ 5)
  • Base Price: 130 EURO (if requested shipment > 5)
  • Price/Kg: 15 EURO
• AcceptedPaymentMethod: carriageForward, carriagePaid
• PaymentDeadline: 45 days
• Insurance: refundForDamage
• Logistic Platform:
  • Warehouse #1
    • Address: Rue Notre Dame 8, Cannes (France)
    • SupportedAtpClasses: FNC
  • Warehouse #2
    • Address: Corso Garibaldi 58, Firenze (Italy)
    • SupportedAtpClasses: FNC
  • Warehouse #3
    • Address: Calle de Vallandes 10, Madrid (Spain)
    • SupportedAdrClasses: 4.1, 4.2
  • Warehouse #4
    • Address: Mainzer Landstrasse 18, Frankfurt (Germany)
    • SupportedAdrClasses: 1, 2, 3, 4, 5
  • Warehouse #4
    • Address: Boulevard Richard Lenoir 58, Paris (France)
    • SupportedAtpClasses: FNB, RRD
• Fleet:
  • Pickup Trucks
    • AverageSpeed: 55 km/h
    • Qualifications:
      • SupportedAtpClass: RRA
      • SupportedAdrClass: 4, 5
  • Refrigerator Trucks
    • AverageSpeed: 40 km/h
    • Qualifications:
      • SupportedAtpClass: FNC
  • Dump Trucks
    • AverageSpeed: 40 km/h
    • Qualifications:
      • SupportedAdrClass: 1

Service WS5:

• Name: All@Home
• URL: http://all-at-home.example.com
• CoveredGeographicalAreas: Europe
• DailyOperatingHours
  • StartHour: 08:00
  • EndHour: 22:00
• AverageHoursForOrderManagement: 2
• PriceList
  • Base Price: 150 EURO
  • Price/Kg: 20 EURO
• AcceptedPaymentMethod: carriageForward
• PaymentDeadline: 45 days
• Insurance: refundForLoss
• Fleet:
  • Vans
    • AverageSpeed: 45 km/h
    • Qualifications: None
  • Semi-trailer Trucks
    • AverageSpeed: 55 km/h
    • Qualifications:
      • SupportedAdrClass: 1, 2, 3, 4, 5
  • Refrigerator Vans
    • AverageSpeed: 37 km/h
    • Qualifications:
      • SupportedAtpClass: FNC

Service WS6:

• Name: Fast4U
• URL: http://fast4u.example.com
• CoveredGeographicalAreas: France, Italy, Germany
• DailyOperatingHours
  • StartHour: 04:00
  • EndHour: 16:00
• AverageHoursForOrderManagement: 7
• PriceList
  • Base Price: 150 EURO
  • Price/Kg: 15 EURO
• AcceptedPaymentMethod: carriagePaid
• PaymentDeadline: 30 days
• Insurance: refundForLoss
• Logistic Platform
  • Warehouse #1
    • Address: Via Manzoni 7, Firenze (Italy)
• Fleet
  • Vans
    • AverageSpeed: 50 km/h
    • Qualifications: None
  • Refrigerator Trucks
    • AverageSpeed: 40 km/h
    • Qualifications:
      • SupportedAtpClass: FNA
  • Dump Trucks
    • AverageSpeed: 37 km/h
    • Qualifications:
      • SupportedAdrClass: 1, 7, 8, 9

Service WS7:

• Name: GTL
• URL: http://gtl.example.com
• CoveredGeographicalAreas: France, Italy
• DailyOperatingHours
  • StartHour: 04:00
  • EndHour: 16:00
• AverageHoursForOrderManagement: 4 hours
• PriceList
  • Base Price: 140 EURO
  • Price/Kg: 10 EURO
  • Price/Km: 0.20 EURO
• AcceptedPaymentMethod: carriageForward
• PaymentDeadline: 30 days
• Insurance: refundForDamage
• Logistic Platform
  • Warehouse #1
    • Address: Rue de Romainville 38, Paris (France)
    • SupportedAtpClasses: FNF
  • Warehouse #2
    • Address: Via Dante 24, Firenze (Italy)
    • SupportedAtpClasses: FNB
• Fleet
  • Pickup Trucks
    • AverageSpeed: 55 km/h
    • Qualifications: None
  • Refrigetor Vans
    • AverageSpeed: 37 km/h
    • Qualifications:
      • SupportedAtpClass: FNB
  • Refrigetor Vans
    • AverageSpeed: 37 km/h
    • Qualifications:
      • SupportedAtpClass: RRC

Service Requests:

The following service requests are classified by the complexity of service discovery. A 0-5 grading scale is used to describe difficulty of the goal (5 is the maximum level of difficulty) both for Soft Constraints and for Hard Constraints (HC).

A service offer matches a request if all the following conditions on hard constraints are satisfied:

• pickup and delivery time are within the service's operating hours
• pickup and delivery locations are within the geographic areas covered by the service
• the service's fleet has at least one truck that:
  • is able to transport the goods with respect to A.T.P. and A.D.R. requirements, and
  • has an average speed that allows the carrier to delivery the freight in time (see the formula shown in the chapter describing the scenario)
• in case a warehouse is needed (see the formula shown in the chapter describing the scenario), the service has at least one warehouse that:
  • is located in the same city of either the pickup or the delivery location, and
  • is able to store the goods with respect to A.T.P. and A.D.R. requirements

Soft constraints are exploited to establish preferences among the services that match hard constraints used in the requests, resulting in an ordered list of services; the preference orders depend on:

• the number of soft constraints solved and on the evaluation of the matching between the requested;
• the relationship between the requested values in the constraints and the values covered by the services;

Specific criteria for the evaluation of each soft constraint, and of a set of soft constraints are specified in the goal descriptions to test the capability of evaluating soft constraints expressed with different expressions and combined according to different principles.

Goal A1 (Standard single order)

Tested Capabilities

[HC: 1/5] This goal represents a single order that requires a standard transportation.

[SC: 0/5] This goal does not test soft constraints-based discovery.

Description:

Pickup date&time:    24/08/2008 11:00
Pickup location:     Salzufer 13, 10587, Berlin (Germany)
Delivery date&time:  24/08/2008 17:00
Delivery location:   Alexanderplatz 7, 10178, Berlin (Germany)
Good:                books

Matching Services:

• WS1: yes
• WS2: yes
• WS3: no (none of its trucks can delivery goods in time)
• WS4: yes
• WS5: yes
• WS6: no (the working time ends before the delivery time and its trucks are too slow)
• WS7: no (it does not transport goods in Germany)

Goal A2 (A.D.R. rules)

Tested Capabilities

[HC: 2/5] In addition to the features tested with the previous goal, this goal requires to consider the A.D.R. normative because the good needs a special truck.

[SC: 0/5] This goal does not test soft constraints-based discovery.

Description:

Pickup date&time:    03/09/2008 18:00
Pickup location:     Avinguda Diagonal 338, 08013, Barcelona (Spain)
Delivery date&time:  04/09/2008 09:30
Delivery location:   Calle del General Ricardos 176, 28025, Madrid (Spain)
Good:                Roman candles (70 mm of inner diameter without flash composition)

Matching Services:

• WS1: yes
• WS2: no (it does not cover Spain and none of its trucks is qualified for ADR transportations)
• WS3: yes
• WS4: no (it cannot pickup the goods because it finishes to work too early)
• WS5: yes
• WS6: no (the working time ends before the delivery time and its trucks are too slow)
• WS7: no (none of its trucks is qualified for ADR transportations)

Goal A3 (ATP truck):

Tested Capabilities

[HC: 3/5] To solve this goal is necessary to implement the A.T.P. rules, since the good involved is milk.

[SC: 0/5] This goal does not test soft constraints-based discovery.

Description:

Pickup date&time:    08/09/2008 10:00 (GMT+1)
Pickup location:     Rue de la Cité 5, 75004, Paris (France)
Delivery date&time:  before 09/09/2008 13:00 (GMT)
Delivery location:   Boulevard Carnot 68, 06400, Cannes (France)
Good:                cuttlefishes

Matching Services:

• WS1: no (trucks that could transport cuttlefishes are too slow)
• WS2: yes
• WS3: no (no truck can transport cuttlefishes)
• WS4: no (it does not cover France)
• WS5: yes
• WS6: yes
• WS7: no (trucks that could transport cuttlefish are too slow)

Goal B1 (A2 + Simple Soft Constraints):

Tested Capabilities

[HC: 2/5] In addition to the features tested with the previous goal, this goal requires to consider the A.D.R. normative because the good needs a special truck (same as Goal A2).

[SC: 1/5] This goal tests the capability to (partially) order the HCD-WSs (Hard Constraints-based Discovered WSs) on the basis of their satisfaction of soft constraints. On the basis of two soft constraints SC1 and SC2 a partial order on WSs consists of three possible classes:

• WSs satisfying (SC1 AND SC2)
• WSs satisfying (SC1 XOR SC2)
• WSs satisfying (NOT (SC1 OR SC2))

Preferences among soft constraints are not required.

Description:

Pickup date&time:    03/09/2008 18:00
Pickup location:     Avinguda Diagonal 338, 08013, Barcelona (Spain)
Delivery date&time:  04/09/2008 09:30
Delivery location:   Calle del General Ricardos 176, 28025, Madrid (Spain)
Good:                Roman candles (70 mm of inner diameter without flash composition)
Soft constraints:       I prefer WSs that provide the following properties
  SC1 - PaymentMethod:  carriageForward
  SC2 - Insurance:      RefundForDamage

Matching Services:

• WS1: yes
• WS2: no (it does not cover Spain and none of its trucks is qualified for ADR transportations)
• WS3: yes
• WS4: no (it cannot pickup the goods because it finishes to work too early)
• WS5: yes
• WS6: no (the working time ends before the delivery time and its trucks are too slow)
• WS7: no (none of its trucks is qualified for ADR transportations)

Sorted Matching Services:

• WS1
• WS5
• WS3

Goal C1 (A3 + Soft Contraints With Preferences):

Tested Capabilities

[HC: 3/5] To solve this goal is necessary to implement the A.T.P. rules, since the good involved is milk (same as A3).

[SC: 3/5] This goal tests the capability to order the HCD-WSs on the basis of their satisfaction of soft constraints. Preferences among soft constraints are introduced. Moreover a ranking principle is introduced in the sense that with respect to specific soft constraint a criterion of "better fulfillment" is introduced (on the base price).

Description:

Pickup date&time:    08/09/2008 10:00 (GMT+1)
Pickup location:     Rue de la Cité 5, 75004, Paris (France)
Delivery date&time:  before 09/09/2008 13:00 (GMT)
Delivery location:   Boulevard Carnot 68, 06400, Cannes (France)
Good:                cuttlefishes
Soft constraints:    I Prefer WSs that best fit the soft constraint on Payment method.
                     In the case of equal satisfaction degree, I prefer WSs whose
                     Base Price are closer to the value expressed in the soft constraint.
                     Based on the consideration that cheap prices occasionally do imply
                     lower service quality, I explicitly do not ask for the cheapest base price.  
  
  SC1 - PaymentMethod:	    carriageForward
  SC2 - Base Price:   close to 180 Euro

Matching Services:

• WS1: no (trucks that could transport cuttlefishes are too slow)
• WS2: yes
• WS3: no (no truck can transport cuttlefishes)
• WS4: no (it does not cover France)
• WS5: yes
• WS6: yes
• WS7: no (trucks that could transport cuttlefishes are too slow)

Sorted Matching Services:

• WS2
• WS5
• WS6

Goal D1 (warehouse):

Tested capabilities:

[HC: 4/5] This goal needs a warehouse where the goods can be temporarily stored, because the delivery date is far from the pickup date even if the locations are not so distant.

[SC: 3/5] This goal tests the capability to order the HCD-WSs on the basis of their satisfaction of soft constraints. A ranking principle is introduced in the sense that a criterion of "better fulfillment" is introduced for one specific soft constraint (on the base price). However, some WS conditionally offer different base prices, e.g., based on the number of shipments requested. Users do not necessarily know beforehand of such conditions since they do not possess complete knowledge how providers model prices. They are explicitly not supposed to provide information about the number of requested shipments. Instead, a scenario solution should provide some other solution to the problem, e.g., provide conditional output lists, or call back the user to inquire necessary information like the number of shipments. Generally, the solution must show how it takes into account that some values cannot be defined on the basis of the information provided by the requester.

Description:

Pickup date&time:    10/09/2008 08:30
Pickup location:     Viale Matteotti 48, 50132, Firenze (Italy)
Delivery date&time:  14/09/2008 12:30
Delivery location:   Via Lucchese 57, 56123, Pisa (Italy)
ShipmentFrequency:   Monthly
Good: clothes
Soft constraints:    I prefer WSs with a base price lower than 150 €.
                     The lower the base price, the better it is.

  Base Price:        ≤ 150 Euro

Matching Services:

• WS1: no (its warehouses are not in Italy)
• WS2: no (it owns no warehouses)
• WS3: no (its warehouses are not in Italy)
• WS4: yes
• WS5: no (it owns no warehouses)
• WS6: yes
• WS7: yes

Sorted Matching Services:

• WS4 (under condition requested shipments >5)
• WS7
• WS6
• WS4 (under condition requested shipments <= 5)

Goal E1 (ATP truck & ATP warehouse):

Tested capabilities:

[HC: 5/5] This goal is similar to the previous one - in the sense that it requires a warehouse - but it is more difficult because the involved goods need a fridge both on the truck and in the warehouse.

[SC: 4/5] This goal tests the capability to order the FCD-WSs (Functionally Discovered WSs) on the basis of their satisfaction of soft constraints. Both preferences among soft constraints and ranking are implicitly addressed, but furthermore there is a problem of ranking on the basis of a global evaluation of a set of soft constraints: the problem here consists in finding a way to provide not only a preference between different soft constraint, but a global method that allows to combine different soft constraints; this should account also for the case in which some WS does not publish any information about some of the properties involved in the soft constraint required.

For each single soft constraint the evaluation method is fixed. In particular, for two required values in conjunctive condition (AND), services fulfilling both conditions must be preferred to services fulfilling only one condition which in turn must be preferred over services fulfilling neither condition. However, different strategies can be used to put together the results into a global evaluation algorithm/function. We require a ranked list of WSs to be returned but a degree of freedom is left to participants to produce different results which are equally acceptable (i.e., the goal is on purpose underspecified).

For the HCD-WSs of this scenario, values of the properties involved in the list of soft constraints are set to provide a reasonable global sort. In fact, notice that:

• If requested shipments are >5 WS1 is clearly better then any service with respect to (i) price (the lowest) and (ii) insurance constraint (satisfies both requirements).
• Furthermore, WS1 is inside the constrained range of payment deadline, as is WS3, whereas WS7 is outside the range.
• WS3 is clearly better then WS7 w.r.t. price and payment deadline (WS7 is out of the range).

It is therefore reasonable to expect that

• if requested shipments are >5
  • WS1 should be preferred to WS3 and
  • WS3 should be preffered to WS7
• if requested shipments are <= 5
  • WS1 is still better than WS7 w.r.t. every property.
  • WS1 is better than WS3 w.r.t. price and insurance, but WS3 is better than WS1 w.r.t. the payment deadline. WS1 could arguably be considered better than WS3 because it meets more soft constraints, but a requester might consider the payment deadline to be more important. For this reason two different rankings of WSs are considered accceptable for this goal:

Description:

Pickup date&time:    11/09/2008 10:00 (GMT+1)
Pickup location:     Via Fucini 2, 20133, Milano (Italy)
Delivery date&time:  27/09/2008 14:30 (GMT+1)
Delivery location:   Rue de la Cité 5, 75004, Paris (France)
GoodType:            fruit ice cream
Soft constraints:    I prefer WSs that best fit the three soft constraints.
                     I would like to receive a list of WSs sorted on the basis of   
                     the average satisfaction degree on soft constraints.
  
  Price:             Base price ≤ 250 Euro (lower base price preferred)
  PaymentDeadline:   45 days ≤ PaymentDeadline ≤ 60 days
  Insurance:         refundForLoss and refundForDamage

Matching Services:

• WS1: yes
• WS2: no (it owns no warehouses)
• WS3: yes
• WS4: no (two warehouses are in France, but one is not in Paris and the other one does not comply with the required ATP class)
• WS5: no (it owns no warehouses)
• WS6: no (none of its warehouses is located at neither the pickup town or delivery town and none of its trucks can carry ice cream)
• WS7: yes

Sorted Matching Services:

• WS1 (regardless of the number of requested shipments)
• WS3
• WS7

or

• WS1 (under condition requested shipments >5)
• WS3
• WS1 (under condition requested shipments <= 5)
• WS7

Quick Links

• The Accord Transport Perishable (A.T.P.) normative
• The A.D.R. normative on Wikipedia

Main Contact

If you are interested in presenting a solution to this scenario or have any questions, please don't hesitate to contact Dario Cerizza about questions regarding the "Bridging the Gap Between Providers and Users Perspectives" aspect of this scenario, Matteo Palmonari on all questions regarding "Soft Constraint Based Discovery and Service Ranking" and Ulrich Küster with any general question.

Credits

This scenario was designed by CEFRIEL and University of Bicocca in cooperation with Friedrich-Schiller-University Jena.