[
Lists Home |
Date Index |
Thread Index
]
> [Uche Ogbuji]
>
> > I'm sure many of the rdf-logic folks came about this insight through
> rigorous training, but it came to me in a client project. When we started
> developing the ontology in the Sun project I've described here recently, I
> thought we were going to need some heavyweight business rules coding. In
> fact, we at Fourthought had already developed RDF Inference Language (RIL)
> as basically an expert systems shell for RDF, in order to implement such
> knowledgebases.
> >
> > I was amazed as we proceeded in design and analysis that pretty much all
> the business rules could be couched as classification problems. In the end,
> it turned out that DAML+OIL plus a solid query language (for which we used
> Versa) was all we needed for such business rules (we've since abandoned the
> inference part of RIL), and it was all declarative. It turns out that this
> is one of the most flexible designs I've ever been involved in, and I've
> come to understand some of the promise of WebOnt at least in closed systems.
> I will watch with interest as distributed ontologies come into play: ours
> was highly centralized, so we could manage performance and other matters
> closely.
> >
> > Certainly I have become a believer in the fundamental soundness of this
> approach.
> >
>
> Uche, could you give one or two more concrete examples of this (I mean,
> examples of replacing rules and inference by declarations and class
> analyses)? Especially something that gives the flavor of what surprised
> you. Not of course something that you shouldn't be talking about, but some
> kind of illustration. It would be very useful to me and, I'm sure, many
> others.
OK. One of the sensitive things about the project is the sorts of data in the ontology, so I'll just have to completely make up an example that I hope will do for illustration.
But first, I want to warn you: if you're looking for the sort of lightning-bolt epiphany that leads to manifestos, for-dummies books and start-up companies, you won't find it here. The crux is but a subtle change of viewpoint, but one that has a greater effect than I expected on design, and based on what I've seen of design in other projects, could have a useful effect in many applications.
If we were to model a traffic cop program, and we focused on the task of keeping freeloaders off the express lanes, we might establish the following business rule:
Only vehicles meeting the legal definition of energy efficiency are allowed in the express lane.
A common, non-methodology or language specific approach to implementing this business rule might look as follows:
1) If the vehicle is a motorcycle, go to 10
2) If the vehicle is a fuel-cell hybrid, go to 10
3) If the vehicle is a registered public transport vehicle, go to 10
4) If the vehicle does not have a current emissions test sticker, go to 11
5) If the vehicle has more than one occupant, go to 10
10) Take no action. Done.
11) Cite the vehicle for illegal use of the express lane. Done
Different methodologies have different sorts of kit for implementing this. In OO, you might have different object classes for cars, motorcycles, fuel cell hybrids and pub transport, and a checkLegalForExpressLane() methods for each. Some of these methods, corresponding to steps 1,2 and 3 would be simple "return true". Some, such as the method for object class Car would be more complex, checking the state of the object: i.e. number of occupants, presence and currency of emissions sticker, etc.
BTW, I am purposefully using the term "object class" to differentiate the OO concept of classes from the more general, set theoretic concept.
Notice one thing. I introduced an object class Car. There isn't one in the "raw" description of the business rule implementation. This is a common artifact of OO development: you often introduce object classes just to take advantage of polymorphism, even though these are not "first class" in the business problem description. I've come to believe this is a common cause of inflexibility of OO designs. What if we then have to consider a private bus. We can introduce a PrivateBus class now and implement the checkLegalForExpressLane() method. Probably this is very similar to that of the Car class. We could break out the common functionality to a mix-in class, or use one of the many design patterns available for this sort of thing. However, regardless of our approach, we will almost certainly have introduced some artifice to the design. Artifice is not bad per se, but since the real world does not correspond to our artifice, it can cause maintenance and integration probl!
ems.
Most importantly, some of the object classes we introduce that are specific to this business rule might not make sense in others. For instance, if we were also writing a business rule for determining what vehicles were allowed to pass through a tunnel, we might want to consider private buses and public transport buses together, which cuts across the object classes we set up for the express lane rule.
I could go on for ever on little implementation details that dog this approach. But I think you probably get the idea.
Trying to re-cast this as a general classification problem, I might do the following:
Consider what properties are fundamental to vehicles: i.e. number of wheels, their owner, propulsion system, etc.
Now, you can construct needed classes dynamically: a motorcycle is simply a vehicle with 2 wheels. A public transport vehicle is a vehicle whose owner is the transport authority. Et cetera.
We can then attach application behaviors to classifications in some way. This is similar to the idea of methods in OO, but our big gain is that we've decoupled the classification of objects from low-level implementation details.
Some things are still probably best treated as instance state, e.g. the number of occupants and the state of the emissions sticker.
So, to implement the business rule, we set up the dynamic classifications that allow us to view instances as motorcycle, pub transport vehicle, etc. We then attach application modules to the classes. We can reuse these classes and modules independently of each other while solving other business rules in the application. To address a business rule for who is allowed to pass through a tunnel, we might re-use the some of the classes (e.g. a motorcycle can always pass through a tunnel), but not others (we don't care about the distinction between private and public vehicles). To write a business rule for routing in a taxi company, we might want to reuse the application module that checks whether cars are allowed on the express lanes in their current state, but we'll have an entirely different set of classes we're concerned with.
So, there's an example. As I said, probably mostly just common sense, and much of it is scattered across a whole zoo of design patterns and tools. This is the first time I've used such an approach overall to drive an application's design from the get go, and as I've said, I've found that it is one of the most flexible designs I have ever been involved in.
I am reminded me of an old comp.lang.c++ post. I printed it out, and I've had it in my files for years. More recently, it just makes me chuckle when I read it. It used to inspire me to put in the work to get OO designs right. Now it just reminds me that so much about OO seems designed to make it hard for you to get designs right.
I just dug it up on Google:
http://groups.google.com/groups?q=chemical+classes+group:comp.lang.c%2B%2B&hl=en&as_drrb=b&as_mind=12&as_minm=1&as_miny=1993&as_maxd=11&as_maxm=12&as_maxy=1994&selm=1993May1.063557.11123%40ucc.su.OZ.AU&rnum=1
One neat note: the author of this note, John Max Skaller, has long since become a Python fan, and has even authored a Python variant, Vyper, which adds some features for rich expression that since made it into Python proper. Skaller was one of the people on my side when we were fighting against *any* sort of static typing cruft in Python after it had come up at IPC7 (a fight we seem to have won mostly because those who wanted static types couldn't agree among themselves what they wanted).
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/
DAML Reference - http://www.xml.com/pub/a/2002/05/01/damlref.html
The Languages of the Semantic Web - http://www.newarchitectmag.com/documents/s=2453/new1020218556549/index.html
XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel
|
