RE: Issue-31: Disjoint sorts - sketch of test case

Dave: thanks for the explanation.

I was trying to see from your example in
http://lists.w3.org/Archives/Public/public-rif-wg/2007Apr/0043.html why
disjoint sorts could not be used as the lowest common denominator. You
explained in that email how 
ruleset
   Forall ( p(a) :- And())             # p(a).
   Forall ( q(b) :- And())             # q(b).
   Forall ( p = q :- And())            # p = q.
could be interpreted differently for ONDS and OS. 

1. What would a DS version look like?   
   Forall ( p(*) = q(*) :- And())            # p = q.

2. If the example was written assuming ONDS what could an OS version
(i.e. OS result) look like?
   Forall ( p_ = q_ :- And())            # p_, q_ replace p,q references

3. If the example was written assuming OS what could an ONDS version
(i.e. ONDS result) look like?
   Forall ( p(*) = q(*) :- And())            # p = q.

4. Note that my suggestion would simply be
Ruleset( sort-type)
   Forall ( p(a) :- And())             # p(a).
   Forall ( q(b) :- And())             # q(b).
   Forall ( p = q :- And())            # p = q.
thereby deferring the problem to whoever and whenever

5. I wonder if the folks who develop things like abstract syntax trees
(e.g. in http://adm.omg.org/ ) have already covered this problem?
Probably not as it seems more related to logical languages than simple
programming languages - I found no reference in the abstract syntax tree
metamodel...

Paul Vincent
TIBCO | ETG/Business Rules 
 
> -----Original Message-----
> From: Dave Reynolds [mailto:der@hplb.hpl.hp.com]
> Sent: 02 May 2007 11:37
> To: Paul Vincent
> Cc: RIF
> Subject: Re: Issue-31: Disjoint sorts - sketch of test case
> 
> Paul Vincent wrote:
> > Thanks Dave: on the last point I would assume the translator from a
> > language (using sort A) L1A to RIF would choose the same sort as
used in
> > L1A: i.e. they would translate L1A to RIF(A).
> 
> [A terminology nitpick but I think you mean something like "style A"
> rather than "sort A". We are exploring three different styles of
> identifier aliasing, and whether some of our sorts are disjoint or
not.]
> 
> If we allow all of these styles via some semantic annotation then it's
> true that when translating to RIF a translator *could* simply pick
it's
> native style, but I'm not sure it would be wise to do so.
> 
> In particular, if I have a language with the more complex style OS
(the
> same thing can be both, say, a predicate and an individual constant)
> then I'd know that a lot of the people who might use my rules can't
> easily cope with that so I might be inclined to try to convert to one
of
> the simpler styles anyway to improve interoperation.
> 
> > Only the consumer would
> > have the problem of changing sort, if needbe, for example to a
language
> > (using sort B) L2B. Whether they would do this via RIF(B) is a
different
> > question...
> >
> > Whether a single sort is chosen for RIF or not, someone has to
translate
> > sorts, and it would be better if such translations were optional
IMHO...
> 
> Given that for any language we need to translate both to and from RIF,
> and given that different languages have different styles then it can't
> be optional for everyone.
> 
> The closest we could come is that if RIF adopted one of the simpler
> styles DS/ONDS then only people with the complex style OS would need
to
> worry. Which would be reasonable if the OS style is a minority, or at
> least if the rulesets which truly exploit the style are relatively
rare.
> 
> Seems to me like a general guideline: we need RIF to be rich enough
(to
> easily translate our rules into) but no richer (to avoid problems
> translating back from RIF).
> 
> Dave
> --
> Hewlett-Packard Limited
> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England
> 
> 
> >> -----Original Message-----
> >> From: Dave Reynolds [mailto:der@hplb.hpl.hp.com]
> >> Sent: 01 May 2007 20:55
> >> To: Paul Vincent
> >> Cc: RIF
> >> Subject: Re: Issue-31: Disjoint sorts - sketch of test case
> >>
> >> Paul Vincent wrote:
> >>> My apologies for what no doubt some will see as a "stupid
question",
> > but
> >>> if it is so problematic in defining a single sort for a rule
> > interchange
> >>> format, why can't the sort type simply be a characteristic (e.g.
> >>> metadata) of the format?
> >> Seems like a perfectly reasonable question to me. It is certainly
an
> >> option, though not one I personally favour.
> >>
> >>> Reasons to do this:
> >>> - removes the selection of one sort for all types of different
> >>> interchange languages
> >>> - simplifies the handling of standard use cases where interchange
is
> >>> between common rule language types (and therefore, presumably,
> > sorts)
> >> Not necessarily, depends on how fine grained these "types" are. You
> >> could certainly imagine different rule systems within the same
family
> >> which make different decisions on this but which you could
reasonably
> >> want to interoperate.
> >>
> >>> Reasons not to do this:
> >>> - will not provide a unifying rule interchange *language* (in case
> > this
> >>> matters)
> >>> - will likely increase the complexity of test cases where
> > translation
> >>> using different sorts and between different sorts will need to be
> >>> considered
> >> Not just test cases but implementations. To me the issue is that an
> >> "implementer" (i.e. someone trying to translate RIF Core rules into
> >> their language) would then have to cope with all three cases. This
> > would
> >> not only increase the translator complexity but it would mean that
all
> >> implementers would need to understand all three choices, which is
> >> probably an unreasonable burden. I think it'd be better to have
just
> > one
> >> choice that we have to explain to people.
> >>
> >> Dave
> >> --
> >> Hewlett-Packard Limited
> >> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> >> Registered No: 690597 England
> >>
> >>> Paul Vincent
> >>> TIBCO | ETG/Business Rules
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: public-rif-wg-request@w3.org
> >>> [mailto:public-rif-wg-request@w3.org]
> >>>> On Behalf Of Jos de Bruijn
> >>>> Sent: 01 May 2007 17:31
> >>>> To: RIF
> >>>> Subject: Re: Issue-31: Disjoint sorts - sketch of test case
> >>>>
> >>>>
> >>>> <snip/>
> >>>>
> >>>>> ** ONDS to DS
> >>>>>
> >>>>> The source rule uses the same identifier for distinct objects so
> > the
> >>>>> translator needs to introduce new identifiers:
> >>>>>
> >>>>>   Forall ( p_unary_pred(a) :- And())
> >>>>>   Forall ( q_unary_pref(b) :- And())
> >>>>>   Forall ( p_individual = q_individual :- And())
> >>>>>
> >>>>> Query: p_unary_pred(?x)
> >>>>>
> >>>>> The translation is straightforward but the form of identifiers
in
> >>> the
> >>>>> target system may not be intuitive.
> >>>>>
> >>>>> A static analyis could omit the identifier renaming for
constants
> >>>>> which are not subject to punning but that leads to a
non-monotonic
> >>>>> translation which is undesirable (at least in the OWL setting).
> >>>>>
> >>>>> ** ONDS to OS
> >>>>>
> >>>>> Same as for ONDS to DS, the translator has to introduce new
> >>>>> identifiers.
> >>>> No, this would not work.
> >>>>
> >>>> Say you have a rule and a fact:
> >>>>
> >>>> Forall x,y (x=y).
> >>>> p(a).
> >>>>
> >>>> Under ONDS, this entails p(a), but not q(a).
> >>>> Under OS, this entails both p(a) and q(a).
> >>>>
> >>>> You can rename your symbols as much as you want, but every symbol
> > will
> >>>> be interpreted as the same symbol.
> >>>>
> >>>> Conclusion: translations from DS and ONDS to OS do not work in
the
> >>>> general case.
> >>>>
> >>>>
> >>>> Best, Jos
> >>>>
> >>>>> ** OS to DS
> >>>>>
> >>>>> Hummm ...
> >>>>>
> >>>>> If we can assume an equality operator for predicates (=pred=)
then
> > I
> >>>>> guess the translation would be something like:
> >>>>>
> >>>>>   Forall ( p_unary_pred(a) :- And())
> >>>>>   Forall ( q_unary_pref(b) :- And())
> >>>>>   Forall ( p_individual =indivdual= q_individual :- And())
> >>>>>   Forall ( p_unary_pred =pred= q_unary_pred)
> >>>>>
> >>>>> Query: p_unary_pred(?x)
> >>>>>
> >>>>> If not then we would have to rewrite all of the rules involving
p
> >>> and q
> >>>>> to introduce the alias syntactically:
> >>>>>
> >>>>>   Forall ( p_unary_pred(a) :- And())
> >>>>>   Forall ( q_unary_pref(a) :- And())
> >>>>>   Forall ( p_unary_pred(b) :- And())
> >>>>>   Forall ( q_unary_pref(b) :- And())
> >>>>>   Forall ( p_individual = q_individual :- And())
> >>>>>
> >>>>> Query: p_unary_pred(?x)
> >>>>>
> >>>>> ** OS to ONDS
> >>>>>
> >>>>> Would be either:
> >>>>>
> >>>>>   Forall ( p(a) :- And())
> >>>>>   Forall ( q(b) :- And())
> >>>>>   Forall ( p =indivdual= q :- And())
> >>>>>   Forall ( p =pred= q :- And())
> >>>>>
> >>>>> Query: p(?x)
> >>>>>
> >>>>> or
> >>>>>
> >>>>>   Forall ( p(a) :- And())
> >>>>>   Forall ( q(a) :- And())
> >>>>>   Forall ( p(b) :- And())
> >>>>>   Forall ( q(b) :- And())
> >>>>>   Forall ( p = q :- And())
> >>>>>
> >>>>> Query: p(?x)
> >>>>>
> >>>>> Dave
> >>>>>
> >>>>> [1] http://www.w3.org/2005/rules/wg/wiki/Issue-31
> >>>>>
> >>>
> >
> >
>

Received on Wednesday, 2 May 2007 12:24:19 UTC