text:
Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document, developed by the Rule Interchange Format (RIF) Working Group, specifies use cases and requirements for a format that allows rules to be translated between rule languages and thus transferred between rule systems.
The Phase 1 version of this document presents use cases and requirements for the RIF in general. The Phase 1 deliverables will provide an extensible base with which the use cases can be addressed, but it will not be until Phase 2 that most of these use cases are directly addressed by the Working Group.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
The Rule Interchange Format (RIF) Working Group has produced this First Public Working Draft and is interested in feedback. If there appear to be significant mistakes or omissions from these use cases, please let us know, bearing in mind that they need to be representative of a much larger set. Please send to firstname.lastname@example.com (public archive). If possible, please offer specific changes to the text which will address your concern.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Rule-languages and rule-based systems have played seminal roles in the history of computer science and the evolution of information technology. From expert systems to deductive databases, the theory and practice of automating inference based on symbolic representations has had a rich history and continues to be a key technology driver.
Due to the innovations made possible by the Internet, the World Wide Web, and, most recently, the Semantic Web, there is now even greater opportunity for growth in this sector. While some of these opportunities may require advances in research, others can be addressed by enabling exisiting rule-based technologies to interoperate according to standards-based methodologies and processes. The basic goal of the Rule Interchange Format (RIF) Working Group is to devise such standards and make sure that they are not only useful in the current environment, but are easily extensible in order to deal with the evolution of rule technology and other enabling technologies.
Nearly fifty use cases documenting the need for a RIF were originally submitted. These were grouped into eight general categories and then synthesized as much as possible. The following use case descriptions, guided by this synthesis, provide scenarios that motivate the need and explain the benefits of a RIF. They are also intended to provide an ongoing reference point for the working group in its goal of providing a precise set of requirements for a RIF.
Note that in order to enhance readability and to avoid the appearance of syntactic prejudice we have deliberately avoided the use of formal notation in representing rules in these use cases.
This use case illustrates a fundamental use of the RIF: to supply a vendor-neutral representation of rules, so that rule-system developers and stakeholders can do their work and make product investments without concern about vendor lock-in, and in particular without concern that a business partner does not have the same vendor technology. It also illustrates the fact that the RIF can be used to foster collaborative work. Each developer and stakeholder can make a contribution to the joint effort without being forced to adopt the tools or platforms of the other contributors.
John is negotiating an electronic business contract regarding the supply of various types of items that Jane's company is manufacturing. Jane and John interchange the contract-related data and rules involved in the negotiation in electronic form so that they can run simulations. Both agree on a standard Business Object Model / data model (i.e., vocabulary / ontology) for the goods and services involved - in this case an XML schema and appropriate test XML documents are interchanged with their rules. Since John and Jane run applications based on different vendors' rule engines and rule languages, they interchange the rules using the RIF; both vendors used can interpret the XML schema and data, and produce the results as an amended XML document. John's company defines its purchase orders in terms of an XML description of goods, packaging, delivery location and date with delivery and payment rules. A rule proposed by John might be the following:
If an item is perishable and it is delivered more than 10 days after the scheduled delivery date then the item will be rejected.
Jane replies with some suggested rule changes:
If an item is perishable and it is delivered more than 7 days after the scheduled delivery date but less than 14 days after the scheduled delivery date then a discount of 18.7% will be applied to this delivery.
John considers this and agrees with Jane. Both organizations utilize these rules in their operational systems using disparate rule representations internally to compute prices for this order and determine contract compliance.
Future requests for the supply of items by John's company are defined on their Purchasing web site, as the appropriate XML schema and a RIF ruleset (or rulesets). This allows Jane's company and its competitors to respond electronically with XML cost sheets. Suppliers respond with multiple cost sheets with different variations on the RIF rules proposed by John's company, allowing John's company to review the alternative rules with their associated costs to determine whether they, as a business, would benefit by relaxing or adding new rules as proposed by suppliers.
This use case concerns the ability of parties involved in formal transactions or procedures, e.g., credit card authorization of a purchase, access of private medical records, etc., to express and protect their interests within a policy-governed framework. The goal is to formally encode the preferences, priorities, responses, etc., of the parties in such a way that the overall policy can work as intended while providing opportunity for automatic negotiation of terms when allowed by the policy. Utilization of the RIF in this use case would extend the scope of this technology, affording a higher degree of interoperability, as well as enabling re-use and sharing of preferences, etc., through interchange. The detailed scenario below shows how this would work.
Alice wants to buy a device at an online site called "eShop." Alice employs software called "Emptor" that functions as automated negotiating agent for buyers. eShop employs software called "Venditor" as automated negotiating agent for sellers.
Alice's and eShop's policies describe who they trust and for what purposes. The negotiation is based on the policies, which are specified as rules, and the credentials Emptor and Venditor have, they are disclosed (interchanged) so as to automatically establish trust with the goal of successfully completing the transaction.
Policies are themselves subject to access control. Thus, rule interchange is necessarily done during negotiation and (in general) depends on the current level of trust that the systems have on each other. Since Emptor and Venditor might use different rule languages and/or engines for evaluating (own and imported) rules, a (standard) rule interchange format (RIF) needs to be employed for enabling the rule interchange between the two systems.
When Alice clicks on a "buy it" button at the eShop's Web site, Emptor takes over and sends a request to eShop's site. Venditor receives the request and sends parts of its policy (i.e. a set of rules) back to Emptor. Among other things, the policy states that:
A buyer must provide credit card information together with delivery information (address, postal code, city, and country).
For determining whether Venditor's request for information is consistent with Alice's policy, the Emptor takes its rules into account, which state for example:
Disclose Alice's credit card information only to online shops belonging to the Better Business Bureau.
By disclosing (interchanging) the above given rule, Emptor asks Venditor to provide credentials saying that it belongs to the Better Business Bureau, Alice's most trusted source of information on online shops. eShop has such a credential and its policy contains a rule stating to release it to any potential purchaser. Hence, Venditor passes the credential to Emptor. Emptor is now ready to disclose Alice's credit card information to Venditor but it still must check whether disclosing all the information does not break Alice's denial constraints. Alice has stated two constraints stating:
Never disclose two different credit cards to the same online shop.
For anonymity reasons, never provide both her birth date and postal code.
Different choices exist for implementing the above given constraints as rules the Emptor has; choosing the type of rules for implementing policies depends also on the capabilities the Emptor system has.
For this purchase, anonymity is no issue and only information on one credit card is requested. Thus, Alice's constraints are respected. Emptor therefore provides Alice's credit card information to Venditor. Venditor checks that Alice is not on eShop's blacklist, then confirms the purchase transaction.
Companies that provide software such as Venditor and Emptor would make use of the RIF in a number of ways. The rules expressing Alice's and/or eShop's policies could be expressed in different rule languages but still work with the software, using RIF-based interchanges. Secondly, assuming Venditor and Emptor are products of different companies using different internal rule languages, it would still be possible for them to work together in real-time. When these two systems need to exchange policy or preference information of their respective clients they would use the RIF to enable the interchange in real-time. When Venditor sends its initial policy information to Emptor it uses the RIF. Emptor takes that policy and translates it from the RIF to its internal representation in order to determine what it needs to do.
This use case demonstrates how the RIF leads to increased flexibility in matching the goals of end-users of a service/device, with the goals of providers and regulators of such services/devices. The RIF can do that because it enables deployment of third party systems that can generate various suitable interpretations and/or translations of the sanctioned rules governing a service/device. There are at least two broad areas in which such third-party services could be deployed.
One area is Dynamic Spectrum Access for wireless communication devices. Recent technological and regulatory trends are converging toward a more flexible architecture in which reconfigurable devices may operate legally in various regulatory and service environments. The ability of a device to absorb the rules defining the policies of a region, or the operational protocols required to dynamically access available spectrum, is contingent upon those rules being in a form that the device can use, as well as their being tailored to work with devices in the same class having different capabilities.
In this use-case we suppose a region adopts a policy that allows certain wireless devices to opportunistically use frequency bands that are normally reserved for certain high-priority users. (The decision by the European Union to allow "Dynamic Frequency Selection" (DFS) use of the 5 GHz frequency band by wireless systems, a band intermittently used by military and weather radar, is a recent example - See http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2005/l_187/l_18720050719en00220024.pdf.)
Suppose the policy states:
A wireless device can transmit on a 5 GHz band if no priority user is currently using that band.
How does a device know that no priority user is currently using a band it wants to use? The answer will depend on the specific capabilities of the device. One type of device may answer this question by sensing the amount of energy it is receiving on that band. That is, it might employ the rule:
If no energy is detected on a desired band then assume no other device is using the band.
A second type of device, may get information from a control channel that lets it know whether the desired band is being used by a priority user. That is, it might employ the rule:
If no control signal indicating use of a desired band by a priority user is detected then assume the band is available.
So each type of device will need to employ different "interpretations" or "operational definitions" of the policy in question.
Now assume that there are 10 manufacturers of these 2 different types of wireless devices. Suppose that each of these manufacturers uses a distinct rule-based platform in designing its devices. Each manufacturer needs to write 2 interpretations of the policy (for each of the two types of device). That means that 20 different versions of the policy must be written, tested and maintained.
Enter the RIF. The 10 manufacturers form a consortium. This is a third-party group that is responsible for translating regional policies into the RIF. When it does so, however, it provides different versions corresponding to the possible interpretations (operational definitions) of the policy. So in this case, 2 RIF versions of the DFS policy are provided for the 2 types of device mentioned above. Each of these RIF specifications can be automatically translated into the appropriate rule-platform provided a RIF-Compiler for the target device architecture exists. Clearly it will be in the interest of each device manufacturer to develop such compilers. That is because the manufacturer only needs to develop such a compiler once for every architecture it owns. Contrast that investment with having to produce, test, and maintain different versions of various policies over the lifetime of a product.
This arrangement also allows the overall process to be organized in a fashion that maintains the natural division of labor in the corresponding division of artifacts produced by that labor: the policy and its various interpretations are written and maintained in platform-independent artifacts (the RIF); knowledge about how to translate from the RIF to a particular device architecture is maintained in the compilers. A change in policy is inserted at the top level in the policy artifact hierarchy where it should be; possible operational interpretations of that change are inserted at the next level down; the implementation implications for the various device architectures is generated automatically at the lowest level.
Web Services and Service Oriented Architectures is another broad area in which third party rule interchange services would be enabled by the RIF. Web-based service architectures offer a dynamic and flexible approach in which differentiated Service Level Agreements (SLAs) can be matched to particular circumstances automatically as required. For example, what constitutes a certain level of service, or an acceptable premium for such a level, might vary depending upon the laws in the region in which the service is provided or contracted. SLAs written in the RIF could be automatically translated into appropriately customized agreements by a third party service provider.
A business process (BP) designer designs processes that can span multiple departments in the same business as well as other business partners. A classic example of this is the integration of supply chain business processes which typically involve multiple partners. Supply chain integration involves exposing a certain amount of business logic between partners as well as integrating processes across partners. In such activities it is therefore often necessary to access or invoke rules that originate in other ownership domains.
A key part of a business process is the logic used to make decisions within the process. Such logic is often coded in rules because rule languages are easier for BP designers to understand and manipulate than procedural code (as in Java) -- although both forms of business logic are prevalent. Where business logic is represented in different rule languages this presents a significant burden to the BP designer in designing an integrated process.
Two primary integration modalities are possible: importing the different rulesets into a single engine and processing them in a uniform manner, or accessing the rulesets by querying remote engines and processing the results. Each modality has its uses and contra-indications. Where there are strong ownership boundaries involved it may not be permitted to merge rule sets of partners.
For example, in an insurance adjustment process, the inspection of a damaged vehicle is often performed by independent inspectors. The critical decision in how an insurance claim will proceed is whether the damage results in a total loss or whether a repair is feasible:
If inspector believes vehicle is repairable then process as repair otherwise process as total loss.
The question of whether a vehicle is repairable is one that is dependent on the processes executed by the inspector and cannot be directly integrated into the insurance companies own adjustment process. The insurance company effectively queries the inspector's logic. Within the adjustment process, the overall flow will be quite different for repairable claims and total loss claims.
Even in the case of a single company, which is nominally under a common ownership domain, information and business logic is often controlled by multiple stakeholders. For example, a large company will often be organized into semi-independent profit centers (business units). Each unit will be motivated differently, will have different ontologies and business logic and may use different rule languages to represent their logic (this is particularly the case where one company acquires another company).
The RIF should be used to permit the BP designer a unified view of the different partners' business rules in designing the process, while at the same time permitting the partners to continue to leverage their own business rules without changing their own technologies.
When a business process is deployed, the engine running the BP may dynamically import the business rule logic of multiple departments when they are in the same organization; or, if that is not permitted, then a query-style access to partners' business rules may be used. In this way, the RIF permits a unified dynamic view of the business rule logic no matter what the original form of the rules.
For this to be viable from a business perspective it is critical that the semantics of the rules and query exchange be completely predictable and preferably loss-less.
This use case is about the management of rules representing business policies and practices in cases involving multiple organizations and/or multiple units within a single organization. One of the key challenges in dealing with such domains is that some rules that support business policies and practices might not be directly executable by a machine, whereas others, even those dealing with the same situation, are machine executable. Rules that are not directly executable might need something from a person, e.g. a decision or confirmation of an action, at which point the rule execution system might be able to use the rule in a reasoning process. The RIF can help to make such domains more tractable and amenable to machine processing by allowing rules to be labelled with tags that express the necessary meta-level information required to make a reasoned determination as to the intended status of a given rule.
This scenario uses the (fictitious) car rental company, EU-Rent, used as the SBVR case study. The EU legislation discussed is also fictitious.
EU-Rent's corporate HQ deals with CarWise, a consultancy company with expertise in managing fleets of vehicles. One service CarWise offers to its clients is negotiating with EU regulators to clarify regulation. It provides both interpreted regulation for EU-Rent as an organization, and rules that can be directly used by IT rules systems.
An EU regulator issues a directive dealing with insurance for vehicles owned by companies. One of the interpretations relevant to EU-Rent is:
Every car rental must be insured for damages to third parties.
EU-Rent receives this and accepts that it must comply. It also decides that it will maintain its compliance documentation electronically. CarWise provides EU-Rent with rules for electronic signatures for insurance schedules, which can be directly used in EU-Rent's IT systems, e.g.
Each schedule must have electronic signatures from two EU-Rent employees of at least manager grade.
EU-Rent corporate HQ decides that
Cost of third-party insurance will be built into the basic cost of each rental.
so that there is no possibility that it can be omitted from rentals. It provides this rule to its companies in each of the EU countries in which it operates. EU-Rent operating companies also use consulting companies like CarWise for national level expertise. In the UK AutoLaw advises EU-Rent of rules for placing aggregate insurance for fleets with more than one insurer in order to spread the risk:
For fleets of more than 200 vehicles, fleet insurance policies must be placed with at least 3 insurers where at least 25% of the risk is with each insurer.
AutoLaw also provides the rules for calculating tax liability for aggregated insurance for direct use by EU-Rent's IT systems. These include, e.g.
For an individual rental, the tax on aggregated insurance is 1.5% of the simple cost of the rental
Simple cost of rental is the cost for use of the car, excluding extra equipment, additional drivers and VAT.
EU-Rent UK 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 rule:
Insurance policies that provide separate third-party cover must not be renewed.
EU-Rent HQ permits this, not just for UK, but for all its operating companies, and disseminates it.
EU-Rent HQ is concerned about meeting deadlines for electronic filing. It introduces a new rule that it distributes to operating companies:
Each electronic compliance document must have its required electronic signatures 48 hours before its filing deadline.
This means that if '48 hours before filing deadline' occurs and the electronic signatures are not present, an operating company's rules system must report the out-of-compliance situation, and then wait for the responsible managers to provide the signatures.
Decision support systems aid in the process of human decision making, especially decision making that relies on expertise. Reasoning with rules is an important part of this expert decision making. For complex decision support systems, it is expected that rules will be furnished by a variety of different sources, including ontologies, knowledge bases, and other expert systems. This use case illustrates how the RIF makes it possible to merge rulesets from diverse sources in diverse formats into one rule-based system, thereby enabling inferences that might otherwise have remained implicit.
Medical decision support systems, such as the ones discussed below, might use rules from pharmaceutical knowledge bases, laboratory knowledge bases, patient data bases, and medical ontologies. For example, a large amount of information on therapeutic medications (drug taxonomies, indications, contraindications, and clearance times) and diseases (disease taxonomies, etiologies, and symptoms) is contained in existing ontologies such as SNOMED Clinical Terms®. Rules can be used to express therapeutic recommendations, to formulate queries about relevant prescriptions for a patient, and to assess the effectiveness of a treatment.
The following scenario illustrates how rule-interchange would be used in various medical decision support systems to support the following functionalities:
Improving situation assessment, e.g., determining when a patient needs to be put on medication, or have his medication switched.
Prescribing a course of action, e.g., determining which drug is best for a patient in a particular circumstance.
Improving event planning, e.g., determining whether a patient can be scheduled for a procedure given the medication that he is currently taking.
Bob, 62 years old and reasonably healthy, has been going to his internist, Dr. Rosen, for several years for control of his Type II diabetes. Dr. Rosen has been using the AutoDoc system to help him decide when to switch to medications and which drugs to prescribe. The AutoDoc system uses two sources when making its recommendations: a laboratory knowledge base giving particular results for patients and specifying when these results are out of normal range, and a pharmaceutical knowledge base giving guidelines for the use of medications. Automated reasoning with rules from these combined sources is possible if the rules are first mapped to the RIF. Here are two specific examples of such synergistic effects.
This scenario discusses the fictitious expert systems AutoDoc and MEDIC. In the interest of readability and brevity, the information and rules presented in the following scenario may not precisely capture the current state of medical knowledge and best practices in this field, but may be somewhat simplified.
Originally Bob's diabetes was controlled through diet and moderate exercise. In time, however, Bob's blood glucose level began to rise, even under this regimen. Due to Bob's elevated HbA1c level (which indicates one's average blood sugar level over the last several months), Dr. Rosen prescribed oral medication for Bob. He was forced to change Bob's medication a number of times over the course of a year. He first prescribed Precose, a oral alpha-glucosidase inhibitor, but had to discontinue this medication due to undesired side effects. He then prescribed several sulfonylurea drugs, Micronase and Glucotrol, to no avail. Bob's lab results still indicated an elevated HbA1c level. The following rule from the laboratory knowledge base suggests that Bob's treatment at that time was not effective:
If a Type II diabetes patient's current level of HbA1c is high, then the patient's current treatment is considered to be ineffective.
To deal with this problem, Dr. Rosen was about to prescribe Glucophage (metformin, one of the biguanides) 850 mg., 3 times a day, when as usual, he double checked his prescription with the AutoDoc system. The system, based on the following guidelines from the pharmaceutical knowledge base, informed Dr. Rosen that he should have prescribed an oral bitherapy (two medications, each of which controls blood sugar levels) instead of a monotherapy.
If an oral monotherapy at recommended doses of a sulfonylurea or biguanide, combined with lifestyle changes, is ineffective, then the monotherapy should be replaced by an oral bitherapy.
Based on the recommendation from AutoDoc, Dr. Rosen switched Bob's prescription to Glucophage and Avandia (rosiglitazone, one of the thiazolidinediones).
Bob recently suffered a concussion and has become increasingly forgetful. He went to see a neurologist, Dr. Cervello, who prescribed a contrast MRI (Magnetic Resonance Imaging). When asked about current medication, Bob told Dr. Cervello that he was taking Glucotrol to control his diabetes, forgetting that he had been switched to Glucophage. This was potentially problematic, since Glucophage should not be taken close to the administration of a contrast injection.
Fortunately, when Bob went to the lab to schedule his MRI, the medical receptionist pulled up MEDIC (Medical Event and Drug Interaction Consultant), the hospital's new automated system, which checks for incompatible medical events and/or drugs (e.g., liposuction scheduled during pregnancy, blood thinners prescribed before surgery, etc.).
MEDIC uses a variety of sources in its reasoning, including:
the pharmaceutical knowledge base, described above
the patient data bases, which gives the patient record, including the medications a patient is currently taking
the hospital medical event protocol knowledge base, which details the protocol used for different medical procedures
In this case, MEDIC uses all three sources, and pulls up the following information:
Metformin is contraindicated with contrast dye.
Metformin is the generic form of Glucophage.
Bob is taking Glucophage.
The contrast MRI requires as one of its steps injecting the patient with contrast dye.
MEDIC therefore determines that Bob should not be taking the contrast MRI at this time.
For MEDIC to work, the rules from these different sources must be mapped to a unified interchange format.
Rules are often used in conjunction with other declarative knowledge representation formalisms, such as ontology languages (e.g. RDF and OWL), in order to provide greater expressive power than is provided by either formalism alone. Ontology languages, for example, typically provide a richer language for describing classes (unary predicates). Rules, on the other hand, typically provide a richer language for describing dependencies between properties (binary predicates), and may also support higher-arity predicates.
Rich domain models combining both rules and ontologies are often needed in domains such as medicine, biology, e-Science and web services. In such domains, several actors and/or agents are involved that have to interchange the data, ontologies, and rules that they work with. An example is the use of such a domain model in an application that aims at assisting the labelling of brain cortex structures in MRI images. In this case, an OWL ontology is used to capture knowledge about the most important brain cortex anatomical structures, and a rule base is used to capture knowledge about mereological and spatial dependencies between properties.
For example, a rule is used to express the dependency between the ontology properties isMAEConnectedTo and isMAEBoundedBy, in particular (a simplified form of) the knowledge that two Material Anatomical Entities having a shared boundary are connected:
If MAE X is bounded by Z and MAE Y is also bounded by Z then X is connected to Y.
Benefits of interchange include the ability to collaboratively develop and share valuable knowledge, the ability to integrate anatomical images, possibly from distributed image sources, and the ability to use large-scale federated systems for statistical analysis of brain images of major brain pathologies. Requirements on the rule interchange format include semantic compatibility with OWL-DL and RDF, and the ability to provide reasoning support over combined ontology and rule bases.
Note: This is a synthetic use case, used as an example in the charter. The Working Group expects to replace this use case with a real-world data integration use case in a future version of this document.
Jackson is trying to find someone: he needs at least one more client before the end of the quarter. He has access over the web to dozens of databases, some public, some licensed, and some maintained within his company. Together, they contain millions of potential candidates, but how is he going to narrow the field to the five or ten leads he should seriously pursue?
He thinks for a minute, then constructs a new query. He clicks on interesting properties, sees their values, and locks in the ones he thinks will act as useful filters. After a few minutes he gets frustrated, because the same concepts seem to have different names in different databases. Worse, the same idea is sometimes expressed in different structures; one database follows the the model of having "name of assistant" and "phone number of assistant" properties, while another simply has an "assistant" property, which links to another person. Trying to handle structural variations like this in his query is becoming impossible.
Fortunately, Jackson's system supports a rule language. The query construction interface helps him construct mapping rules between different constructs which seem equivalent to him, letting him infer new information that is customized to his needs, so he can query over a virtual unified database with a structure that seems to him to be simple and straightforward.
In fact, these rules were already being used; the data views Jackson saw were in many cases constructed by rules other people had written. His own rules will be available to his department (because he stored them in department workspace), allowing his co-workers to use the unified view he finds so useful.
The Working Group has not yet prepared text for this section. Requirements will be presented in an upcoming Working Draft.


text:
2013 Boulevard road race, a tragedy in three parts
February 3, 2013 § 8 Comments
Part I: The Venus fly-trap
I stood in the sunny parking area, having just arrived at Boulevard, and contemplated the only thing that a bike racer contemplates before registering and changing into his battle garb: Where are the port-o-potties?
Then I remembered that Boulevard had none. The smart money voided the chamber up at the Golden Acorn casino gang toilets; the dumb money drove down to the race site and used the quaint wooden latrines.
I peeked into the first one, which was easy to do because it had a large window with no glass in it, facing directly from the barbecue and parking area into the direct view of a toilet. On the down side, if you were scarfing a hot dog with chili and looked the wrong way, you'd catch a full frontal of someone grunting and straining away to make space for another round of wieners.
On the upside, if you were the one grunting and straining, you got to watch all your friends drink, eat, and be merry while you took a little sunbath and did your business.
I looked in and was greeted by G$, trousers around his ankles as he soaked in the scenery and the sunshine. "Yo!" he said. "Don't be shy!"
I stuck my head further into the window and looked at the other two units. Using either would have required a hazmat suit, so I sauntered around the building and entered the other toilet. This one had no windows, was almost pitch black, and had a single unit stuck over in the corner. Spiders and roaches and a scorpion scurried off as I approached.
My eyes adjusted to the gloom, and indeed the unit was spotless. It's amazing how clean a public pooper will remain, even in a barbecue venue frequented by tweekers and chili-dog aficionados, when it's guarded by scorpions.
I brushed a couple off the rim and into what was sure to be a very unpleasant way to die, even for a scorpion, and settled in. I could hear footsteps outdoors and voices.
"That other place was out in the fucking open practically. I ain't shitting there. Gotta have my privacy."
The two speakers stepped into my domain and saw me over in the corner. "Oh, wow, dude, sorry."
"No problem," I said. "I'll be done shortly. Just watch out for the scorpions."
If it looks sunny and feels warm, put on an extra layer
After registration I got dressed. Thermal undershirt. Thermal arm warmers. Jersey. As I got ready to put on my thermal long-sleeve jersey, Quickie drove up. "Yo, dude!" he said. "I got 34th here last year!"
"That's, uh, awesome."
"You got 36th!"
"I did?"
"Yeah, you were behind me."
"That makes sense, I guess, if you were 34th and I was 36th."
"Yeah, you were 36th. I was almost 33rd."
"What happened?"
"Fucking pit bull chased me down on the final climb. I tried to sprint away but cramped."
"Did you live? Or did he kill you?"
"I had to get off my bike and put the bike between me and him. I thought he was going to eat my fucking frame. That's how come I got 34th."
"Bummer. I mean, awesome."
"You were behind me," he reminded me again.
"Oh, yeah, well I was behind a lot of people."
"Thirty-five of them, actually. You were 36th."
This was getting repetitive, even for me. "Yeah, I guess so."
"Hey, what's with the long-sleeve jersey? It's fucking 70 degrees out here."
"Yes, it is."
"You'll broil in that thing. Stick a butter pat, some soy sauce and ketchup down your back after the first lap and the coyotes will be able to eat you barbecued. Don't overdress, dude."
"I won't. But the wind is howling out on the course. And if you get dropped you won't finish before five. And by then the shadows will be long. And the cold wind will cut to your core. And your sweat will freeze. And you will die if you're lucky. The warm weather at the start lulls everyone into a false sense of security. Out on the course the helpless riders freeze and seize. It's like a Venus fly-trap. Invites you in, then covers you in the toxic goo of your own sweat, spit, blood, and mucous, and kills you. That's Boulevard."
"You planning on getting dropped, then?"
"I always get dropped at Boulevard."
"Yeah," he said. "Me. too. But I was…"
"Thirty-fourth last year," I finished.
"Yeah!" he brightened. "And you were 36th!"
Bike racing is a sport of tiny, incremental changes to maximize performance
Lauren and Ron Peterson have helped me immensely as I've become more focused on fine-tuning my bike fit. Last winter on a ride Ron said, "Hey, dumbass. Your saddle's too low. Raise it."
"Oh. How can you tell?"
"You knees are hitting your chin. Raise the danged saddle."
"How much?"
"Start with two inches."
So I did, and immediately noticed positive changes. The next time Ron dropped me on a ride, he said, "Another inch, wanker," as he whizzed past.
Each time I went to the bike shop to get my saddle raised, the mechanic shook his head. "You can't raise your saddle two inches at one time. That's massive."
"Oh. How much do most people raise it?"
"A giant lift is a centimeter. Usually it's done in millimeters."
"Make it three inches, then."
Lauren had also helped me with my bike fit. "Yo, Wanky," she said. "That bike posture where you're all hunched like a dog going after a sofa cushion is robbing you of power. Not that you have any."
"Fact. You need to find a balance between being squeezed over your bike like a pretzel and sitting up in the saddle like a windmill. Bump up your stem a fraction."
So I threw away the whole stem and got one of those up-pointing dork stem things that raises your bars about a foot.
"You don't do things by halves, do you?" she said as we walked over to the Boulevard Cafe to get a cup of coffee.
Victory and defeat are defined by the care one uses in choosing one's equipment
A few days before the race I'd gotten tired of my road bike, and had taken it over to Luca Brazzi's for him to part and sell on e-Bay. "Dude," he said. "Glad to do it, but aren't you racing Boulevard this weekend?"
"What are you gonna do for a bike?"
"I'll ride my 'cross bike."
Luca looked at me for a minute, pausing politely for the punch line. None came. "Dude. You can't race Boulevard on a 'cross bike. You'll get dropped on the first lap."
"I always get dropped on the first lap."
"Then you'll get dropped in the parking lot."
"So I'll get home early."
"What are you going to do for gearing?"
"What do you mean?"
"You know on the back side of the course where you spin out a 54 x 11?"
"What do you think is going to happen when you're running a 50-tooth chain ring?"
"I, uh, hadn't really thought about it."
"Here's what's going to happen: Your fucking legs are going to come unhitched at the pelvis and you're going to kill whoever's next to you when they get speared by your bony fucking legs whistling through the air at 50 mph. Here. Take the bike back. We can part it and e-Bay it after the race."
I had, however, made up my mind. "Nah," I said. "My Giant 'cross bike handles better than the Venge anyway. I'll be fine."
"You're nuts," he said.
Proper nutrition is the key to success
I was fanatical about proper eating prior to and during a race. That morning I'd had oatmeal, raisins, kimchi, eggs, sausage, yogurt, fruit, and coffee. The fartage alone would shell a dozen or so riders.
An hour before the race I carefully unwrapped my magic lunch. Quickie peeked in. "What the hell are you eating?"
"PB sandwich."
"Before a race?"
"Yeah. But I've got coffee to wash it down with."
He shook his head and went back to his car.
Humpster wandered over. He was doing Boulevard for the first time and wanted some advice from a seasoned wanker who'd been dropped every time on the first lap for four years in a row. "What are you doing for nutrition during the race?"
"I'm taking a small water bottle."
"What are you putting in it?"
"Dude," he said. "The race is almost seventy miles. You'll die."
I thought for a second. "You're right. I'll take two."
He rolled his eyes. "What about food?"
"I don't need food. I'm just taking a pocketful of these." I showed him a handful of dates.
"Gross. What the fuck are those? Baby turds?"
"They're medjool dates. Filled with, uh, energy stuff and things."
"Gimme one."
Before I could warn him about the unbreakable granite pit in the center, he chomped hard. Shards of tooth went everywhere. "Dogfuckit!" he screamed. "My tooth!"
"I was gonna warn you," I said. "About the pit. It's really hard."
He stanched the blood with his cycling glove and staggered back to his car. "Don't worry!" I called after him. "It's just one tooth! That's why Dog gave you 32. Or was it 36?"
Quickie, who had only heard part of the conversation, shouted over, "You got 36th, dude! Thirty-sixth!"
Perfect preparation on the day before the race is the key
On Friday I'd ridden to work and then gone to the gym. Since I wasn't riding hard, I figured it would be a great day to do some squats. I loaded up the bar with two massive five-pound plates on each end and went into a deep squat.
The giant muscled man with tattoos looked on in amazement. "Dude," he said as I grunted and roared and strained and heaved and pushed and sweated and almost threw out my back as my legs straightened, "you've only got ten pounds on the bar."
It took me a couple of minutes to catch my breath. "I know," I said. "But today I'm going big, so get outta my way."
As I finished off the set, a small group of hecklers gathered around the squat rack. "C'mon, Wankster! You can squat those ten pounds! Be the animal! Be the beast!"
"Let's do it Wanky! Well, maybe you should replace the fives with 2.5's. Just sayin'!"
After three sets my thighs were so wrecked that Tattoo Dude had to grab me by the armpits to lift me to a standing position. It briefly occurred to me that all this thigh work might not be such a great idea the day before a big race. "Fuggit," I told myself, and moved over to the inclined leg press thingy.
Still delirious from the massive squattage, I accidentally put on the 45-lb. plates instead of the 25-lb. plates. When I released the switch control protector thingy, the entire contraption came crashing down like, well, a ton of steel plates, jamming my right knee hard into my rib cage. I felt a sharp pain and something under the skin went "pok-kee-t."
I somehow got the weights back up to where I could engage the protector locking thingy, and tried to stand up. The sharp stabbing in my rib cage was so intense I could barely breathe. Tattoo Dude came over. "You fuck yourself up, Wankster?"
"Where does it hurt?"
I pointed to my rib. "Here…gasp…"
"Oh, you probably just bruised or broke a rib. Get back into the fucking leg press and finish your set. Just don't hit your damned broken rib with your knee and you'll be fine."
He put me back into the leg press thingy and reduced the weight to an amount appropriate for a young elementary schoolgirl and watched as I completed the set. Between the pain in my rib and the pain in my throbbing thighs I could barely breathe.
Tattoo Dude then slapped on a couple of the giant plates, two per side. "Here you go. Now do some calf raises."
When I finished he picked me up out of the thingy and carried me over to the leg extender. "You wanna go big? You wanna be big? You wanna flex and pop those veins? We'll get you beefed up in no time."
"But, Boulevard tomorrow…" I protested.
"Yeah, you can walk up and down the fuckin' Boulevard tomorrow all day long, and all night, too. We'll put legs on your skinny ass that will get you all the tricks you can handle."
He plopped me down into the leg extender and loaded it up with a huge, unthinkable 60 pounds. "Hit it!" he yelled.
Out of fear I jerked my legs straight, each knee joint making creaks and pops and tearing noises that sounded like a wing separating from a fuselage in outer space, that hollow, empty rending sound of bone and muscle and gristle all twisting knotting and grinding. "More, you weakling!" he roared.
Three sets later I was in tears. He carried me out of the gym and set me gently on the curb. "Good job, weakling. You won't be able to walk tomorrow, but that's what it takes if you want to go big."
"Walk tomorrow?" I thought. "I can't even walk to the car."
When it all comes together: Nutrition, equipment, adjustments, clothing, and pre-race preparation
Finally zipping up my jersey, I assembled my 'cross bike. Now I was really wondering about the downhill. How windy would it be? What if I had the gears to hang on the climb, but got shelled on the damned downhill? How mortifying would that be?
I hopped on the bike to warm up, and my legs seized. The weights from the day before had completely destroyed what little musculature I had to begin with. Then I gasped from the sharp stab of the broken rib.
Had I done anything right?
I saw John Hall pedal by, and realized, "Yes, I have. I have the best-pinned on number in the whole damned race."
John had failed his comprehensive exams in Basic Number Pinning On, and had left huge gaps in the tops of his numbers. Whether he thought he'd save weight on safety pins, or whether he was counting on the reverse sail effect of the billowing numbers to push him faster, or whether he was planning to psych out his competition with the constant whirr, buzz, flap, and chatter from the fluttering paper numbers, it worked, as he turned in one of the great rides of the day.
At the beginning, though, he sounded like a small helicopter. It gave me some measure of confidence. My numbers were perfectly placed so that I could access the dates in my rear pockets and so that the officials could easily read my number. Not that it's hard to read a number when you're the last guy crossing the line, alone…
Tune in tomorrow for Part II: The Vomilitious Road to Hell
§ 8 Responses to 2013 Boulevard road race, a tragedy in three parts
That's some mighty fine writing.
Thank you
Pb sammich and coffee. I really dont see the problem!…unless you forgot the jelly…)…ps great read!
Though it came highly recommended a week or so ago, I wasn't sure about this blog at first. Crit/club racers are the absolute worst Freds. I'm happier to see 30 geriatrics with rear view helmet cams and head-to-toe hiviz clogging up the bike lane than the local team doing their "training bloc" for the absolutely meaningless Great Park Crit, but I think I get it now, and getting it is fucking hilarious.

subset: commoncrawl


text:
Jimmy Kimmel's 'Celebrities Read Mean Tweets' Is Too Funny For Words
Thanks to the rise of the social media site Twitter, celebrity users and your every day folk like you and me are closer than ever. But so are the nasty, catty tweets from the Average Joe to whatever celebrity they're mad at now. Jimmy Kimmel decided that celebrities should confront these mean (and often strange) tweets in his ongoing segment 'Celebrities Read Mean Tweets.'


text: The Knicks have the best record in the east after beating the Bobcats and destroying the Heat without Melo. We talk about how the Knicks are winning, if they can keep it up, injury worries, strategies and much more. We also find time to make fun of the Nets and Pelicans. Download Episode 159