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 19:54:59 UTC