<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Already published it for him :) Michael if you think you'll end up
wanting to publish a number of blogs we can add you as a guest writer.<br>
<br>
Mark<br>
Edson Tirelli wrote:
<blockquote
cite="mid:e6dd5ba30809171335v137f65c9k7657b60a88195a3f@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
Michael,<br>
<br>
Really interesting use case. <br>
<br>
Thank you for sharing!!<br>
<br>
In case you are interested in publishing an article on the Drools
blog as a guest writer, it would be more than welcome!<br>
<br>
I completely agree with your suggestions on improvements. We just
need to find the time to work on them!<br>
<br>
Cheers,<br>
Edson<br>
<br>
<div class="gmail_quote">2008/9/17 Michael Zimmermann <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:list@incunabulum.de">list@incunabulum.de</a>></span><br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">HI
Edson,<br>
<br>
while discussing custom operators in drools trunk, you pocked me<br>
repeatedly to write something about how we use drools in a research<br>
project in the field of engineering. Here you go... may be it is also<br>
helpful or at least interesting for the other readers on this list :-)<br>
<br>
The Scope: Naval Engineering,<br>
<br>
In naval engineering vessels consists of thousands of parts (read: way<br>
more than an aircraft has today). Focusing on the steel structure, most<br>
of these parts are 2-dimensional plates of a certain size, thickness,<br>
grade and contour. For most fields of applications detailed regulations<br>
from classification societies etc. exist.<br>
<br>
Currently, the design of such objects is done using specialized CAD<br>
systems. Here the following issues are present in all cad systems and<br>
the design process today:<br>
- design time is 6 - 18 months (and not 10 - 15 years as for an<br>
air plane)<br>
- this means concurrent design, i. e. different people are working on<br>
parts or features that are closely related (strength, fatigue, cost,<br>
functional aspects or just being in the same room) on different levels<br>
of granularity (changing the hull 6 weeks before building happens!)<br>
- and no connection between design intent (specification on paper),<br>
design conditions (regulations, by the customer, results of<br>
calculations) and design solution chosen.<br>
<br>
Result:<br>
- We just have the geometrical data, nothing more in the CAD-model<br>
- No automatic checks if a certain component is changed; no automatic<br>
tests if a chosen design solutions really satisfies the conditions at<br>
lowest cost today<br>
- Therefore, changes (which you can't avoid) are cost intensive and<br>
error prone. Also, no one really knows why a certain solutions was
chosen<br>
<br>
Enter Logic & Drools<br>
<br>
The objective of our research is to make the design process context<br>
aware. Example: If I design a "door" in a watertight "wall" the cad<br>
system should check whether the selected door is a watertight model.<br>
<br>
So, using one of the most popular commercial cad systems for naval<br>
engineering the approach is to define the standards (currently<br>
paper-based) electronically using DROOLS. Also, context-information<br>
like watertight, stress level=x ... is added to the model and reused in<br>
the design process. For standard design tasks (in a part of the field of<br>
detailed steel structural design) we use drools to completely automate<br>
the design process, i. e.<br>
- find a design problem in the model<br>
- select a suitable solution adhering to all known boundary conditions<br>
- design the solution<br>
- and assign a assurance level for the solution (how good is it?)<br>
<br>
Lessons Learnt from an Engineering POV<br>
<br>
1) Extracting the knowledge is hard<br>
2) Formulating it logically sound even harder (even official regulations<br>
are vague on a regular basis)<br>
3) Defining the context a solution is valid for is even more difficult.<br>
4) Current CAD systems in naval engineering are not really capable to<br>
store meta information and to interface with other applications.<br>
<br>
Lessons Learnt from a Drools POV<br>
<br>
1) Drools is quite a nice system :-)<br>
2) With DSL even engineers can use it (once they are trained how to<br>
"Think Rules". And that is next to impossible)<br>
3) What's missing is some solution to easily define classes, class<br>
hierarchies and (!) instance data. We use OWL for now. eCore might be<br>
usable yet is terrible from a UI usability perspective<br>
4) Not drools is the problem but getting the data in and out!<br>
4a) The Smooks binding could be a godsend for this<br>
4b) Fact templates sound really promising if you think dynamically<br>
generated classes via web services...<br>
<br>
What's missing in Drools?<br>
<br>
- An OWL/RDF binding would be really great (we use OWL to define, edit,<br>
store our standards. But encountered the clash of open world logic (DL)<br>
and closed world logic (CS) more than once.) I know there is quite a<br>
large interest for such a solution in the Ontology user base.<br>
<br>
- Better support for constraint programming (what we do here and there)<br>
for simple primitive cases (read: selection processes) would help.<br>
Drools solver is overkill; drools rules can not handle this if you think<br>
optional constraints. The custom operator "== (open world style)" we<br>
talked about helps, though.<br>
<br>
<br>
<br>
Well, it has gotten longer than I expected yet only skimmed the surface<br>
of our approach, I think. Hopefully not to long :-)<br>
<br>
cu, Michael<br>
_______________________________________________<br>
rules-users mailing list<br>
<a moz-do-not-send="true" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-users"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Edson Tirelli<br>
JBoss Drools Core Development<br>
JBoss, a division of Red Hat @ <a moz-do-not-send="true"
href="http://www.jboss.com">www.jboss.com</a><br>
</div>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<br>
</body>
</html>