Re: RIF Homework for May 2 Telecon

Paula,
thanks for your clarifications. Here are some further comments.

> > 1. Goal
> >     CSF 2
> >       Requirement 2: Component languages follow same paradigms
> >           
> > 	  *** Not clear what is meant here.
> >   
> My idea is to have a uniform framework where a couple of component 
> languages (such as a condition language for the body of deductive rules, 
> an event language for the E part of ECA rules, and an action language 
> for the A part of ECA rules) can be put together for expressing e.g. 
> deductive rules or ECA rules. For gaining uniformity and easing RIF's 
> design and usage, clear language paradigms should be followed for these 
> component languages; which paradigms will be followed is part of the 
> solution to meeting this requirement. An example of such a paradigm is a 
> pattern-based approach to specifying these languages (as followed e.g in 
> Xcerpt and XChange, see http://www.pms.ifi.lmu.de/projekte/xchange); in 
> my opinion, it would be better not to mix languages following such a 
> paradigm with languages that follow a path-based approach to specifying 
> e.g. queris to data (as is the case in XQuery). However, I can imagine 
> that RIF will follow a couple of paradigms, which regard different 
> aspects of language design or use.

Yes, this is a good idea, but it wasn't expressed clearly. It would be good
to come up with a set of building blocks like what you are suggesting.
This is basically similar (I think) to the idea of the semantic/syntactic
taxonomy of languages, but probably you have a different granularity in
mind.

> >     CSF 3
> >       Requirement 3
> >         Desideratum 1: RIF should accept OWL KBs as data
> >
> > 	  *** Not clear what data is meant here. The A-box?
> >   
> I think we should enable the use of the T-box too. However, I'm not an 
> expert on this and I think the best answer would come from Peter, Jos 
> (de Bruijn)  or Jos (De Roo) because they championed this design constraint.

My point was that it is not clear what you meant by "data" and how it is
different from OWL interoperability through a query interface.  One might
interpret this as a requirement of being able to actually incorporate OWL
terms in RIF directly (e.g., to ask if one class subsumes another using OWL
syntax) or as being able to just use a query interface. I think the
requirements must be as unambiguous as possible.


> >      Requirement 6: Type system / Datatype built-in predicates and functions
> >
> >           *** Typing should be optional
> >   
> Is this referring to RIF Core or RIF in general? Note that at moment my 
> hierarchy doesn't make the difference between RIF Core and its 
> extensions, but I agree that such a distinction is needed so as to 
> understand better what is to be done here.

I am not sure I understood your answer/question. I meant that one should
not be required to use typed objects (variables, predicates, functions,
...) in RIF -- only if one feels like it.


> > 2. Goal
> >      CSF 1
> >        Requirement 2: Format for specifying the inference procedure
> > 	     (inference procedure interchange format) that can be applied
> > 	     to a set of rules
> >
> > 	  *** This is very controversial as a requirement. Neither the use
> >               cases nor the intent are particularly clear.
> > 	      (Where exactly in
> >               http://www.w3.org/2005/rules/wg/wiki/Operationally_Equivalent_Translations
> > 	      is it needed that an inference procedure should be
> >               communicated to another engine?)
> > 	      I didn't take part in the previous discussion of this
> >               subject, but I do share skepticism that others expressed
> >               towards this issue.
> >
> >   
> The mentioned use case explicitly states this requirement; it tries to 
> motivate the practical need for preserving operational equivalence 
> (''The MITRE-1 use case scenario attempts to explore the consequences of 
> using the RIF for translation that attempts to preserve operational 
> equivalence.'') However, Requierement 2 refers just to a format for 
> specifying this, Requierement 4 for this CSF is  ''Declarative semantics 
> as must, operational semantics optional'', which was mentioned also at 
> F2F2 in Cannes (e.g. by Francois Bry).

My point was that these use cases mention the need to encode proof
strategies, but they don't support this requirement with actual arguments.
There is no illustration or discussion of why this is needed, and in the
absence of that the requirement looks more like a speculation.

> >       CSF 2
> >         Requirement 1: Definition of default behavior(s)
> >
> > 	  *** Not clear what this means.
> >   
> Sorry for not being clear enough. This requirement refers to rue 
> engines' behavior when encountering certain kinds of unsupported 
> extensions. This is an abstract way of expressing the conformance stated 
> in the charter and the ideas of the design constraint proposed by Christian:
> http://www.w3.org/2005/rules/wg/wiki/RIF_must_define_for_all_RIF_elements_a_default_behaviour_for_compliant_applications_that_do_not_know_how_to_process_it

This is too concrete and probably not doable. We should have a requirement
for being able to express conformance, but this is one place where I would
prefer to be vague. This is because it is not clear how to achieve that, to
what degree this is achievable, and what the mechanism should be.



	regards
	  --michael

Received on Tuesday, 2 May 2006 16:47:05 UTC