Response to TG1

From RIF
Revision as of 16:03, 25 August 2009 by ChrisWelty (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Tom,

Thanks for the feedback. Regarding your final comment, the existing RIF specification for externals *is* a general and extensible method for attaching procedures, which could be builtins or be defined using existing programming languages. See FLD Section 2.4 item number 8:

[External] terms are used for representing built-in functions and predicates as well as  
"procedurally attached" terms or predicates, which might exist in various rule-based systems, 
but are not specified by RIF. 

DTB is a list of externals that are *required* for interoperability, but does not preclude defining others.

Please acknowledge receipt of this email to <mailto:public-rif-comments@w3.org> (replying to this email should suffice). In your acknowledgment please let us know whether or not you are satisfied with the working group's response to your comment.

-The RIF WG

Tom Gordon wrote:
> The time is ripe for a W3C standard for rules and RIF looks to me to be 
> a very good proposal, building on the experience of previous work on 
> SWRL and RuleML, among other initiatives.   I particularly like its 
> modular structure and its extensibility using FLD.  It remains to be 
> seen whether FLD will be expressive enough for requirements in the legal 
> domain, for defining a dialect capable of modeling legislation in an 
> "isomorphic" way, which is important for both validating and maintaining 
> the models.  In a three year European project, ESTRELLA, which ended in 
> 2008, we developed a rule interchange language for models of 
> legislation, called the Legal Knowledge Interchange Format (LKIF) 
> expressly for this purpose. We may have built LKIF on top of RIF had it 
> been available at the time.  It may be an interesting task to see if 
> LKIF could be reconstructed as a RIF dialect using FLD.
> 
> One nitpick:  RIF, like SWRL before it,  define a bunch of "builtin" 
> predicate and function symbols.   I would have much preferred a more 
> general and extensible method for attaching procedures, defined using 
> existing programming langauges.