RE: can we all work together?

+1 for building a foundation.

It is very important to keep in mind at least two types of targets during
this phase, even if you only spell out the details for one.  I might even
argue, the more extreme and apparently incompatible the better.  It can be
very hard to go back and fix the extension mechanism.

What is very important is that we be thinking about unusual constructs right
from the start.

The goal here is NOT to map (say) PR's to OWL or viceversa. If the consumer
knows nothing about PR's then encoding PR's in RIF is not expected to enable
the consumer to execute the PR rules.  

Simply put, we need enough information present so that a consumer can take
an informed action, including inaction or handoffs.  Consider the following
diagram.


Rule Type 1.1|
.............|--> Family 1 with common semantic structure |
Rule Type 1.2|                                            |
                                                          |--> common
semantic structure
Rule Type 2.1|                                            |
.............|--> Family 2 with common semantic structure |
Rule Type 2.2|

The actual rule types and families make only a minor difference.  PR's may
need some syntactic structures that are quite different, but that is okay -
in fact good.  The harder it pushes the extension model the better.  We need
to be able to slot in radically different models.

The different families of rules will each have a common semantic structure
among themselves. Our first job is to characterize the commonalities and the
differences and again between the different families and to use that
characterization to provide a coherent and as simple as possible language to
capture and pass on enough information.

We need an extensible notation that is rich enough to write down typical
expressions in each Rule Type (and hence each family.)  It needs to provide
for enough annotation so that the rules that are received can be recognized
for what they are.  We need to allow for things we have not encountered.

Once we can write things down, we can turn our attention to recognizing the
definitions that are shared by different rule types in a given family, and
between families.  This will lead to defaults for the different types and
appropriate override mechanisms.


Stan


-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] On
Behalf Of Christian de Sainte Marie
Sent: Thursday, June 01, 2006 3:27 PM
To: Gary Hallmark
Cc: public-rif-wg@w3.org
Subject: Re: can we all work together?


With regards to Gary's useful comment, I would like to stress again that
phase 1 is _not_ about interchanging Horn rules: phase 1 is about building
the foundation of RIF.

The WG "mission in the first phase is to produce a W3C recommandation for a
very simple and yet useful and extensible format". Phase 1 must design the
foundation for a RIF that can be extended to cover the relevant rule
languages and usage scenarios while ensuring compatibility with other
relevant standard (including RDF and OWL; PRR; etc).

As the specification of such foundations would not necessarily enable, per
se, the interchange of one single rule, the charter mandates us to support
at least the interchange of Horn-like rules. This is to make sure that phase
1 RIF is useful to interchange at least some kind of rules, without forcing
us to deal with the complex and potentially contentious problem of multiple
semantics (some, horresco referens, being even possibly operational :-)

My point is that at least Horn does not mean only Horn: nothing should stop
us from harvesting any useful low hanging fruit we can find, provided that
we specify the extensibility and compliance models, XML syntax, the basics
of datatype support and data source access etc; and the semantics for Horn
rules, of course.

In summary, Garys' proposal can be extended without charter's violation to:
1. start with a common (XML) syntax and model theory for conditions
(actually: logical sentences), extending Boley et al proposal to include any
useful low hanging fruit (slotted atoms, types etc come to mind), without
specific consideration for Horn restrictions. But including everything
mandated in the charter, of course, like how it interacts with OWL etc.; 2.
add the specification for the head of Horn rules (probably as a restriction
on the step 1 language) and the semantics for Horn rules (seen like that,
that step looks like a no-brainer; but I may be wrong); 3. add the
specification for the conclusion of other kind of rules, with the
appropriate semantics (for the rules), including PR actions (and semantics).

The extensibility model that will allow it is phase 1, but how we specify
the appropriate semantics for different kinds of rules in as uniform a way
as possible is typically a question for phase 2 (Hassan's proposal to use
rules, à la Natural Semantics, is one possible approach; there are certainly
others).

Notice that specifying a step 1 language that covers the core requirements
of many different rule languages (including PR ones) would be a real benefit
in itself, even though step 3 will probably not be standardised before phase
2. It would, in particular, enable advance implementations beyond Horn
rules, thus initiating deployement, on the one hand; and suscitating useful
proposals and raising concrete issues to be considered in phase 2, on the
other hand.

Christian

Received on Thursday, 1 June 2006 15:38:41 UTC