- From: John Hall <john.hall@modelsys.com>
- Date: Fri, 10 Mar 2006 17:59:15 -0800
- To: Chris Welty <cawelty@frontiernet.net>
- Cc: RIF WG <public-rif-wg@w3.org>
- Message-id: <44122EF3.8090804@modelsys.com>
Hello Chris, My responses in-line, below, Regards, John Chris Welty wrote: > > > The new draft of this use case is much better, but there are still > parts in it that border on what I initially objected to. Again, I > think RIF is clearly about machine-processable rules. Of course if > people want to use it for other things, great, I won't stop them, but > these other things (like writing regulations or laws) shoudl not > influence the design of RIF. > > Most of the current version is OK, I think, except: > > "EU-Rent UK finds some problems in applying the rules. One is that > sometimes it has to give free upgrades to customers. It wants to have > one of the rules for insurance tax changed. > > For an individual rental, the tax on aggregated insurance is 1.5% of > the simple cost of the rental actually paid by the customer (not the > price of rental of the upgrade provided) > It provides this to AutoLaw, which will negotiate it with the > regulators and disseminate the outcome to EU-Rent and its other > customers. " The issue here is ambiguity. The rule says, "Insurance tax must be charged on rental at 1.5% of rental-simple-cost". Rental-simple-cost in EU-Rent agrees with the regulator's definition: "price charged for use of the car plus compulsory insurance, excluding extra charges such as additional, drivers, optional insurances, additional equipment." But in EU-Rent it has two specializations. * Rental-actual-simple-cost: "rental-simple-cost that is actually paid" * Rental-tariff-simple-cost: "rental-simple-cost that is quoted in the tariff for the car group used in the rental" (which is higher than the price paid if a free upgrade is provided) EU-Rent UK wants the rule disambiguated. But it provides its preferred version: "Insurance tax must be charged on rental at 1.5% of rental-actual-simple-cost", so that tax would be due on the price paid. Of course, the regulator might decide that it should be: "Insurance tax must be charged on rental at 1.5% of rental-tariff-simple-cost", so that if a free upgrade is given, tax would be due on the benefit provided. This can't be the only kind of circumstance where the tool behind a RIF client needs to request clarification of a received rule that is, for its local vocabulary, ambiguous. One reasonable way of resolving ambiguity is to propose a non-ambiguous alternative. Are you suggesting that the RIF should not support this capability? > > This is precisely what I would live to avoid. RIF is not a format for > exchanging legal language between people so that they can negotiate. > > Also: > > "It also has some existing insurance policies in place. They provide > third-party insurance as an explicit item, and EU-Rent UK cannot get > refunds on early termination. It asks corporate HQ for rules: > > Cost of third-party insurance will be built into the basic cost of > each rental, unless there is an alternative insurance already in place" > > > I do not see how this rule could be implemented in RIF, in particular > "will be built in". What is that supposed to mean? This is not a > machine processable rule. The issue here is about rules for building and using rental tariffs. EU-Rent HQ wants the cost of 3rd-party insurance to be included in tariff rates (the rates quoted for car groups and rental periods, e.g. 'one-day rate for mid-size', 'weekly rate for full-size). EU-Rent UK wants its current 3rd-party insurance, with distinct premiums for 3rd-party insurance, to run its course before applying the new rules. Rules that would be machine processable might (given a more formal syntax and a suitable vocabulary) look something like this: * If 3-P insurance does not exist then aggregate-insurance must exist and current-date must be or be later than effective-start-date of aggregate-insurance and current-date must be or be earlier than effective-end-date of aggregate-insurance * If current date is later than (effective-end-date of 3P-insurance - 15 working-days) and current-date is or is earlier than effective-end-date of 3P-insurance then aggregate-insurance must exist and effective-start-date of aggregate-insurance must be effective-end-date of 3P-insurance * If current-date is (effective-start-date of aggregate-insurance - 10 working days) then process "tariff update" must be activated with effective-start-date of tariff = effective-start-date of aggregate-insurance. Rules relevant to process "tariff-update": * If effective-start-date of tariff is earlier than effective-end-date of 3P-insurance then tariff-item (car-group, rental-period) <= base-rental-cost (car-group, rental-period) * If effective-start-date of tariff is or is later than effective-start-date of aggregate-insurance then tariff-item (car-group, rental-period) <= (base-rental-cost (car-group, rental-period) * (1 + aggregate-insurance-percentage (car-group, rental-period)) Rules relevant to process "rental quote": * Current-tariff is tariff with latest effective-start-date that is earlier than current-date. * If effective-start-date of current-tariff is earlier than effective-end-date of 3P-insurance then rental-simple-cost <= tariff-item (car-group, rental-period) of current-tariff + 3P-insurance-premium (car-group, rental-period) * If effective-start-date of current-tariff is or is earlier than effective-start-date of aggregate-insurance then rental-simple-cost <= tariff-item (car-group, rental-period) of current-tariff I'm sorry if I expressed the rule so informally that it looked as if it couldn't be automatically processed. I had hoped that people would get the idea without the tedious detail. The more machine-friendly version above probably requires RIF WG members to understand more about the detail of EU-Rent than they would ever wish to know. Or are you suggesting that effective date/times for rules should not be supported by the RIF? > > What do others think here? > > -Chris > >
Received on Saturday, 11 March 2006 02:02:11 UTC