- 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