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

Hi Paul,

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

It certainly could be.

Though if most systems are, say ONDS, they have to invent new names to 
separate out the aliases with possible impact on round tripping (unless 
there is metadata or a naming convention to allow aliases to be 
reintroduced).

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

Not sure I understand the question. The equivalent statement in DS was 
my first translation example, viz:

   Forall ( p_unary_pred(a) :- And())
   Forall ( q_unary_pred(b) :- And())
   Forall ( p_individual = q_individual :- And())

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

Ditto. The translation cases were supposed to illustrate what moving 
between ONDS and OS would look like. I think I'm misunderstanding what 
you are asking, sorry.

> 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

I'm not sure that really defers the problem. It means that all 
implementers would need to translate to and from all three styles or 
only do a partial implementation.

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

Typically I assume abstract syntax trees would allow aliases and be ONDS.

You are probably right that it is mostly the logic folks who consider 
OS. If it wasn't for OS that then the choice would be easy - just pick 
ONDS because that is likely to be the majority case and round tripping 
to DS can be made to work if need be. In programming languages then 
aliases are very common and it would be seen as strange not to allow them.

It is the existence of OS systems like Common Logic and RDFS/OWLFull 
which makes the choice non trivial. Though our current direction for RDF 
integration makes the RDFS/OWLFull issues unimportant since it seems 
that RDF Classes and Properties are just going to all be treated as RIF 
individual constants. So I think RIF could be DS without compromising 
its ability to interoperate with RDFS.

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: 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 Friday, 4 May 2007 11:29:56 UTC