Re: RIF vs Rule Language

Stan - I think this is a really great approach for this group, and 
using MathML as a source of inspiration makes great sense because in 
a certain deep sense the languages we're thinking about are 
mathematical notations (and the literature is full of hundreds of 
years of discussion of the relationship between logic and 
mathematics) so looking to mathematics as a "model" sure seems to 
make sense.  I hope as things go on, you can help the WG understand 
the details of how the stuff below worked (process and standard wise) 
so we can appropriately cherry pick the best of that as meets our 
needs.
  -JH


At 4:59 -0500 12/9/05, stan.devitt@agfa.com wrote:
>A similar issue to the one described below surfaced early on in
>MathML.  The detailed evaluation semantics (in general, and as
>implemented by various computer algebra systems) differed
>greatly.  Default domains and domain extensions differed for
>various "standard" mathematical functions and even  basics like
>numerical arithmetic differed between systems.
>
>For some consumers, the differences mattered - for others (like
>editors) they did not. Only the author could say for sure which
>definitions they were using if the details of those definitions
>became important.
>
>The common thread, however was that nearly all mistakes in the
>mathematical information exchange between systems had the
>following  in common.  The consumer made invalid assumptions
>about the mathematical semantics of an object.  Yet, only the
>producer (author) could know for sure what definition they were
>using and when the details were important.
>
>So, we identified three key goals.
>
>         1.  Provide a limite standard vocabulary (including
>         definitions) to facilitate and encourage simple exchange.
>
>         2.  Provide a mechanism for the author to explicitly
>         identify what definition they were using (to be used as
>         necessary) vocabulary in a significant way.  This could
>         be used by authors to "warn" consumers.
>
>         3.  Provide an extension mechanism for both vocabulary
>         and definitions - primarily so that we could actually
>         agree on the contents of the list in 1.
>
>Ultimately we settled on the following approach.
>
>1.  There is a set of standard functions,  e.g.  <sin/>, <cos/>
>that one might expect in a basic mathematical system.  (for
>convenience and for usability so that the common mathematical
>expressions were easily recognizable) and which have default
>definitions.  The only way we could finalize this list was by
>providing an extension mechanism (see 4 below).  In future,
>heavily used extensions might migrate to this list.
>
>2.  Each function has an optional  "definitionURL", which is
>really a URI used to identify a specific variant.   If the
>definitionURL is absent then the definition is the default
>definition (as outlined in the recommendation). However, the
>author can always flag their definition as different. by
>assigning a value to this attribute.
>
>3.  We made a formal distinction between a function, and the
>result of applying it to a set of arguments -- that is, between f
>and f(x).  For example, the "function" sin  lies in a domain of
>functions, while  sin(x) represents (say) a real number.  To
>facilitate this distinction, we provided an "apply" operator that
>could be used to apply any function to its arguments.
>
>4.  We provided a generic function element which used its
>definitionURL attribute to "name" its definition.
>
>This scheme has worked very well.  We have had some feedback that
>a formal system needs to go beyond just naming definitions (all
>that is really possible with an attribute) to inclusion of a
>definition object, but at the time (and even now, we are a long
>way from a conscensus of what that definition language aught to
>look like).
>
>---
>
>All the above is somewhat historical. The really big issues to get
>us to something useful were:
>
>         1.  a basic vocabulary.
>
>         2.  a definition "naming mechanism".
>
>         3.  an extension mechanism.
>
>
>Stan Devitt
>
>
>4.  We provided a generic function element which used its
>required definitionURL attribute to name its definition.
>
>public-rif-wg-request@w3.org wrote on 12/08/2005 06:38:13 PM:
>
>>
>>  On Dec 8, 2005, at 3:27 PM, Uli Sattler wrote:
>>
>>  > On 8 Dec 2005, at 14:49, Enrico Franconi wrote:
>>  >>
>>  >
>>  > [snipp]
>>  >
>>  >> While I believe, like you, that tehre may be the necessity of
>>  >> different behaviours of reasoners, this can only be justified by the
>>  >> existence of different semantics for the same rule constructs.
>>  >>
>>  >
>>  > Do you mean that, for such a case, we should provide 2 different
>>  > syntactic constructs to make this difference explicit? For example
>>  > "implies1" for horn rules without contraposition and "implies2" for
>>  > horn rules with contraposition?
>>
>>  Or you could have a flag for the whole document which one could
>>  override at one's own risk.
>>
>>  Cheers,
>>  Bijan.
>>
>>

-- 
Professor James Hendler			  Director
Joint Institute for Knowledge Discovery	  	  301-405-2696
UMIACS, Univ of Maryland			  301-314-9734 (Fax)
College Park, MD 20742	 		  http://www.cs.umd.edu/~hendler
(New course: http://www.cs.umd.edu/~hendler/CMSC498w/)

Received on Friday, 9 December 2005 13:54:49 UTC