W3C home > Mailing lists > Public > public-rule-workshop-discuss@w3.org > July 2005

Re: An appeal

From: Anthony Finkelstein <anthony@systemwire.com>
Date: Wed, 6 Jul 2005 19:05:29 +0100
Message-Id: <p06210213bef1c5392975@[128.16.12.221]>
To: Sandro Hawke <sandro@w3.org>
Cc: public-rule-workshop-discuss@w3.org

There is a risk here (on my part) of getting over-philosophical, 
which I wish to avoid. Let me simply say this ... in a typical 
organisational information systems setting, one strategy to achieving 
interoperability is to define a universal schema into which 
everything is mapped, another is to provide a lightweight layer that 
supports location and characterisation of resources and permits 
mappings between local schemas.

Do I believe that it is possible to devise a meta-language into which 
a large range of existing rule schemes can be mapped. No. At least 
not without cutting down rule languages covered or devising a 
language so large, abstruse and high-level that the practical 
benefits of mapping into it will be nullified. Probably both.

Do I see a big problem with "establishing a standard language of "if
condition then condition/error/action" and defining conformant 
implementations in terms of the above functions? Basically ... yes. I 
think we could characterise different rules and perhaps agree on 
syntactic matters but actually there are very many different ways in 
which these languages could be interpreted with subtle but 
practically important semantic differences.

We want to encourage a  rich ecology of rule languages and systems 
which are interoperable.

In any event here is what I propose:

That we start off by devising a simple metadata scheme that can be 
used to tag rule sets and rule engines. The metadata would include 
for the rule sets information about the nature of the rules and 
information relevant to industry users who may wish to exchange rule 
sets. For the engine, the metadata would include reference to a 
simple relatively high-level template based description of the manner 
in which rules are interpreted.

In short we start off by making rule sets and rule engines 'self 
descriptive' and worry about the hard stuff later - if at all.

Anthony





At 11:08 am -0400 6/7/05, Sandro Hawke wrote:
>  > When I attended the workshop I understood its goals to be to discuss
>>
>>  - "rule languages for interoperability"
>>
>>  - "a language for sharing rules"
>>
>>  - "a standard rule framework"
>>
>>  I was motivated by the statement "rule systems from different
>>  suppliers are rarely interoperable"
>>
>>  None of this implies a single rule language or indeed a single rule
>>  metalanguage!
>>
>>  As a scientist I don't believe this is possible to achieve. As a rule
>>  system vendor I don't believe this is good for technology or business.
>
>Can you explain this?  The normal approach to establishing
>interoperability, as I see it and in very broad terms, is to define
>one language/format/protocol which includes the important features of
>a key subset of existing pre-standard languages/formats/protocols.
>
>In this arena, things are somewhat complicated by the range of what
>constitutes the field.  It's probably not meaningful to have a
>constraint solver and a Rete engine conform to the same specification.
>Is that what you're getting at?
>
>What are the apples-to-apples functions performed by rule software?
>What bits of code could be put in interchangeable black boxes?
>
>Right now, I see three main ones:
>
>     * Inference.  Given some data and some rules, infer some more data
>       which logically follows.  An inference engine (or deductive
>       database) mostly fits behind a query interface, eg SPARQL, SQL,
>       XQuery. 
>
>     * Validation.  Use some rules to examine some data and see if it
>       meets certain criteria.  If not, issue errors or warnings.
>
>     * Service Execution.  Given some data, rules, and a set of
>       executable operations, run the engine and have it invoke
>       procedural code with parameters bound from the data.
>
>These functions are closely related: given a basic engine mostly
>geared toward doing inference (cf Prolog) or service execution (cf
>Jess), one can implement all three functions without a lot more work.
>
>Each area has its own typical language: "if condition then condition",
>"if [not] condition then error", and "if condition then action", but
>they obviously have a lot in common, too.
>
>Do you see a big problem with establishing a standard language of "if
>condition then condition/error/action" and defining conformant
>implementations in terms of the above functions?  Maybe it's too hard
>a problem; without standardizing on control strategies, the size of
>practical rule sets will be rather more limited, and the standard wont
>really work in practice.  But maybe that element can be addressed in a
>modular, contained fashion?
>
>Or were you thinking in a completely different direction?  :-)
>
>      -- sandro


-- 
_________________________________________________________________________

Anthony Finkelstein
Systemwire
Director of Strategy

TEL: +44 (0)20 7679 7293 (Direct Dial)
MOB: +44 (0)7771 813981
EMAIL: anthony@systemwire.com
WEB: http://www.systemwire.com

_________________________________________________________________________
Received on Wednesday, 6 July 2005 18:05:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:16:21 GMT