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

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). 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...

Paul Vincent
TIBCO | ETG/Business Rules 
 

> -----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 Tuesday, 1 May 2007 20:21:54 UTC