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 10:37:26 UTC