SWSL cost model (draft 0.01)

As part of the Semantic Web Services Language effort, I've volunteered
to produce ...

Proposal for a cost model for web services:

The goal here is to come up with a set of dimensions into which
virtually every cost mechanism can be represented.  A _cost mechanism_ 
is exemplified by something like this hypothetical offer from a movie
theater: 

    Special offer: Senior citizens can pay $5 a month and get to see
    10 movies a month for just $1 each.

That is, a cost mechanism for a given service (webbish or not) enables
one to compute the cost of a user's requests for the service.  (I
would rather not use the word "model" here; _we_ are modeling, but the
cost mechanism is generating prices.  If any economists are listening,
they might give us their feedback on whether this should be called a
"cost mechanism" or a "price mechanism.")

Here are my proposed dimensions for capturing cost mechanisms:

   1. Population who are eligible.  In the example, it's "senior
      citizens." 

   2. Periodic payment ("retainer"?) required to keep the mechanism in
      place.  In the example: $5/month.

   3. A function (the "marginal-cost function") that determines the
      price of a request as a function of the new request and the
      previous request history.  The previous request history is
      represented by two data: the total amount paid by the customer
      to date, and the set of all requests made to date under the
      control of this mechanism.

      In the example: 
        (lambda (movie-showing cum-pay prev-requests)
           ;; movie-showing and  cum-pay are irrelevant in this example
	   (if (cardinality {r | r in prev-requests 
				 & (date r) falls-in this-month}
	        =< 9)
             then $1
	     else (revert standard-cost-mechanism)))

The 'revert' notation enables the mechanism to announce that it can't
provide a price and state the mechanism that now applies.  It's sort
of like raising an exception.  The alternative would be to include the
entire standard marginal-cost function, which would require keeping
two copies of the standard cost mechanism.

Other examples:  

1 For $5 a month Boiler Room Brokerage will notify you
  whenever a stock is about to increase in price by at least 50%.
  Because this is a "push" service, there aren't any requests, so the
  marginal-cost function is irrelevant

    Population eligible: Everyone
    Periodic payment: $5/month
    Marginal-cost: (lambda (_ _ _) $0) or just omit.

I use "_" for ignored arguments.


2 Photocopying: A request in this case is a tuple
    <document, number of copies, special-features>.  (Special features
    include two-sided copying, color copying, binding, ....)

    Population eligible: Everyone
    Periodic payment: $0
    Marginal cost:
      (lambda (<doc, num, feats> _ _)
         (let n = (num-pages doc)
	    (if (feature feats :color)
	       then ...
	       else (if n*num < 10 then n*num*$.25
		     else if n*num < 100 
			   then $2.50 + (n*num - 10) *$.15
		     else $16 + (n*num - 100)*$.10))
	    + (if (feature feats :binding)
	         $1*(ceiling n/150))))

If this dosn't sound webbish enough, change it to a printing service,
where you send them the document as a .pdf file and they mail you a
stack of physical documents back.

   The "progressive" nature of the photocopying costs reminds me of
   progressive taxes.  The IRS can be considered a web service, or at
   least soon will be.  The eligible population is "adults with
   incomes > ..."; "eligible" is a euphemism, of course.  The request
   is for the government to go on existing and providing services for
   another year.  The cost is.... check the tax codes for the exact
   cost mechanism.

3 The ACM Digital Library: A request is a specification of an article
  published in an ACM periodical.  If successful, ACM will reply with a
  pdf version of the article.

    Population eligible: ACM members
    Periodic payment: $100/yr (I'm making the numbers up.)
    Marginal cost: 0

4 Amazon.com or other online retailer.  Here it gets interesting.  The
  protocol for dealing with an online retailer is a multi-stage
  procedure with state.  Cost mechanisms can be associated with steps
  in the protocol.  The interesting step is when the customer has
  stopped shopping, identified payment method, and specified the
  shipping details.  At that point, the request "Finish" creates two
  obligations: the retailer must send the customer the stuff described
  in the shopping cart, and the customer must pay the retailer the
  amount shown on the screen.

  Population eligible: Anyone who has gotten to this point in the
     protocol, with P = (total goods price + shipping costs) now known to the
     customer, and S = contents of shopping cart.
  Periodic payment: 0
  Marginal cost: (lambda (r _ _)
                    (if (r = "Finish")
                       then P else error))


Remarks:

It would be easy to factor the eligible population out, so that a
"Cost offer" would be a pair <population, cost mechanism>.

Insurance companies raise some interesting issues, what with
deductibles and all.  But I don't think deductibles are part of a cost
mechanism.  They might be if you were requesting the right to crash
into someone's car, in which case the payment would be $100 if you had
a $100 deductible.  But that's not the right way to think about it,
obviously.  When you buy an insurance policy, you're buying something
with a "mechanism" like a cost mechanism, except it specifies how much
of the damage (or whatever) the company will pay for.

Late-payment fees don't show up here either.  Once the obligation to
pay is created, there should be a separate model of how the payment is
carried out.  In the case of the on-line retailer, by giving a
credit-card number you've identified how the payment will be made.  In
other cases you might have to spell out late fees and other penalties
or rewards for paying slowly or fast.  

Credit-card companies are a difficult case.  

  Requests normally come via merchant, but by giving the merchant your
  credit-card info you are authorizing the merchant to make a request
  in your name for a transfer of $X to the merchant.

  Here we have a range of cost mechanisms.
  The eligible population is holders of this credit-card.

  but after that, things get murky.  Someone who never carries a
  balance is making use of the following simple cost mechanism:

  Periodic payment: $Y/yr
  Marginal cost: 
      (lambda (<loan $X> _ _)
         $X)

However, no one sends X to the credit-card company as soon as
possible after charging an item.  Instead, everyone pays between the
time they get a bill and the deadline.  Perhaps this can all be shoved
off my desk and onto the desk of whoever develops the "payment model."

-- 
                                             -- Drew McDermott

Received on Wednesday, 6 August 2003 17:36:47 UTC