From: Said Tabet (stabet@attbi.com)
Date: 06/03/03
Hi Sandro and All, I am still working on an updated version that I will send tomorrow before the telecon. As explained by Benjamin, let me add that it does make sense to distinguish the 'sensing' class of built-ins from the 'effector' built-ins and control. Control built-ins can be defined by APIs such as Java JSR-94. As pointed out by Gerd in his email, some of the built-ins in the list belong to the Production/Reaction rules family. This brings me to the idea of having a taxonomy of built-ins as discussed in RuleML. In fact, in this case, why not use OWL and DL. OWL can play the role of a Taxonomy Modeling Language for the built-ins (to guarantee consistency and completeness). See my answers to your questions below. Thanks, Said -----Original Message----- From: sandro@roke.hawke.org [mailto:sandro@roke.hawke.org] On Behalf Of Sandro Hawke Sent: Wednesday, May 28, 2003 11:44 AM To: Said Tabet Cc: joint-committee@daml.org Subject: Re: DRAFT: List of Built-ins > As promised, please find, attached, the list of built-ins. This is a > draft, a new version will be available next week with much more details. Understood; feel free to answer my questions in that new version instead of e-mail, if that works better. General question: how do you propose to organize built-ins in terms of input vs. output vs. bi-directional parameters? EG addition and subtraction can be the same predicate: sum(3,4,7) true if 3+4=7 sum(3,4,?x) binds ?x to 7 if unbound sum(3,?y,7) binds ?y to 4 if unbound This is a little odd for addition, but I guess it's common in Prolog for list-append. [Said Tabet] We actually didn't think of it that way. I guess this question was answered by Benjamin in his email. But of course we can discuss this tomorrow. The above example is typical in Prolog but not in forward chaining. > 3. More Built-ins: > ---------------- > 3.1 Assign = What does this mean in a KR language, where it doesn't make sense to talk about changing the value of something? [Said Tabet] This will be defined at a higher level in the hierarchy for Reaction/Production rules family. We can omit it from the early version if everyone agrees. > 3.2 Increment ++ > 3.3 Decrement -- Ditto, unless you just mean +1 and -1. [Said Tabet] yes! > 3.4 Power ** > 3.5 Abs (absolute value) > 3.6 Min > 3.7 Max > > 4. Data Types > -------------- > Our approach is to integrate XML Part 2, Data Types: > http://www.w3.org/TR/xmlschema-2/ What kind of built-ins does that give you? For example, the datatype "duration" [1] represents a length of time via a 6-tuple of <year, month, day, hour, minute, second>. It has an ordering, and the following "constraining facets": * pattern * enumeration * whiteSpace * maxInclusive * maxExclusive * minInclusive * minExclusive So what built-ins does that suggest we should have associated with the xsd:duration type? [Said Tabet] Very good point! Actually, duration is used in many rulebases in deployed systems. You can use it with most of the 'sensor' built-ins. > 5. String built-ins: > ----------------- > 5.1 str-length returns the length of a given string in charact > ers > 5.2 str-cat string concatenation > 5.3 str-compare compares 2 strings > 5.4 str-index returns the position of the first argum > ent within the = > second argument > 5.5 is-String returns TRUE if the argument is a strin > g, FALSE = > otherwise > 5.6 sub-string returns a substring from a string argument give > n two = > 1-based indices > 5.7 str-upcase returns the given string argument in Uppercase > 5.8 str-lowcase retrns the given string argument in lowercase Do you really want hyphens in names? stringLength is probably more in keeping with current naming wisdom. Is isString different from checking to see if it's in the String class? [Said Tabet] Agreed! The changes will be made in the next version. [Said Tabet] isString will be removed as it duplicates what you mentiend. What are strings, btw? Are they XSD strings, RDF plain literals (are those xsd strings?), or something else. [Said Tabet] Very good point. Initial assumption: XSD Strings. Is that an issue? > 6. I/O Streams built-ins: > ----------------------- > 6.1 open Open a file or a stream > 6.2 read Read from stream or file > 6.3 write Write to a stream or file > 6.4 close close file or stream I'd suggest that file handling and URI handling be unified. Opening and reading a file is pretty much the same as GET of an HTTP URI. If the default basename is file: with the current directory, the difference is only noticable on filenames starting with something that looks like a URI scheme name. [Said Tabet] I totally agree, this is the way to handle those and is the standard with current Prog. languages anyway. "write" is of course not a side-effect-free (sensing) operation. [Said Tabet] yes > 6.5 printout sends unformatted output to a given str > eam/router ... this is an enormous can of worms.... What kind of formatting are you suggesting "write" has? [Said Tabet] This could be moved to the 'control' class of built-ins, and take care of your concern. > 7. Control and debugging built-ins: > --------------------------------- > 7.1 run invoke an inference cycle > 7.2 query run a query > 7.3 halt halts an inference/query cycle > 7.4 reset reset the fact base > 7.5 show-facts returns the list of asserted facts > 7.5 show-rules returns the list of rules > 7.8 debug runs in a debug mode: traces all rule firings > 7.9 assert assert new facts > 7.10 retract retract facts > 7.11 load-facts asserts facts loaded from a file > 7.12 load-rules loads rules from a file > 7.13 evaluate evaluates a string input as command lin > e input and = > returns the result > 7.14 clear clear engine from all its contents: rules, fact > s, etc. Most of these are not sensing operations either. I don't know how you expect to fit them into a KR language. Any ideas? [Said Tabet] To be discussed, but the general idea again is what Gerd explained in his email. -- sandro
This archive was generated by hypermail 2.1.4 : 06/03/03 EST