Sweetjess Inferencing in situated courteous ruleml via translation to and from jess rules
Working Paper,version of May2,2003
SweetJess:Inferencing in Situated Courteous RuleML via Translation to and from Jess Rules
Benjamin N.Grosof1,Mahesh D.Gandhe2,and Timothy W.Finin3
1MIT Sloan School of Management,
50Memorial Drive,Cambridge,MA02142,USA
bgrosof@https://www.wendangku.net/doc/45368222.html,
https://www.wendangku.net/doc/45368222.html,/?bgrosof
2IBM,Business Integration Solutions
577,Airport Blvd.,Suite800,CA94410,USA
maheshg@https://www.wendangku.net/doc/45368222.html,
https://www.wendangku.net/doc/45368222.html,/?mgandh1
3Department of Computer Science,
University of Maryland Baltimore County
1000Hilltop Circle,Baltimore MD21250,USA
finin@https://www.wendangku.net/doc/45368222.html,
https://www.wendangku.net/doc/45368222.html,/??nin
Abstract.We describe the innovative design of our prototyped SweetJess tool for RuleML
inferencing.Our?rst contribution is to give a new,implemented translation from a broad
but restricted case of SCLP RuleML into Jess rules,and an inverse translation from a broad
but further restricted case of Jess rules into SCLP RuleML.SCLP stands for the Situated
Courteous Logic Programs knowledge representation;this is expressively powerful and fea-
tures prioritized con?ict handling and procedural attachments.The translation is intended
to preserve semantic equivalence–i.e.,for a given rulebase,to entail the same conclusions.
The translation often preserves semantic equivalence;in current work,we are developing
formal guarantees for the equivalence,including necessary expressive restrictions in each
direction.Our second contribution,building upon the translation,is a new,implemented
architecture to perform(a broad case of)SCLP RuleML inferencing using the Jess rule en-
gine.Our approach translates from SCLP RuleML rules into Jess rules,runs the Jess rule
engine to generate conclusions(and actions),and then translates the concluded Jess facts
back into SCLP RuleML.Our third new contribution is to enable bi-directional implemented
inter-operability,via RuleML,between several other heterogeneous rule systems(e.g.,XSB
Prolog and IBM CommonRules)and Jess.For example,to our knowledge,this is the?rst
tool to enable inter-operability between a Prolog and any“production”/”reactive”rule sys-
tem descended from OPS5heritage.The prototype implementation of SweetJess is publicly
available for Web download.
1Introduction and Overview
The overall problem we address is how to enable inter-operability between heterogeneous rule systems(including relational database systems as an important special case),and between hetero-geneous intelligent applications that make use of such rule systems.Rules are widely deployed today to represent and automate e-business policies and work?ows,for example.Practical advances in such inter-operability would o?er the promise to greatly facilitate program-to-program knowledge sharing and integration,and thereby to stimulate a global virtuous circle of growing value creation in e-business.In short,we seek to realize rule-based business intelligence on the Semantic Web.
In this paper,we describe the design of SweetJess,our new system for inter-operability of rules between RuleML and Jess.RuleML[17]is an emerging industry standard for XML rules that we (?rst author)co-lead,being pursued in informal cooperation with the World Wide Web Consortium (W3C)[22]and the DARPA Agent Markup Language(DAML)Program[4].Rules indeed are part of the announced mission of the W3C’s Semantic Web Activity[18].Jess[11],acronym for“Java
Expert System Shell”,is a popular rule system that is free for academic use and whose source code is relatively easily available.
SweetJess is part of our(?rst author’s)larger toolset system SWEET,acronym for“Semantic WEb Enabling Technology”.SWEET also includes SweetRules[10],a system for RuleML inferenc-ing and translation,and SweetDeal[8][9][15],an approach to rule-based contracting that builds upon SweetRules and RuleML e.g.,to represent deals about Web services.Our previous Sweet-Rules prototype was the?rst to implement SCLP RuleML inferencing and also was the?rst to implement translation of(SCLP)RuleML to and from multiple heterogeneous rule systems.
“SCLP”stands for the Situated Courteous Logic Programs knowledge representation.The SCLP case of RuleML is expressively powerful.The Courteous feature/extension enables prioritized con?ict handling and(a limited form of)classical negation.The Situated feature/extension enables procedural attachments for sensing(testing rule antecedents)and e?ecting(performing actions triggered by conclusions).
SweetRules enables bi-directional translation from SCLP RuleML to:XSB,a Prolog rule sys-tem[23];the IBM CommonRules rule engine,a forward SCLP system[5];Knowledge Interchange Format(KIF)[12],an earlier version of the Common Logic[6]emerging industry standard for knowledge interchange in classical logic;and Smodels,a forward logic-program rule engine.Sweet-Jess aims to complement and extend SweetRules by providing additional capabilities including translation to Jess.
The?rst new contribution of the SweetJess approach is a fundamental mapping.We give a new, implemented translation from a broad but restricted case of SCLP RuleML into Jess rules,and an inverse translation from a broad but further restricted case of Jess rules into SCLP RuleML. The translation is intended to preserve semantic equivalence.Semantic equivalence means that,for a given rulebase,the same conclusions are entailed,and the same side-e?ectful actions(triggered by conclusions)are performed when the rulebase is executed(i.e.,when the rules are“run”). The translation often preserves semantic equivalence;in current work,we are developing formal guarantees for the equivalence,including necessary expressive restrictions in each direction.
The set of expressive restrictions for the translation from SCLP RuleML into Jess includes several that are imposed by the expressive limitations of Jess;notably,these include:
1.Datalog,i.e.,no logical functions;
2.safeness/range-restrictedness of rule heads,i.e.,every logical variable in the head must appear
in(and thus be bound by)the rule body;
3.“all-bound sensors”,i.e.,sensor attached procedures require all their arguments to be bound
(fully instantiated,i.e.,ground)when the sensor procedure is invoked;and
4.safe negation,i.e.,variables in negated body literals must appear in(and thus be bound by)
positive body literals(NB:negation here means negation-as-failure;and
5.dynamically strati?able negation,i.e.,the LP’s model under the Well-Founded Semantics[20]
must not need to assign any literals the truth value unde?ned.
In addition,there are some other limitations of Jess with regard to negation-as-failure that we are investigating in current work.Finally,Jess also lacks some naming capabilities(especially,for facts and rulebases),as compared to(SCLP)RuleML;however,these are less fundamental expressively than the above restrictions.
The above restrictions(1.),(2.),(4.),and(5.)are often found in rule-based systems—especially ones that do forward-direction inferencing.Restriction(3.),all-bound sensors,is more unusual and is practically rather limiting—it restricts a sensor attached procedure when queried to answer with simply a boolean,as opposed to a set of bindings.Overall,these restrictions underline some dimensions of the powerful expressive generality of SCLP as a KR.We will discuss the translation’s expressive restrictions in more detail later.
The second new contribution of the SweetJess approach builds upon the translation.We give a new,implemented architecture to perform(a broad case of)SCLP RuleML inferencing using the Jess rule engine.Our approach translates from SCLP RuleML rules into Jess rules,runs the Jess rule engine to generate conclusions(and actions),and then translates the concluded Jess facts back into SCLP RuleML.
Translating the Courteous feature of SCLP RuleML,i.e.,its prioritized con?ict handling and classical-negation aspects,is a particular hurdle,since Jess essentially lacks the ability to directly
express these aspects.(Jess does include a quite limited kind of inferencing-control-agenda prioriti-zation—“salience”—which is a discouraged mechanism.)Our approach is able to surmount this hurdle however,by utilizing a Courteous Compiler component.The Courteous Compiler“compiles away”the courteous aspect of an input rulebase,transforming it into a semantically equivalent rulebase that does not contain the Courteous expressive features(priorities and mutual exclusion integrity constraints),but rather that only employs negation-as-failure(NAF).The IBM Common-Rules library provides a Courteous Compiler,for example.
The third new contribution of the SweetJess approach is to enable bi-directional implemented inter-operability,via RuleML as an interlingua,between Jess and multiple other heterogeneous rule systems,including Prologs and relational database systems for which translation to RuleML has already been shown,and for which there are existing translation tools(e.g.,in SweetRules and our other earlier work[8]).In particular,as we discussed earlier,SweetRules already enables bi-directional translation from SCLP RuleML to:XSB;Smodels;IBM CommonRules;and KIF. The overall approach to such translation was?rst given by us in[8].The RuleML website lists additional translation tools as well.For a given rule system such as Jess,the software engineering e?ort of speci?cation,design and implementation of translation to multiple other rule systems is greatly eased by use of a single intermediate interlingua,i.e.,the emerging RuleML standard.
Jess is a representative member of one group of currently commercially important(CCI)rule systems:namely,production rule systems descended from OPS5[3],which in turn are closely re-lated to event-condition-action(ECA)rule systems[19].These systems primarily employ forward chaining(rather than backward),and their applications heavily rely on their capabilities for pro-cedural attachments.This group is sometimes called“reactive”for short;often,rules are run in response to the arrival of knowledge-base updates consisting of facts(or“events”).Another quite distinct group of CCI rule systems is comprised of Prolog systems[2],together with SQL-type rela-tional database systems(RDB)[19].The core of SQL RDB’s—relational algebra and Datalog—is well-known theoretically to be very closely related to pure Prolog.Systems in this second group (sometimes called“derivational”)primarily employ backward chaining(rather than forward),i.e., query-answering.
The fourth new contribution of the SweetJess approach is a bridging across heterogeneous families of CCI rule systems.Our translation and tool are each the?rst,to our knowledge,to enable inter-operability between a Prolog and any“production”/”reactive”rule system descended from OPS5heritage.More generally,our translation may be the?rst to go for a broad expressive case between the two groups(production/reactive vs.Prolog/SQL derivational).
The?fth new contribution of our translation e?ort is to compare the expressive capabilities of each rule system and its underlying fundamental knowledge representation,and in particular to bring out several limitations of Jess relative to SCLP RuleML.We discussed the most important of these above.
In continuing the overall SweetRules approach by laying these new foundations for inter-operability,the SweetJess approach thereby moves a discernible step closer to the Semantic Web’s vision of wide knowledge sharing and integration among intelligent applications,e.g.,where rules are already often deployed for e-business policies and work?ow,and SQL RDB’s are ubiquitous.
The prototype implementation of SweetJess is and publicly available free on the Web4.It is implemented in Java and makes use of tools for XML,RDF[16]and RuleML.
The remainder of this paper is organized as follows.Section2provides background:we review RuleML,Situated LP,and Courteous LP.In section3,we review Jess Rules and begin the analysis and reformulation that underlies our translation mappings.In section4,we describe SweetJess’architecture to perform(a broad case of)SCLP RuleML inferencing using the Jess rule engine. In section5,we come to the heart of the matter:we describe how to translate rules from SCLP RuleML to Jess.In section6,we describe how to translate back from Jess to SCLP RuleML.In section7,we wind up with some discussion,including additional directions for future work.
4https://www.wendangku.net/doc/45368222.html,/sweetjess
2Background:RuleML,Situated LP,Courteous LP
2.1RuleML and LP
RuleML[17]is the leading emerging industry standard for XML-based inter-operable rules,i.e., Semantic Web rules.It is being developed by a coalition which includes participants from several dozen institutions,both academic and industrial.We(?rst author)co-lead it.The speci?cation of RuleML includes an XML markup syntax,together with a formal semantics based on the knowledge representation(KR)of Logic Programs(LP)5.In adddition,there already exist early draft speci?-cations of an abstract syntax,an alternative RDF syntax,and an OWL syntax.RuleML is intended primarily to support inter-operability among currently commercially important kinds(CCI)of rule systems.These CCI rule systems fall primarily into four major families today:relational database management systems(SQL),Prolog,OPS5-heritage production rules,and Event-Condition-Action (ECA)systems.The RuleML language actually provides a range of options for the fundamental KR expressiveness to be used in inter-operating between a group of two or more rule systems.For-mally,RuleML organizes these options into a set of“sub-languages”.Each sub-language provides a di?erent combination of expressive features/expressive restrictions,and has associated syntax. The set of sub-languages is thus hierarchical,in that a given sub-language may provide a superset of(i.e.,subsume)the expressiveness of a particular other sub-language.
In the LP literature,the most studied LP expressive class is what we will call“Ordinary”LP (OLP).OLP extends Horn LP by permitting body literals to be negated;its form of negation is negation-as-failure(NAF).Courteous LP subsumes OLP.OLP is also sometimes called“normal logic programs”(or“general[sic]logic programs”as in[1]).OLP is roughly pure Prolog without built-ins,but not limited to backward direction of inferencing.
Currently de?ned RuleML sub-languages also include:
1.Datalog Horn LP(no negation,no logical functions)
2.Horn LP(adds logical functions(of non-zero arity);no negation;subsumes Datalog Horn)
3.Situated Courteous LP(adds procedural attachments for sensing/e?ecting,and prioritized
con?ict handling;subsumes OLP and Horn)
and several others that provide combinations of various additional syntactic or expressive fea-tures/restrictions.
Note that Ordinary LP and Horn LP are“pure-belief”KR’s—i.e.,they lack procedural at-tachments.Most KR theory,generally,treats pure-belief formalisms.
RuleML’s sub-languages di?er from the formulation of LP expressive classes in the KR literature primarily in that RuleML provides a standardized set of mechanisms for syntax and for Webizing the KR.Besides providing XML6syntactic schemas,an important aspect of these mechanisms is to provide additional capabilities for naming,notably to permit predicates,individuals,and logical functions(“constructors”)to be URI’s,and to permit rule names and rulebase names to be part of the KR language.These naming capabilities facilitate highly distributed knowledge bases and inferencing for rules and their use of ontologies and databases—in short,they largely equip rule KR for the Semantic Web.In particular,permitting a predicate name to be a URI that refers to an OWL class or property enables RuleML rules to be“on top of”OWL ontologies(e.g.,see[9] for the?rst detailed application scenario that used this capability).
RuleML has been evolving since its?rst version XML DTD’s(V0.7)were released in early2001. The current version(V0.8)includes additional extensions in expressive and syntactic features,and a few moderate revisions in the syntax.Our SweetJess design and implementation e?ort was started while V0.8was still in development,and thus used the same version of the SCLP RuleML XML DTD as the?rst(still current)version of SweetRules[10].This DTD(known as“SCLP dtd-v13”) di?ers in a few minor ways with RuleML V0.8.In current work,we are updating the implementation to achieve full compliance with the RuleML V0.8SCLP DTD7.
The current SweetJess translation mappings and implementation incorporates all the features of the RuleML V0.8SCLP DTD with one important exception:the object-oriented argument col-lections feature(“roli’s”),which provides additional syntactic convenience(rather than increasing 5see[1]for a helpful review of LP KR
6and early drafts of RDF and OWL
7https://www.wendangku.net/doc/45368222.html,/dtd/0.8/ruleml-sclp-monolith.dtd
fundamental expressive power from a logical KR standpoint).The collection of arguments in a log-ical atom is thus,for now,simply an ordered tuple(in the current SweetJess translation mappings and implementation).Such an atom when ground is called an“ordered fact”in Jess.In current work,we are designing an extension of the SweetJess translation mappings and implementation to support the object-oriented argument collections feature as well.
Next,we give examples of a Fact and a Rule in RuleML V0.8syntax.
Example1.Premium Customer Fact,in RuleML A RuleML fact(“fact”element in the XML syntax)expresses a ground atom.It is a kind of statement.E.g.:
/*Fact:‘‘Allan is a premium customer.’’*/
premiumCustomer(Allan)
In RuleML syntax:
<_head>
<_opr>
Example2.Discounting Rule,in RuleML A RuleML implication rule(“imp”element in the XML syntax)expresses an if-then rule(a.k.a.a“clause”in the LP KR literature).It is a kind of statement.An implication rule is a pure-belief rule that does not directly specify any procedural attachments for sensing or e?ecting.E.g.,
/*Rule:‘‘If a customer is a premium customer then give him a10%discount.’’if premiumCustomer(?customer)
then giveDiscount(percent10,?customer)
For ease of human-readability,in this paper we often give our LP and RuleML examples(e.g., the ones above)in the Prolog-like“SCLP?le”syntax of IBM CommonRules V3.0[5],which maps straightforwardly to RuleML.“;”ends a rule statement.The pre?x“?”indicates a logical variable.“/*...*/”encloses a comment.“//”pre?xes a comment line.“<...>”encloses a rule label (name).Rule labels identify rules for editing and prioritized con?ict handling,for example to facilitate the modular modi?cation of contract provisions.
In RuleML syntax:
<_head>
<_opr>
Customer
<_body>
<_opr>
customer
For sake of brevity,especially in human authoring and reading,the XML syntax for RuleML uses terse/abbreviated names for the elements(and attributes).“rel”means relation,i.e.,predicate.“ind”means individual(object constant).“var”means logical variable.“body”and“head”mean the antecedent(a.k.a.“if”part)and the consequent(a.k.a.“then”part)of a rule,respectively.“opr”stands for relational operator.
Note that a fact is similar syntactically to an(implication)rule that lacks a body.Conceptually, an empty body is viewed as logically True,as is usual in LP and classical logic.
Terminology:From a LP KR viewpoint,a fact is just a special case of a rule.A RuleML rulebase consisting of implication and fact statements is thus often simply called a“rulebase”or“ruleset”. More generally,however,the Situated and Courteous features of SCLP extend the LP KR with three additional kinds of statements:sensor,e?ector,and mutex;we will be discussing those in more detail later.A collection of such SCLP statements(all?ve kinds)constitutes a RuleML rulebase in the more general sense.
2.2Situated Logic Programs
The Situated extension of(Courteous or Ordinary)Logic Programs allows actions and queries to be performed by procedural attachments.SLP uses e?ector and sensor statements to specify these, as in the following example.
Example3.Order Cancellation with Noti?cation Action
/*rule:should notify customer if order cancellation request was received in time to be accepted*/
and receivedBefore(cancelRequest4216,?Day)
then shouldInformCustomer(cancelRequest4216,accepted);
/*effector statement:associated with the predicate shouldInformCustomer,the ack method performs a notification action*/
Effector:shouldInformCustomer/*the predicate*/
Class:orderMgmt.Request.mods
Method:ack
Path:‘‘edu.cs.umbc.SLP.examples.orderMgmt.aprocs’’;
/*sensor statement:associated with the predicate receivedBefore,the earlierReceiptDate method queries an external order management system*/
Sensor:receivedBefore/*the predicate*/
Class:orderMgmt.Request
Method:earlierReceiptDate
Path:‘‘edu.cs.umbc.SLP.examples.orderMgmt.aprocs’’;
BindingRequirement:(BOUND,BOUND)
The e?ector statements in a SLP each associate a pure-belief predicate,e.g.,shouldInform-Customer,with an external attached procedure,e.g.,orderMgmt.request.mods.ack(here,a Java method).During rule inferencing(more precisely,during rule execution),when a conclusion is drawn about the predicate,e.g.,“shouldInformCustomer(cancelRequest4216,accepted)”if the rule above was?red successfully,then the external procedure is invoked as a side-e?ectful action,e.g., the method“ack”is called with its parameters instantiated to“(request1049,accepted)”.“Exter-nal”here means external to the inferencing engine itself.An(external)attached procedure is also called an“aproc”for short.
The sensor statements in a SLP each associate a pure-belief predicate,e.g.,receivedBefore,with an external attached procedure,e.g.,orderMgmt.request.earlierReceiptDate(again,here the aproc is a Java method).During rule inferencing/execution,when a rule antecedent condition(i.e.,a literal in the rule’s“if”part)is tested,e.g.,“receivedBefore(cancelRequest4216,?Day)”in the rule above,then the external procedure is queried to provide information about that condition’s truth. More precisely,the aproc is queried for its answer bindings since the condition may contain logical variables.A sensor aproc may require that some or all of its arguments must be bound(i.e.,fully instantiated)at the time that aproc is invoked.A sensor statement thus includes a binding pattern that speci?es such requirements.Such binding requirements are quite common in practice.
For example,consider an external procedure myCompany.BluePages.getPhoneNumber,pro-vided by a company phone directory application,that has two arguments,where the?rst is a
person name and the second is a phone number.It has an associated binding pattern that requires the?rst argument to be bound but permits the second argument to be unbound.When invoked with the?rst argument bound to“Fred.Green”and the second argument a free variable(“?X”),it returns the binding“617-555-9876”for that variable.In the example above,the sensor aproc order-Mgmt.Request.earlierReceiptDate requires both of its arguments to be bound when it is invoked. Some sensor statements,e.g.,for the predicate lessThanOrEqual,correspond to what in Prolog (or many other commercial rule systems)are“built-ins”,utility procedures provided as a standard package with the rule system rather than provided by a particular individual user/application.
Terminology:a predicate which has one or more associated sensor(e?ector)statements is called a“sensor predicate”(“e?ector predicate”).A literal in a sensor(e?ector)predicate is called a“sen-sor literal”(“e?ector literal”).Overall,we call the process of drawing conclusions and performing related e?ector and sensor invocations in SLP:“situated inferencing”.
Sensing about a given predicate p occurs in addition to any facts derivable from rules(or facts) whose heads are p atoms.Also,a given predicate p may appear in multiple sensor statements, i.e.,p may have multiple sensor aproc’s.The results from querying all of these sensor aproc’s are combined(i.e.,union’d)when a rules body’s sensor literal in p is tested.
Likewise,a given predicate p may appear in multiple e?ector statements,i.e.,p may have multiple e?ector aproc’s.When a conclusion is drawn about p,each of these e?ector aproc’s is invoked.
2.3Courteous Logic Programs:Review
Courteous Logic Programs(CLP)is an expressive super-class of Ordinary Logic Programs(OLP). The Courteous expressive extension enables prioritized con?ict handling and also a limited form of classical negation.Next,we give an example of a CLP,having2rules,1fact,and1mutex. Example4.Prioritized Discounting Rules
/*if the Customer has a Loyal Spending History then give him a5%Discount*/
IF shopper(?Cust)and spendingHistory(?Cust,loyal)
THEN giveDiscount(percent5,?Cust);
/*if the Customer was Slow to Pay last year then give him a0%(NO)Discount*/
IF slowToPay(?Cust,last1year)
THEN giveDiscount(percent0,?Cust);
/*prioritization fact:SlowPayer is higher priority than SteadySpender*/ overrides(slowPayer,steadySpender);
/*the amount of the Discount given to a customer is Unique*/
MUTEX giveDiscount(?X,?Cust)and giveDiscount(?Y,?Cust)
GIVEN notEquals(?X,?Y);
Each rule has an optional rule label.This is used as a handle for specifying prioritization information.Each label is a logical term,e.g.,an individual constant.The“overrides”predicate is used to specify prioritization.“overrides(lab1,lab2)”means that any rule having label“lab1”is higher priority than any other rule having label“lab2”.“overrides”is syntactically reserved,but otherwise is treated as an ordinary predicate.In particular,“overrides”can itself be the subject of inferencing.The scope of what is con?ict is speci?ed by“mutex”statements.A mutex speci?es a (conditional)pair-wise mutual exclusion between two literals;these are called the“opposer”literals of the mutex.The mutex statement also includes a condition,called its“given”part.The mutex given part is similar to the body of a rule;it may be empty(i.e.,T rue).E.g.,the mutex above speci?es that it is a contradiction to conclude two di?erent values of the percentage discount for the same customer;i.e.,giveDiscount is a(partial-)functional predicate.The semantics of Courteous LP enforces consistency of the conclusions wrt each mutex.
Any literal may be classically negated;however,(C)LP as a KR only supports a quite limited form of classical negation(a.k.a.“strong”negation).There is an implicit mutex between p and classical-negation-of-p,for each p,where p is a predicate,ground atom,or atom.These implicit mutex’s are called“classical-negation”mutex’s.
The semantics of Courteous LP ensures overall consistency of the conclusion set,including consistency between the two concepts of negation(classical negation of p entails NAF of p,but not vice versa).
Combining Courteous+Situated→SCLP:The Courteous expressive extension can be combined with the Situated expressive extension,to form Situated Courteous LP.Currently in the theory of Situated Courteous LP,however,there is an expressive restriction on this combination: the sensor predicates must be con?ict-free.More precisely,the restriction on the SCLP rulebase is that:no mutex opposer literal may be a sensor literal.This includes the implicit classical-negation mutex’s,thus no sensor literal may be classically-negated.We call this restriction“con?ict-free sensing”or“monotonic sensor predicates”,for short.In current work,we are generalizing the theory of SCLP to remove this restriction.
3Jess Rules:Overview,Analysis,and Reformulation
3.1Jess Facts
Conceptually,what Jess calls a“fact”is very similar to the concept of a fact in RuleML;it expresses a ground atom.Jess provides some machinery for de?ning facts and acquiring them from surrounding Java context,with which we will not need to concern ourselves in this paper.We will concern ourselves simply with the basic concept of a Jess fact—speci?cally,what Jess calls an “ordered”fact,i.e.,one where the fact’s arguments constitute an ordered tuple.Jess also provides as a syntactic enhancement the concept of an“unordered”fact,which uses slot names(rather than sequence)to de?ne arguments within a fact(or atomic pattern);this is quite similar to the object-oriented argument collections feature of RuleML V0.8,which we mentioned earlier.The current SweetJess translation mappings and implementation just deal with Jess“ordered”facts,however.
Jess uses a Lisp-like syntax,generally.A Jess fact statement has the following kind of form(we can view this roughly as a generic template):
(assert(predicateName constant1constant2...constantN))
The statement begins with the‘‘assert”keyword.This is followed by an expression syntactically similar to an LP ground atom:a predicate followed by an ordered collection of individual constants. Di?erent predicates have di?erent arities;we indicated this in the form above by writing“N”as the arity.Actually,in Jess,“assert”is a system procedure(what Jess calls a“function”);when executed it puts the fact into the currently active stored knowledge base of the Jess inferencing engine.Note that,in the tradition of OPS5-heritage production rule systems,Jess does not con-ceptually view a Jess fact as a special case of a Jess rule.However,in our translation mapping,we will essentially view a Jess fact as a special case of a LP rule,from the viewpoint of KR theory.
Jess lacks the semantic equivalent of logical functions,i.e.,constructors,that have non-zero arity.It thus also lacks the semantic equivalent of complex terms formed using constructors.This is known in LP and classical logic KR as the Datalog restriction.The closest thing in Jess to a non-zero-arity constructor is a JessMethod procedure(see next sub-section),but that is always evaluated on its arguments;the semantics of a non-zero-arity constructor,however,essentially correspond to not evaluating it.
3.2Jess Rules
A Jess rule has the following kind of syntactic form(we can view this very roughly as a generic template):
(defrule ruleName
(predicate1constant1?boundVariable1)
(test(jMethod1constant2?boundVariable1))
=>
(jMethod2(symbol3?boundVariable1)))
A Jess rule de?nition begins with the“defrule”keyword followed by a rule name,and has two further parts,an“if”part on its left hand side(LHS)and a“then”part on its right hand side (RHS),separated by the“=>”symbol which roughly means implication.The LHS of a Jess rule is a“pattern”in Jess terminology.A basic“pattern”matches facts and corresponds to an atom in
a LP rule body.E.g.,the second line in the example form above is a basic pattern.This atom may include logical variables,not just individual constants,as arguments.More complex patterns can be formed in several ways.The LHS may consist of a(top-level)list of basic patterns;these are interpreted(implicitly)as a conjunction.
The basic form of a Jess rule’s RHS is an“action”in Jess terminology.An action is simply a call to one of Jess’Java procedures.We will call these procedures“JessMethods”.(Jess calls them“functions”,but we wish to reserve“function”for logical functions cf.LP and classical logic KR terminology.)Syntactically,a JessMethod call is simply a Lisp-like list whose?rst member is the name of a JessMethod,followed by arguments.Each such argument may be a constant, logical variable,or another JessMethod procedure call expression.E.g.,the last line in the template example above is an action.“Jess comes with a large number of built-in[JessMethods]that do everything from math,program control and string manipulations,to giving you access to Java APIs.”,says the User Manual8.In addition,a user may de?ne their own additional JessMethods, which are essentially general Java procedures(methods);in practice,this capability is often used heavily.In general,an action may essentially arbitrarily modify program state,and is a way to do pretty much anything you can do in Java.
From the standpoint of KR and for designing our translation mappings,however,one Jess-Method is particularly germane:“assert”.A common kind of action in Jess rules is to assert a fact.In this case,the Jess rule RHS corresponds to the head atom of a(pure-belief)implication rule in LP KR,and thus in RuleML.When the Jess rule inferencing engine runs,if the rule LHS is satis?ed(“matches”in Jess terminology),i.e.,if the rule?res(with variable bindings supplied as in the usual manner for rules),then this RHS fact is added to the working fact set portion of Jess’knowledge base.From the standpoint of LP KR,this corresponds to drawing a conclusion. More generally,the RHS may consist of a(top-level)list of actions.If these are assert’s,the list is interpreted(implicitly)as a conjunction of its member actions.
The result of the RHS when a rule?res thus may be either(1)to draw a conclusion fact(or several facts),or(2)to perform some(general)procedural action(s)that may be—and typically, are–side-e?ectful.From the standpoint of Situated LP KR,expressively,case(2)corresponds essentially to generating an e?ector call to a JessMethod.(A complex RHS can be rewritten as a call to a single JessMethod.)
In addition to basic patterns that correspond to LP atoms,there is one other fundamental kind of(pattern)expression can appear in the LHS of a Jess rule:a“TEST Conditional Element”in Jess terminology,called“TestCE”for short.910A TestCE is constructed syntactically using the reserved keyword“test”followed by a JessMethod call expression(as in the third line of the template example above).When the rule runs,the TestCE tests whether that JessMethod call expression(when supplied with variable bindings by matching the rest of the LHS)evaluates to True(vs.False).From the standpoint of Situated LP KR,this essentially corresponds to a sensor call.When the JessMethod call is invoked,all the arguments of the JessMethod must be fully bound.This is signi?cantly less(expressively)general than the concept of a sensor call in Situated LP,where some or all of the arguments may be(or contain)free variables.We call this the all-bound sensors expressive restriction.
Jess also has explicit logical connectives.The?rst is“not”,which is negation-as-failure.“(not BP),where BP is a basic pattern,is similar to a negation-as-failure literal in LP.More complex patterns can be built up by explicit use of logical connectives;these include not,and,or,exists, and can be nested.This provides enhanced expressiveness in a direction very similar to(but somewhat less general than)“Lloyd-Topor”LP.“Lloyd-Topor”LP is the extension of OLP to use the Lloyd-Topor transformation[13].The Lloyd-Topor transformation does not increase the fundamental expressiveness of OLP,however;it reduces its more expressive version of LP into OLP. In that sense,it can be viewed as syntactic sugar.
8Jess V6.1,section2.2
9In addition,Jess permits“predicate constraints”and“return value constraints”to be associated with LHS variables,but these do not provide any extra essential expressiveness;they are reducible to TestCE’s plus the other permitted LHS pattern constructs.
10Note that a LHS rule pattern may not contain a top-level JessMethod appearance,only t est.
Jess requires that all logical variables appearing in the RHS be bound by matching in the LHS.
I.e.,all RHS variables must appear in the LHS.This is known in LP and classical logic KR as range-restrictedness and as the safe-head expressive restriction.Jess also requires that:all logical variables appearing in a basic pattern(or more complex expression)that is negated(by“not”), must be bound by matching(on non-negated patterns)in the rest of the LHS.11This is known in LP and classical logic KR as the safe negation expressive restriction.Safe-head and safe-negation are frequent restrictions in practical rule-based inferencing systems,and are especially common in forward-direction inferencing systems.
Jess Rule Engine:Above,we have described a Jess rule and a Jess fact,taken one a time. Overall,the KR semantics of a set of Jess rules and facts must be related to what the Jess engine does—what conclusions are drawn and what procedural actions are performed—not just to what is the conceptual intention of a rule or fact.From a KR viewpoint,the Jess engine is similar to the engines of several other OPS5-heritage production rule systems.It uses the Rete(Latin for“net”) algorithm[7]for e?ciency in“pattern”matching,especially to handle updates to its working set of facts.
In current work,we are developing more formal theory to characterize the production-rule Rete engine algorithm in terms of the LP KR.
4SweetJess’Overall Architecture for Inferencing and Translation
Fig.1.SweetJess Architecture for RuleML Inferencing via Jess The bi-directional translation between RuleML and Jess has several potential uses,as discussed in section1.By way of motivation for the details in the rest of this paper,however,we largely
11Jess also allows local existentially-quanti?ed variables within a negated expression,but this is expressively inessential.
focus on one particular use:to perform RuleML inferencing via Jess.Figure1shows SweetJess’architecture for this.By“RuleML inferencing”,we mean(situated)inferencing from a premise RuleML rulebase(“Knowledge Base of rules and facts”in the Figure)to derive RuleML conclusions and related procedural actions that are triggered from those conclusions via procedural attachments (“e?ectors”in Situated LP,described in section2.2).By“via Jess”,we mean that Jess is used as an engine to“run”the rules.
To perform such inferencing,SweetJess?rst translates a premise RuleML rulebase into a set of Jess rules and facts(and JessMethod de?nitions).This transformation is called trans[RJ].Infer-encing is then performed using Jess’rule inference engine,i.e.,the rules are“run”.This generates a set of derived conclusions(facts)in the Jess representation.Then these facts are transformed by a SweetJess translator component into a set of RuleML facts.This inverse direction transformation is called trans[JR].The result is a set of RuleML conclusion facts entailed by the original RuleML premise rulebase.
When the rules are run in the Jess engine,a set of actions,triggered by conclusions,is also performed.These actions are invocations of attached procedures,i.e.,side-e?ectful calls to Java methods.These actions are those sanctioned by the Situated(“e?ecting”)aspect of the semantics of the premise RuleML rulebase.The transformations trans[RJ]and trans[JR]impose some expressive restrictions on their input,which we will describe later.For the results of inferencing,only facts need be translated via trans[JR]from Jess to RuleML.Our trans[JR]translation,more generally, actually handles(as input)Jess rules too,not just Jess facts.The current implementation of trans[JR],however,restricts these input Jess rules to be pure-belief rules,i.e.,without JessMethods (other than assert),and to be in similar syntactic form to what trans[RJ]produces.In current work,we have been extending the design of trans[JR]to relax these restrictions.
5Transforming RuleML To Jess:trans[RJ]
There are several major challenging aspects of designing the translation mappings between RuleML and Jess.One aspect is to map conceptually between the terminologies and,more deeply,the concepts of the two di?erent rule languages.We described much of that conceptual mapping earlier in sections3and4.A second aspect is to handle procedural attachments for tests/sensing and actions/e?ecting.A third aspect is to handle prioritized con?ict handling.A fourth aspect is to identify the appropriate expressive restrictions in doing all of the above.
Next,we describe in more detail the various aspects of trans[RJ].The topics of the following sub-sections are sequenced roughly in the sequence of increasing expressiveness:from facts to Horn LP to OLP to Situated OLP to Situated Courteous LP.As we go,we sometimes need to distinguish the translation mapping(which is at the level of design)from the current implementation of SweetJess.
5.1Overall Input and Output
The transformation trans[RJ]takes as input a RuleML rulebase—an XML document which we will call a.rml?le.The output of this transformation is a Jess knowledge base—i.e.,a.jess batch ?le.This batch?le contains facts and rules which can be directly fed to a Jess Rete engine.The batch?le begins with the Jess system command“(reset)”,which when executed clears out the knowledge base and resets the engine.The batch?le ends with the Jess system command“(run)”, which when executed starts up inferencing.The current version of Jess is V6.1.The current version of RuleML is V0.8.As we discussed earlier in section1,the current SweetJess implementation still uses a slightly earlier version of the XML DTD for SCLP RuleML.
5.2Fact
A basic RuleML fact—an atom whose arguments are an ordered tuple of individuals and/or variables—translates straightforwardly into a Jess fact.
Example5.Premium Customer Fact,in Jess:The equivalent Jess fact corresponding to the RuleML fact in Example1is as follows:
(assert(premiumCustomer Allan))
URI constant names feature:An important Webizing feature of RuleML is“URI constant names”:predicate or individual(or other)constant names can be be URI’s.A very basic way to translate these in trans[RJ]is simply to treat them as strings;however,then they are not recognized as being URI’s by Jess.Translating them round-trip from RuleML to Jess back to RuleML in such a way as to preserve the ability to recognize URI-ness upon the return to RuleML,is relatively straightforward to support in trans[RJ]and trans[JR],e.g.,via a pre?xing/encoding convention. Our translation mapping design thus includes URI constant names,but the current implementation does not yet support this feature.
Rule naming issues:In RuleML,a fact has an optional rule label(name).A fact in Jess has a unique Fact-Id which is generated by the system upon loading,and is only accessible to the system rather than being explicit in its Jess representation.The RuleML fact’s rule label,if present,is thus lost by the transformation.Thus formally,there is an expressive restriction on the transformation:“no fact labels”.(An alternative design to relax this restriction would be to translate a RuleML fact into a Jess rule that has a trivially true body,then the rule label could be preserved.But this would probably have some other disadvantages,e.g.,less e?ciency.)
Object-oriented argument collections:The current design of the translation mapping also does not yet support the object-oriented argument collections feature of RuleML V0.8.That recently-added feature,as yet experimental in status,provides syntactic and conceptual convenience but does not add fundamental expressiveness from a KR standpoint.We will call this restriction the “tuple-arguments”expressive restriction.
Expressive restrictions imposed on the rulebase:Datalog,no fact labels,tuple-arguments.
Expressive features enabled for rulebase:URI constant names.
5.3Horn Rule
A RuleML Horn LP implication rule(i.e.,imp statement)is translated into a Jess rule whose LHS corresponds to the RuleML body,and whose RHS corresponds to the RuleML head.Each RuleML body atom is translated into a corresponding basic pattern.The RuleML head atom is translated into an assert of the corresponding basic pattern.The RuleML rule label,if present,is translated into the Jess rule name,else a new rule name is automatically generated.
Example6.Discount Rule,in Jess After transforming the RuleML rule given in Example2 (sub-section2.1),the corresponding Jess rule is:
(defrule discountRule
(premiumCustomer?customer)
=>
(assert(giveDiscount percent10?customer)))
A further subtlety arises when translating rulebases that contain sensor statements.The sensor statements modify how a rule mentioning a sensor predicate is translated so as also to generate TestCE patterns in place of basic patterns;see sub-section5.6below for details.
Naming Issues:A RuleML rule label(name)is optional and need not be unique.Jess requires a name for every rule,w hich moreover must be unique(if not,the last-loaded with that name blows away any previously-loaded rule with the same name).For the time being,we thus expressively restrict the input RuleML rules’labels not to coincide with each other.We call this the unique rule labels expressive restriction.
Expressive restrictions imposed on the rulebase:unique rule labels,safe head.Note also that the Datalog restriction applies to the LP rule labels,thus each rule label must be simply an individual constant.
Expressive features enabled for the rulebase:Horn LP.
5.4Lloyd-Topor And-Or(LTAO)Expressiveness
The“Lloyd-Topor And-Or(LTAO)”permits:(1)conjunction(of literals)to appear in a rule head;and(2)disjunction to appear in a rule body,even nested with conjunction to form AND-OR expressions formed from literals.This is a portion of the Lloyd-Topor transformation:a rule
a∧b←c can be rewritten as two rules a←c and b←c;and a rule a←(b∨c)can be rewritten as two rules a←b and a←c.
trans[RJ]supports the LTAO expressive feature.LTAO is convenient but expressively inessen-tial.The SCLP RuleML V0.8sub-language includes LTAO;many practical rule-based systems support it.LTAO can be added(inessentially)to Horn LP or any of its expressive super-classes (e.g.,OLP).
An advantage of this LTAO feature is conciseness and naturalness in authoring of rules.The LTAO feature is straightforward to implement.
Expressive features enabled for the rulebase:Lloyd-Topor And-Or(LTAO).
5.5Negation-as-Failure(NAF)
Negation-as-failure(NAF)in OLP and SCLP RuleML is translated into Jess negation(“not”), which also is NAF.
NAF in OLP(and thus in SCLP),and in rule systems generally,is somewhat tricky in the fully general case,both to de?ne semantically and to implement.As is well-known in the OLP literature,NAF can cause semantic trouble by interacting with cyclic dependencies(“recursion”) among rules.A full discussion of the subtleties of NAF is beyond the scope/space of this paper. But we do impose the following restriction:dynamically strati?able negation,i.e.,the(O)LP’s model under the Well-Founded Semantics[20]must not need to assign any literals the truth value unde?ned.(Note that NAF-free is a special case of dynamically strati?able.)
In addition,there are some other limitations of Jess with regard to negation-as-failure that we are investigating in current work.
Expressive restrictions imposed on the rulebase:safe negation,dynamically strati?able negation.
Expressive features enabled for the rulebase:Negation-As-Failure(NAF),thus OLP.
5.6Situated LP Procedural Attachments for Sensing and E?ecting
Next,we describe how sensor and e?ector statements,in the Situated feature of RuleML,are translated.
An e?ector statement associating a predicate p with an attached procedure q,is translated into two Jess statements.(1)The?rst is a Jess rule whose LHS is an open atom in the predicate p and whose RHS is a JessMethod that invokes the aproc q.Here,“Open”atom means that all of the atom’s arguments are(free)logical variables.(2)The second is a JessMethod de?nition statement (using the deffunction keyword/command),that de?nes a a new“user-de?ned”JessMethod that corresponds to the e?ector aproc q.There are some other relatively straightforward mechanics of how to pass the path,classname,and methodname of a(sensor or e?ector)aproc to Jess when de?ning the corresponding JessMethod;some of these details are in evidence in the example below. There are a few di?erent possible lower-level design choices for exactly how to do this.Below,we illustrate and describe how it is done in the current implementation.
Example7.Noti?cation E?ector:The e?ector statement from Example3(sub-section2.2)is translated into the following Jess rule.(Also—not shown here—there is a JessMethod de?nition statement for the e?ector aproc ack.)
(defrule effect_shouldInformCustomer_1
(shouldInformCustomer?orderModificationRequest?status)
=>
(effector ack orderMgmt.Request.mods
(create$?orderModificationRequest?status)))
The“effector”JessMethod in the Jess rule above is actually a generic e?ector procedure (one for the whole rulebase)that takes the particular e?ector aproc’s methodname,classname, and e?ector-call argument list as its input parameters.This is a rather elegant low-level design approach that exploits the power of Java in Jess.This generic e?ector procedure also has a corre-sponding JessMethod de?nition statement.Similarly,in this approach,there is a generic“sensor”JessMethod(one for the whole rulebase).
A sensor statement associating a predicate p with an attached procedure q,is translated more indirectly.Its presence in the input results in modifying the translation of every rule r whose body
mentions the predicate p.A sensor atom of the form p(t),within the body of r,is then translated into the expression
(or BP(p,t)(test MC(q,t)))
rather than into simply the basic pattern BP(p,t)which corresponds directly to the sensor atom. Here,t stands for a tuple of arguments,and MC(q,t)is a JessMethod call expression to invoke
aproc q on arguments t.That is,a TestCE pattern is also generated to do sensing via the aproc q,and that TestCE pattern is disjoined(i.e.,OR’d)with the basic pattern in p.The result when the rule LHS is matched/tested is to invoke/query the sensor as well as to match the basic pattern
against the working memory’s set of facts.Also,like with e?ectors,the translation generates a JessMethod de?nition statement for the sensor aproc q.
More generally,there may be multiple(e.g.,two)sensor statements for p,each with a corre-
sponding aproc,e.g.,q1and q2.In this case,multiple TestCE patterns are disjoined—one per aproc—e.g.,the sensor atom p(t)is translated into
(or BP(p,t)(test MC(q1,t))(test MC(q2,t)))
Example8.Receipt Date Sensor:In Example3,the rule together with the sensor statement,is translated into the following Jess rule.
(defrule rule_526
(deadlineToCancel order4215?Day)
(or
(receivedBefore cancelRequest4216?Day)
(test(sensor earlierReceiptDate orderMgmt.Request
(create$cancelRequest4216?Day))))
=>
(assert(shouldInformCustomer cancelRequest4216accepted)))
(Also—not shown here—there is a JessMethod de?nition statement for the sensor aproc earlierReceiptDate.)
Expressive restrictions imposed on the rulebase:all-bound sensors(recall section3).
Expressive features enabled for the rulebase:Situated LP(sensors,e?ectors),thus Situated OLP.
5.7Courteous Prioritized Con?ict Handling
So far,we have described how to translate for the Situated Ordinary LP(SOLP)expressive class of RuleML(along with the LTAO and URI constant names features).We call this the SOLP case of the translation.SCLP RuleML also includes the Courteous expressive feature for prioritized con?ict handling(and limited classical negation),which we overviewed in sub-section2.3.Jess,however, does not support anything like the Courteous feature directly;it lacks the ability(directly)to express mutex’s or the kind of prioritized con?ict handling that Courteous LP enables.
Use Courteous Compiler:We have found a means for overcoming this incapacity of Jess.It is to compose an additional transformation,called the Courteous Compiler,as a?rst step before the“basic”SOLP-case translation.As we have shown in previous work[8][5],the Courteous Com-piler transforms a(Situated)Courteous LP into a semantically equivalent(Situated)Ordinary LP. IBM CommonRules and SweetRules make use of a Courteous Compiler component,for example; CommonRules provides one as part of its toolset.12For an input SCLP RuleML rulebase that contains Courteous expressive features(notably,mutex’s explicit or implicit),we thus re?ne the SweetJess architecture accordingly:as a?rst step in trans[RJ],the input RuleML rulebase(.rml) is transformed via a Courteous Compiler(CC)component into a di?erent,but semantically equiv-alent,RuleML rulebase that no longer contains the Courteous features.This post-CC rulebase is then run through the basic SOLP-case translator for trans[RJ].The SOLP-case translator handles SOLP(plus LTAO and URI constant names).
12The Courteous Compiler step is tractable computationally:worst-case O(n3)but typically more like O(k?n),where3≤k≤50,in practical experience to date.
Expressive features enabled for the rulebase:Courteous(prioritized con?ict handling,limited classical negation),thus SCLP.
Expressive restrictions imposed on the rulebase:
(1)the post-Courteous-Compiler NAF-related restrictions(dynamic strati?ability)13;and
(2)con?ict-free sensing(recall sub-section2.3).
Note also that the Datalog restriction applies to the mutex’s.
6Transforming Jess To RuleML:trans[JR]
Next,we describe trans[JR],the translation from Jess to RuleML.In the rest of this section,the “translation”means trans[JR],unless explicitly indicated otherwise.
The input to trans[JR]is a Jess batch(.jess)?le containing facts,rules,and JessMethod def-initions,that can be directly fed to the Jess Rete engine in its current version(V6.1).Output of trans[JR]is a RuleML(.rml)?le.
To support RuleML inferencing via translation to/from Jess,via our SweetJess architecture,it su?ces simply to translate Jess facts—i.e.,the conclusions of inferencing by the Jess rule engine —to RuleML.
The translation of facts is straightforward.Jess facts are de?ned in calls to the JessMethod “assert”.To transform a Jess fact,trans[JR]just strips o?the assert to obtain the inner ground-atom-like expression,and generates a RuleML fact that corresponds to that inner expression.Facts in Jess each have a unique Fact Id which is generated by the system upon loading or inferencing. Jess facts do not have an explicit label for identi?cation.In RuleML facts have an optional rule label.For the time being,we de?ne trans[JR]to simply translate this Jess Fact Id into the RuleML fact label.
Our translation mapping extends to much more than facts,however.It is relatively straightfor-ward to invert the OLP case of trans[RJ],i.e.,to“round-trip”the results of trans[RJ];each Jess rule is translated into a RuleML(implication)rule.
The fundamental expressive class covered by trans[JR]thus includes OLP(with the other OLP-relevant expressive features and restrictions that we discussed in the last section).The current prototype implements this case of trans[JR].However,in the current implementation of trans[JR], the Situated extension is not supported,i.e.,the implementation of trans[JR]does not handle TestCE’s or(non-assert)actions.
In the larger SweetJess e?ort,we have been investigating how to extend the fundamental ex-pressive class covered by this translation trans[JR]from OLP to Situated OLP.Next,we give a sketch of how.
(1.)For each JessMethod sproc appearing in some TestCE:
(a.)introduce a new predicate spred;and
(b.)generate a sensor statement associating spred with sproc.
Note this sensor statement also essentially de?nes/declares sproc from RuleML’s viewpoint.
(2.)Likewise,for each JessMethod eproc appearing in some action(expression):
(a.)introduce a new predicate epred;and
(b.)generate an e?ector statement associating epred with eproc.
(Similarly,this e?ector statement also essentially de?nes/declares eproc from RuleML’s viewpoint.)
(3.)Translate a TestCE pattern(sproc t)to a sensor atom spred(t),where t stands for the arguments.
(4.)Translate an action(eproc t)to an e?ector atom epred(t),where t stands for the argu-ments.
7Conclusions,Discussion and Future Work
For the main Conclusions,see section1“Introduction and Overview”,especially the list of novel contributions we gave there.At core,our e?ort is not particular to RuleML or Jess,but rather 13In current work,we are investigating how to characterize syntactic su?cient conditions on the original (S)CLP to guarantee this restriction is met.
between knowledge representations.Its essence is to translate from declarative SCLP to(OPS5-heritage)production rules,and vice versa.This continues the overall approach and vision we?rst
gave in[8].
That the translation between RuleML and Jess imposes some expressive restrictions in each direction is entirely typical when engaged in de?ning translations between two heterogeneous rule systems(or any other kind of heterogeneous systems)—the translation handles their expressive overlap.
Another contribution of our translation e?ort is to discover and compare the expressive capa-
bilities of each rule system and its underlying fundamental KR.In particular,we discovered and highlighted some limitations of Jess as compared to SCLP,including about its ability to represent attached procedures.Jess is less expressively powerful than Situated(Courteous)LP,in that sensor arguments must be fully bound,and sensors may only return true or false;whereas in SCLP,sensor arguments may contain variables that are unbound at the time the sensor is called,and sensors may
return sets of bindings(or sets of facts,viewed alternatively).Jess also can make use of Courteous prioritized con?ict handling since Jess does not provide a comparably powerful or clean way to express prioritized con?ict handling.The comparative insights emerging from the translation e?ort
thus show the potential value of SCLP as an expressive enhancement relative to production rule systems.
Our current work includes implementation and testing of the translation mapping and the
overall architecture;development of more formal theory/theorems about the semantic equivalencies including about correctness of the translation and about semantics of negation-as-failure;extending
to object-oriented argument collections;and integration with SweetRules.In this regard,there may
be some additional,relatively minor,expressive restrictions to be added,or other relatively minor
modi?cations needed,to ensure the correctness of the translation.The version of the translation
design in this paper is penultimate,rather than?nalized,in that sense.
References
1.Baral C.and Gelfond M.,“Logic Programming and Knowledge Representation”,J.Logic Programming,
19-20:73-148
2.Clocksin W.F.and Mellish C.S.,Programming in Prolog.Springer-Verlag,1981
3.T.Cooper and N.Wogrin,Rule-Based Programming with OPS5.Morgan-Kaufmann Pub.,1988
4.DARPA Agent Markup Language Program https://www.wendangku.net/doc/45368222.html,/
5.IBM CommonRules.https://www.wendangku.net/doc/45368222.html,/
https://www.wendangku.net/doc/45368222.html,mon Logic,a proposed ISO standard.https://www.wendangku.net/doc/45368222.html,/
7.Forgy,Charles L.,“Rete:A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem”,Arti?cial Intelligence19(1),pp.17-37,1982.
8.Grosof B.N.,Labrou Y.,and Chan H.Y.,“A Declarative Approach to Business Rules in Contracts: Courteous Logic Programs in XML”.Proc.1st ACM Conf.on Electronic Commerce(EC-99),1999.
9.Grosof,B.N.,Poon,T.C.,“Representing Agent Contracts with Exceptions using XML Rules,Ontologies,
and Process Descriptions”.Proc.12th Intl.Conf.on the World Wide Web(WWW-2003),2003.Earlier
version in:Proc.Intl.Wksh.on Rule Markup Languages for Business Rules on the Semantic Web,held
at1st Intl.Semantic Web Conf.,2002.
10.Grosof B.N.,“Representing E-Business Rules for Rules for the Semantic Web:Situated Courteous
Logic Programs in RuleML”.Proc.Wksh.on Information Technology and Systems(WITS’01),2001. Extended report version available at author’s website.
11.Jess.https://www.wendangku.net/doc/45368222.html,/jess/.
12.Knowledge Interchange Format.https://www.wendangku.net/doc/45368222.html,/kif and https://www.wendangku.net/doc/45368222.html,/kif.
Closely related is the new Common Logic e?ort.
13.John W.Lloyd,Foundations of Logic Programming,Second,Extended edition,Springer,Berlin,1987.
14.Niemela,I.and Simons,P.,Smodels(version1).http://saturn.hut.?/html/sta?/ilkka.html.
15.Reeves D.M.,Wellman M.P.and Grosof B.N.,“Automated Negotiation From Declarative Contract Descriptions”.Computational Intelligence,special issue on Agent Technology for Electronic Commerce,
Nov.2002.(Revised and extended from2001Autonomous Agents conference paper.)
16.Resource Description Format(RDF)from World Wide Web Consortium.https://www.wendangku.net/doc/45368222.html,.
17.Rule Markup Language Initiative.https://www.wendangku.net/doc/45368222.html, and https://www.wendangku.net/doc/45368222.html,/bgrosof/#RuleML.
18.Semantic Web Activity of the World Wide Web Consortium.https://www.wendangku.net/doc/45368222.html,/2001/sw.
19.Ullman J.D.and Widom J.,A First Course in Database Systems.Prentice-Hall,1997.
20.Allen Van Gelder,Kenneth A.Ross,and John S.Schlipf,“The Well-Founded Seman-tics for General Logic Programs,”Journal of the ACM,38:3,pp.620-650,July1991. https://www.wendangku.net/doc/45368222.html,/?kar/pubsk/wfjacm.ps.
21.Web Services Activity of the World Wide Web Consortium.https://www.wendangku.net/doc/45368222.html,/2002/ws.
22.World Wide Web Consortium.https://www.wendangku.net/doc/45368222.html,.
23.XSB logic programming system.https://www.wendangku.net/doc/45368222.html,./and https://www.wendangku.net/doc/45368222.html,/sbprolog.
24.XSLT(eXtensible Stylesheet Language Transformations),https://www.wendangku.net/doc/45368222.html,/Style/XSL/.
INC与LLC的区别
Inc. (incorporated) 为根据公司法组成的股份有限公司. LLC(Limited Liability Company)有限责任公司 有限责任公司和股份有限公司 有限责任公司与股份有限公司作为公司的两种主要形式，有它们的共同点，也有不同点。 有限责任公司与股份有限公司的共同点是： （1）股东都对公司承担有限责任。无论在有限责任公司中，还是在股份有限公司中，股东都对公司承担有限责任，“有限责任”的范围，都是以股东公司的投资额为限。 （2）股东的财产与公司的财产是分离的，股东将财产投资公司后，该财产即构成公司的财产，股东不再直接控制和支配这部分财产。同时，公司的财产与股东没有投资到公司的其他财产是没有关系的，即使公司出现资不抵债的情况，股东也只以其对公司的投资额承担责任，不再承担其他的责任。 （3）有限责任公司和股份有限公司对外都是以公司的全部资产承担责任。也就是说，公司对外也是只承担有限的责任，“有限责任”的范围，就是公司的全部资产，除此之外，公司不再承担其他的财产责任。 有限责任公司与股份有限公司的不同点： （1）两种公司在成立条件和募集资金方面有所不同。有限责任公司的成立条件比较宽松一点，股份有限公司的成立条件比较严格；有限责任公司只能由发起人集资，不能向社会公开募集资金，股份有限公司可以向社会公开募集资金；有限责任公司的股东人数，有最高和最低的要求，股份有限公司的股东人数，只有最低要求，没有最高要求。
（2）两种公司的股份转让难易程度不同。在有限责任公司中，股东转让自己的出资有严格的要求，受到的限制较多，比较困难；在股份有限公司中，股东转让自己的股份 比较自由，不象有限责任公司那样困难。 （3）两种公司的股权证明形式不同。在有限责任公司中，股东的股权证明是出资证明书，出资证明书不能转让、流通；在股份有限公司中，股东的股权证明是股票，即股 东所持有的股份是以股票的形式来体现，股票是公司签发的证明股东所持股份的凭证，股票可以转让、流通。 （4）两种公司的股东会、董事会权限大小和两权分离程度不同。在有限责任公司中，由于股东人数有上限，人数相对来计比较少，召开股东会等也比较方便，因此股东会 的权限较大，董事经常是由股东自己兼任的，在所有权和经营权的分离上，程度较低；在股份有限公司中，由于股东人数没有上限，人数较多且分散，召开股东会比较困难，股东会的议事程序也比较复杂，所以股东会的权限有所限制，董事会的权限较大，在 所有权和经营权的分离上，程度也比较高。 （5）两种公司的财务状况的公开程度不同。在有限责任公司中，由于公司的人数有限，财务会计报表可以不经过注册会计师的审计，也可以不公告，只要按照规定期限送交 各股东就行了；在股份有限公司中，由于股东人数众多很难分类，所以会计报表必须 要经过注册会计师的审计并出具报告，还要存档以便股东查阅，其中以募集设立方式 成立的股份有限公司，还必须要公告其财务会计报告。
in on at的时间用法和地点用法 完全版
in，on，at的时间用法和地点用法 一、in, on, at的时间用法 ①固定短语： in the morning/afternoon/evening在早晨/下午/傍晚, at noon/night在中午/夜晚, （不强调范围，强调的话用during the night） early in the morning=in the early morning在大清早， late at night在深夜 on the weekend在周末（英式用at the weekend在周末，at weekends每逢周末） on weekdays/weekends在工作日/周末， on school days/nights在上学日/上学的当天晚上， ②不加介词 this, that, last, next, every, one, yesterday, today, tomorrow, tonight，all，most等之前一般不加介词。如， this morning 今天早晨 （on）that day在那天（that day更常用些） last week上周 next year明年 the next month第二个月（以过去为起点的第二个月，next month以现在为起点的下个月） every day每天 one morning一天早晨 yesterday afternoon昨天下午 tomorrow morning明天早晨 all day/morning/night整天/整个早晨/整晚（等于the whole day/morning/night） most of the time （在）大多数时间 ③一般规则 除了前两点特殊用法之外，其他≤一天，用on，＞一天用in，在具体时刻或在某时用at（不强调时间范围） 关于on 生日、on my ninth birthday在我九岁生日那天 节日、on Teachers’Day在教师节 （注意：节日里有表人的词汇先复数再加s’所有格，如on Children’s Day, on Women’s Day, on Teachers Day有四个节日强调单数之意思，on Mother’s Day, on Father’s Day, on April Fool’s Day, on Valenti Day） 星期、on Sunday在周日，on Sunday morning在周日早晨 on the last Friday of each month 在每个月的最后一个星期五 日期、on June 2nd在六月二日 on the second (of June 2nd) 在六月的第二天即在六月二日 on the morning of June 2nd在六月二日的早晨，on a rainy morning在一个多雨的早晨 on a certain day 在某天 on the second day在第二天（以过去某天为参照） 注意：on Sunday在周日，on Sundays每逢周日（用复数表每逢之意），every Sunday每个周日，基本一个意思。 on a school day 在某个上学日，on school days每逢上学日。on the weekend在周末，on weekends每逢 周末。 关于in in June在六月 in June, 2010在2010年六月
Blade Inc Case
Ch1 1. What are the advantages Blades could gain from importing from and/or exporting to a foreign country such as Thailand? ANSWER: The advantages Blades, Inc. could gain from importing from Thailand include potentially lowering Blades’ cost of goods sold. If the inputs (rubber and plastic) are cheaper when imported from a foreign country such as Thailand, this would increase B lades’ net income. Since numerous competitors of Blades are already importing components from Thailand, importing would increase Blades’ competitiveness in the U.S., especially since its prices are among the highest in the roller blade industry. Furthermore, since Blades is considering longer range plans in Thailand, importing from and exporting to Thailand may present it with an opportunity to establish initial relationships with some Thai suppliers. As far as exporting is concerned, Blades, Inc. could be one of the first firms to sell roller blades in Thailand. Considering that Blades is contemplating to eventually shift its sales to Thailand, this could be a major competitive advantage. 2. What are some of the disadvantages Blades could face as a result of foreign trade in the short run? In the long run? ANSWER: There are several potential disadvantages Blades, Inc. should consider. First of all, Blades would be exposed to currency fluctuations in the Thai baht. For example, the dollar cost of imported inputs may become more expensive over time if the baht appreciates even if Thai suppliers do not adjust their prices. However, Blades’ sales in Thailand would also increase in dollar terms if the baht appreciates, even if Blades does not increase its prices. Blades, Inc. would also be exposed to the economic conditions in Thailand. For example, if there is a recession, Blades would suffer from decreased sales to Thailand. In the long run, Blades should be aware of any regulatory and environmental constraints the Thai government may impose on it (such as pollution controls). Furthermore, the company should be aware of the political risk involved in operating in Thailand. For example, the likelihood of expropriation by the Thai government should be assessed. Another important issue involved in Blades’ long-run plans is how the foreign subsidiary would be monitored. Geographical distance may make monitoring very difficult. This is an especially important point since Thai managers may conform to goals other than the maximization of shareholder wealth. 3. Which theories of international business described in this chapter apply to Blades, Inc. in the short run? In the long run? ANSWER: There are at least three theories of international business: the theory of comparative advantage, the imperfect markets theory, and the product cycle theory. In the short run, Blades would like to import from Thailand because inputs such as rubber and plastic are cheaper in Thailand. Also, it would like to export to Thailand to take advantage of the fact that few roller blades are currently sold in Thailand. Both of these factors suggest that the imperfect markets theory applies to Blades in the short run. In the long run, the goal is to possibly establish a subsidiary in Thailand and to be one of the first roller blade manufacturers in Thailand. The superiority of its production process suggests that the theory of comparative advantage would apply to Blades in the
常用标点符号用法简表.doc
常用标点符号用法简表 标点符号栏目对每一种汉语标点符号都有详细分析，下表中未完全添加链接，请需要的同学或朋友到该栏目查询。名称符号用法说明举例句号。表示一句话完了之后的停顿。中国共产党是全中国人民的领导核心。逗号，表示一句话中间的停顿。全世界各国人民的正义斗争，都是互相支持的。顿号、表示句中并列的词或词组之间的停顿。能源是发展农业、工业、国防、科学技术和提高人民生活的重要物质基础。分号；表示一句话中并列分句之间的停顿。不批判唯心论，就不能发展唯物论；不批判形而上学，就不能发展唯物辩证法。冒号：用以提示下文。马克思主义哲学告诉我们：正确的认识来源于社会实践。问号？用在问句之后。是谁创造了人类？是我们劳动群众。感情号①！1.表示强烈的感情。2.表示感叹句末尾的停顿。战无不胜的马克思主义、列宁主义、毛泽东思想万岁！引号 ②“ ” ‘ ’ ╗╚ ┐└1.表示引用的部分。毛泽东同志在《论十大关系》一文中说：“我们要调动一切直接的和间接的力量，为把我国建设成为一个强大的社会主义国家而奋斗。”2.表示特定的称谓或需要着重指出的部分。他们当中许多人是身体好、学习好、工作好的“三好”学生。 3.表示讽刺或否定的意思。这伙政治骗子恬不知耻地自封为“理论家”。括号③（）表示文中注释的部分。这篇小说环境描写十分出色，它的描写（无论是野外，或是室内）处处与故事的发展扣得很紧。省略号④……表示文中省略的部分。这个县办工厂现在可以生产车床、电机、变压器、水泵、电线……上百种产品。破折号⑤——1.表示底下是解释、说明的部
分，有括号的作用。知识的问题是一个科学问题，来不得半点的虚伪和骄 傲，决定地需要的倒是其反面——诚实和谦逊的态度。2.表示意思的递进。 团结——批评和自我批评——团结3.表示意思的转折。很白很亮的一堆洋 钱！而且是他的——现在不见了！连接号⑥—1.表示时间、地点、数目等 的起止。抗日战争时期（1937-1945年）“北京—上海”直达快车2.表 示相关的人或事物的联系。亚洲—太平洋地区书名号⑦《》〈〉表示 书籍、文件、报刊、文章等的名称。《矛盾论》《中华人民共和国宪法》《人 民日报》《红旗》杂志《学习〈为人民服务〉》间隔号·1.表示月份和日期 之间的分界。一二·九运动2.表示某些民族人名中的音界。诺尔曼·白求 恩着重号.表示文中需要强调的部分。学习马克思列宁主义，要按照毛泽 东同志倡导的方法，理论联系实际。······
In on at 时间用法及练习
In\ on\ at (time) at 用在具体某一时刻eg at 11:00 at 4:30 在节假日的全部日子里at Christmas 习惯用法at noon at weekends\ at the weekend at night at breakfast\lunch\supper on 具体到某一天；某一天的早晨，中午或晚上on May the first on Sunday morning 对具体某一天的早晨，中午，晚上进行详细的描述on a sunny morning on a windy night 节日的当天；星期on Women?s Day on Monday In 用在年；月；季节in spring in 2012 in August 后面+一段时间表示将来时in two days 习惯用法in the morning\in the afternoon\in the evening “\”以this, that, last, next, some, every, one, any,all开始的时间副词之前的at\on\in 省略在today, tomorrow, yesterday, the day after tomorrow, tomorrow morning，yesterday afternoon，the day before yesterday 之前的介词必须省略 Practice ___ summer ____ 2012 ____ supper ___ 4:00 ___ June the first ___yesterday morning ____ New Year?s Day ___ Women?s Day ___ the morning ____ the morning of July the first ____ 2014 ___ tomorrow morning ____ midnight 1.—What are you doing ____ Sunday? And what is your wife doing ___ the weekend? 2. He?ll see you ____ Monday. And he…ll see your brother ____next Monday. 3. They often go out ___ the evenings. But they don?t go out ____ Sunday evenings. 4. Do you work ____ Fridays? Does she work _____ every Friday? 5. They usually have a long holiday ___ summer. But their son can only have a short holiday ___ Christmas. 6. Paul got married ___ 2010, He got married ___ 9 o?clock ___ 19 May 2010. His brother got married ___ May, 2011. His sister is getting married ___ this year. 1.—When will Mr Black come to Beijing? ---_______ September 5 A. on B. to C. at D. in 2. The twins were born ____ a Friday evening. A. on B. of C. at D. in 3. It?s the best time to plant ____ spring. A. on B. in C. at D.\ 4. ____ the age of twelve, Edison began selling newspaper on train. A. On B. At C. In D.By 5. She has been an English teacher ____ 2000. A. for B. since C. in D.on 6.I have studied English _____ 2003. A. since B. for C. from D.in
常用标点符号用法含义
一、基本定义 句子，前后都有停顿，并带有一定的句调，表示相对完整的意义。句子前后或中间的停顿，在口头语言中，表现出来就是时间间隔，在书面语言中，就用标点符号来表示。一般来说，汉语中的句子分以下几种： 陈述句： 用来说明事实的句子。 祈使句： 用来要求听话人做某件事情的句子。 疑问句： 用来提出问题的句子。 感叹句： 用来抒发某种强烈感情的句子。 复句、分句： 意思上有密切联系的小句子组织在一起构成一个大句子。这样的大句子叫复句，复句中的每个小句子叫分句。 构成句子的语言单位是词语，即词和短语（词组）。词即最小的能独立运用的语言单位。短语，即由两个或两个以上的词按一定的语法规则组成的表达一定意义的语言单位，也叫词组。 标点符号是书面语言的有机组成部分，是书面语言不可缺少的辅助工具。它帮助人们确切地表达思想感情和理解书面语言。 二、用法简表 名称
句号① 问号符号用法说明。？1．用于陈述句的末尾。 2．用于语气舒缓的祈使句末尾。 1．用于疑问句的末尾。 2．用于反问句的末尾。 1．用于感叹句的末尾。 叹号！ 2．用于语气强烈的祈使句末尾。 3．用于语气强烈的反问句末尾。举例 xx是xx的首都。 请您稍等一下。 他叫什么名字？ 难道你不了解我吗？为祖国的繁荣昌盛而奋斗！停止射击！ 我哪里比得上他呀！ 1．句子内部主语与谓语之间如需停顿，用逗号。我们看得见的星星，绝大多数是恒星。 2．句子内部动词与宾语之间如需停顿，用逗号。应该看到，科学需要一个人贡献出毕生的精力。 3．句子内部状语后边如需停顿，用逗号。对于这个城市，他并不陌生。 4．复句内各分句之间的停顿，除了有时要用分号据说苏州园林有一百多处，我到过的不外，都要用逗号。过十多处。 顿号、用于句子内部并列词语之间的停顿。
2时间介词in,on,at的用法
介词in on at 表示时间的用法及区别 Step1 Teaching Aims 教学生掌握时间介词in,on和at的区别及用法。 Step2 Teaching Key and Difficult Points 教学生掌握时间介词in,on和at的区别及用法。 Step3 Teaching Procedures 1.用in的场合后所接的都是较长时间 (1)表示“在某世纪/某年代/特定世纪某年代/年/季节/月”这个含义时，须用介词in Eg: This machine was invented in the eighteenth century. 这台机器是在18世纪发明的。 、 She came to this city in 1980. 他于1980年来到这个城市。 It often rains here in summer. 夏天这里常常下雨。 (2)表示“从现在起一段时间以后”时，须用介词in。(in+段时间表将来) Eg: They will go to see you in a week. 他们将在一周后去看望你。
I will be back in a month. 我将在一个月后回来。 (3)泛指一般意义的上、下午、晚上用in, in the morning / evening / afternoon Eg: They sometimes play games in the afternoon. 他们有时在下午做游戏。 Don't watch TV too much in the evening. 晚上看电视不要太多。（4）A. 当morning, evening, afternoon被of短语修饰，习惯上应用on, 而不用in. Eg: on the afternoon of August 1st & B. 但若前面的修饰词是early, late时，虽有of短语修饰，习惯上应用in, 而不用on. Eg: in the early morning of September 10th 在9月10的清晨； Early in the morning of National Day, I got up to catch the first bus to the zoo. 国庆节一清早，我便起床去赶到动物园的第一班公共汽车。 2.用on的场合后所接的时间多与日期有关 （1）表示“在具体的某一天”或（在具体的某一天的）早上、中午、晚上”，或“在某一天或某一天的上午，下午，晚上”等，须用介
介词in-on-at在表示时间时的用法
介词in, on, at在表示时间时的用法区别 ①in时间范围大（一天以上）如：in Tanuary, in winter, in 1999;泛指在上午，下午，晚上，如：in the morning(afternoon, evening). 习惯用法：in the daytime 在白天。 ②on指在某一天或某一天的上午，下午，晚上，如：on Monday, on Sunday afternoon, on July 1, 1999 ③at时间最短，一般表示点时间，如at six o’clock, at three thirty.习惯用法：at night, at noon, at this time of year. in, on和at在表达时间方面的区别 in 表示在某年、某季节、某月、某周、某天和某段时间 in a year在一年中 in spring 在春季 in September 在九月 in a week 在一周中 in the morning/afternoon/evening 在上午/下午/傍晚 但在中午，在夜晚则用at noon/night on 表示某一天或某一天的某段时间 on Monday 在周一 on Monday afternoon 在周一下午 on March 7th 在3月7日 on March 7th, 1998. 在1998年3月7日 on the morning of March 7th, 1998. 在1998年3月7日上午
at 表示某个具体时刻。 at eight o’clock 在8点钟 at this time of the year 在一年中的这个时候 at the moment 在那一时刻 at that time 在那时 注意：在英语中，如果时间名词前用this, last, next 等修饰时，像这样的表示，“在某时”的时间短语前，并不需要任何介词。 例如：last month, last week, this year, this week, next year, the next day, the next year 等。 1．What’s the weather like in spring/summer/autumn/winter in your country? 你们国家春天/夏天/秋天/冬天的天气怎么样？ in 在年、月、周较长时间内 in a week 在里面 in the room 用某种语言 in English 穿着 in red on 某日、某日的上下午on Sunday afternoon 在……上面 on the desk 靠吃……为生live on rice 关于 a book on Physics 〔误〕We got to the top of the mountain in daybreak. 〔正〕We got to the top of the mountain at day break. 〔析〕at用于具体时刻之前，如：sunrise, midday, noon, sunset, midnight, night。〔误〕Don't sleep at daytime 〔正〕Don't sleep in daytime. 〔析〕in 要用于较长的一段时间之内，如：in the morning / afternoon, 或in the week / month / year. 或in spring / supper /autumn / winter等等。 〔误〕We visited the old man in Sunday afternoon. 〔正〕We visited the old man on Sunday afternoon. 〔析〕in the morning, in the afternoon 如果在这两个短语中加入任何修饰词其前面的介
LLC INC LTD CORP的区别
LLC，LLP，Inc，Corp的区别 Corp是Corporation的缩写，（公司, 财团法人） （结合, 合并, 形成法人组织, 组成公司(或社团) Inc是Incorporation的缩写， Co.Ltd.是Limited company的缩写，叫做有限责任公司 LLC是Limited Liability Company 的缩写，叫做有限责任公司 LLP 是Limited Liability Partnership的缩写，叫做有限责任合伙公司 法定公司Corporation (INC) 定义Definition: 是一个州政府注册组织最完善的独立法人。商业行为明文制限于公司法。有 C-Corporation和S-Corporation两种。 This state chartered organization acts as a separate legal entity and is the most structured business entity. Business activities are restricted to those listed in the corporate charter. Corporations may elect to file as a C-Corporation or S-Corporation. C-corporation –根据收入需付联邦及州税。当利润交给股东，股东申报个人税时再次需付收入税。双重克税为其最大缺点。 pays federal and state income taxes on earnings. When the earnings are distributed to the shareholders as dividends, the earnings are taxed again. Double taxation is a big drawback of C-corporations. S-corporation -法律特色如同C-Corporation，但不需直接付税，只要申报收入付个人税即可。 have the same legal attributes as the C-corporation, however, the corporation does not pay income taxes on earnings, rather, the shareholder pays income tax on dividends on their personal income tax return. S corporation需另符合下列几项条件: S corporation owners (shareholders) must meet the following criteria: 拥有人（股东）少于100人Number fewer than 100 拥有人（股东）不可是非永久居民外国人Cannot be non-resident aliens 拥有人（股东）不可是其他法定公司、有限责任公司、合伙公司或信托Cannot be C corporations, other S corporations, limited liability companies (LLCs), partnerships or certain trusts. 优点Advantages:
inonat的时间用法和地点用法版
精心整理in，on，at的时间用法和地点用法 一、in,on,at的时间用法 1、固定短语： inthemorning/afternoon/evening在早晨/下午/傍晚, 2 （on thenextmonth第二个月（以过去为起点的第二个月，nextmonth以现在为起点的下个月） everyday每天 onemorning一天早晨 yesterdayafternoon昨天下午
tomorrowmorning明天早晨 allday/morning/night整天/整个早晨/整晚（等于thewholeday/morning/night）mostofthetime（在）大多数时间 3、一般规则 除了前两点特殊用法之外，其他≤一天，用on，＞一天用in，在具体时刻或在某时用at（不强调时间范围） 关于 On 1 2) 3) （注意：节日里有表人的词汇先复数再加s’所有格，如 onChildren’sDay,onWomen’sDay,onTeachers’Day有四个节日强调单数之意思，onMother’sDay,onFather’sDay,onAprilFool’sDay,onValentine’sDay） 星期、onSunday在周日，onSundaymorning在周日早晨onthelastFridayofeachmonth在每个月的最后一个星期五
日期、onJune2nd在六月二日 onthesecond(ofJune2nd)在六月的第二天即在六月二日onthemorningofJune2nd在六月二日的早晨，onarainymorning在一个多雨的早晨 onacertainday在某天 onthesecondday在第二天（以过去某天为参照） 关于 In 1 2) InJune在六月 inJune,2010在2010年六月 in2010在2010年 inamonth/year在一个月/年里（在将来时里翻译成一个月/年之后） inspring在春天
威廉.索拿马公司(William-Sonoma-Inc.)
威廉.索拿马公司 Williams-Sonoma Inc 背景简介： 威廉.索拿马公司（WSI）是一家成立于1956年的高品质家居用品美国专业零售商、邮购商和电商。在美国纽约证劵交易所上市，年营业额$??? 。其中电子商务和邮购销售占营业额的43.%，零售占56.1%。其在美国，加拿大、澳大利亚和中东（科威特，沙特阿拉伯和阿拉伯酋长国）等地开设专业零售商店，产品通过网络销售可到全球79个国家和地区，共有员工约26,9000余人， 579家实体店，发行7种直邮目录，拥有6个电子商务网站。 该公司旗下有八个品牌，每个品牌在他们所处的行业中都是非常知名且备受尊敬和追从。威廉.索拿马一直以来都以为客户提供高品质和新式样的产品体验为企业经营目标，产品线已覆盖至消费者家里的每一个角落，从厨房到餐厅、客厅、卧室、书房及衣帽间。 威廉.索拿马旗下的八个品牌分别有各自不同的分销策略和客户群： 品牌1： William Sonoma Inc –主营炊具和提供婚礼注册表服务 品牌2：Pottery Barn Furniture –主营家具和提供婚礼注册服务 品牌3：Pottery Barn Kids –主营儿童家具和提供婴儿注册表服务 品牌4：PBteen –主营青少年家具和床上用品 品牌5：West Elm –主营现代家具和室内装饰品 品牌6：William Sonoma Home –主营豪华家具和饰品 品牌7：Rejuvenation –主营高档室内灯饰 品牌8：Mark and Graham –主营客制化高档饰品
Welcome To Download !!! 欢迎您的下载，资料仅供参考！
常用标点符号主要用法
常用标点符号主要用法 问号 1、用在特指问句后。如：(7)你今年多大了？ 2、用在反问句后。如：(8)为什么我们不能刻苦一点呢？ ?提示：反问句若语气缓和，末尾可用句号；若语气重可用感叹号。如：(9)国家 主席可以活活被整死；堂堂大元帅受辱骂；……这哪里还有什么尊重可言！ 3、用在设问句后。如：(10)我们能让你计划实现吗？不会的。 4、用在选择问句中。如：(11)我们是革命呢，还是要现大洋？ ( 12)你到底是去，还是不去？ 5、用在表疑问的独词句后。如：(13)我？不可能吧。 ?提示：若疑问句为倒装句，问号应放在句末。如：(14)到底出了什么问题，你的 车？(若说成：“到底出了什么问题？你的车。”则错误。) ?特别提示： 句号、问号均表示句末停顿。句号用于陈述句末尾，问号用于疑问句末尾。有些句 中虽有疑问词，但全句并不是疑问句，句末只能用句号，不能用问号。 例如：(17)……最后应求出铜块的体积是多少？ (18)面对千姿百态、纷繁芜杂的期刊世界，有哪位期刊编辑不想通过期刊版面设 计为刊物分朱布白、添花增色呢？ (19)关于什么是智力？国内外争论多年也没有定论。 (17) (18) ( 19)三句都是非疑问句，(17) (18)句中问号均应改为句号，(19)句中的问号应改为逗号。 感叹号 ?特别提示： 1、在表感叹或祈使语气的主谓倒装句中，感叹号要放在句末。 如：(20)多么雄伟壮观啊，万里长城！ 2、句前有叹词，后是感叹句，叹号放在句末。 如：(21)啊，这儿多么美丽！ 下面介绍句中点号的用法。句中点号包括逗号、分号、顿号、和冒号四种。 逗号 提示：复句内各分句之间的停顿，除了有时用分号外，都要用逗号。 顿号 用于句中并列的词、词组之间较小的停顿。 如：(22)邓颖超的品德、人格、风范为中华民族树立了一座精神丰碑。 (23)从1918年起，鲁迅陆续发表了《狂人日记》、《药》、《祝福》等短篇小说。 ?特别提示：以下九种情况不用顿号。 1、不定数的两个数字间不用顿号。 如：(24)你的年龄大概是十六七岁。(不能写成“十六、七岁”) ?【注意】相邻的两个数字而非约数之间要用顿号。
inonat的时间用法和地点用法版
i n o n a t的时间用法和 地点用法版 集团档案编码：[YTTR-YTPT28-YTNTL98-UYTYNN08]
i n，o n，a t的时间用法和地点用法 一、in,on,at的时间用法 1、固定短语： inthemorning/afternoon/evening在早晨/下午/傍晚, atnoon/night在中午/夜晚,（不强调范围，强调的话用duringthenight）earlyinthemorning=intheearlymorning在大清早， lateatnight在深夜 ontheweekend在周末（英式用attheweekend在周末，atweekends每逢周末）onweekdays/weekends在工作日/周末， onschooldays/nights在上学日/上学的当天晚上， 2、不加介词 this,that,last,next,every,one,yesterday,today,tomorrow,tonight，all，most等之前一般不加介词。如， thismorning今天早晨 （on）thatday在那天（thatday更常用些） lastweek上周 nextyear明年 thenextmonth第二个月（以过去为起点的第二个月，nextmonth以现在为起点的下个月） everyday每天 onemorning一天早晨 yesterdayafternoon昨天下午 tomorrowmorning明天早晨
allday/morning/night整天/整个早晨/整晚（等于 thewholeday/morning/night） mostofthetime（在）大多数时间 3、一般规则 除了前两点特殊用法之外，其他≤一天，用on，＞一天用in，在具体时刻或在某时用at（不强调时间范围） 关于on On指时间表示： 1）具体的时日和一个特定的时间，如某日，某节日，星期几等。Hewillcometomeetusonourarrival. OnMay4th(OnSunday,OnNewYear’sday,OnChristmasDay),therewillbeacelebra tion. 2)在某个特定的早晨，下午或晚上。 Hearrivedat10o’clocko nthenightofthe5th. Hediedontheeveofvictory. 3)准时，按时。 Iftherainshouldbeontime,Ishouldreachhomebeforedark. 生日、onmyninthbirthday在我九岁生日那天 节日、onTeachers’Day在教师节 （注意：节日里有表人的词汇先复数再加s’所有格，如 onChildren’sDay,onWomen’sDay,onTeachers’Day有四个节日强调单数之意思， onMother’sDay,onFather’sDay,onAprilFool’sDay,onValentine’sDay）星期、onSunday在周日，onSundaymorning在周日早晨
卓细公司 TREXEL INC.
主讲单位：卓细公司 TREXEL INC. 讲题： 革命性注塑成型-提升质量及降低成本之 MUCELL? 微细发泡技术 卓细公司将介绍MuCell®微细发泡技术技术的 基本理论，展示各行各业使用的MuCell®塑料部 件，以及介绍此技术的最新发展。公司将会引用应 用案例来说明这技术的特点及好处，例如1)塑件更 轻、更薄、在极端工作温度下尺寸更稳定；2)减少材 料、缩短生产周期、降低废品、使用较少模具和较 小吨位机器来改变基本的成本结构；3)工艺有更大的 成型视窗及更高的Cpk,可减少模具修正次数，提高 生产良率、更快达到质量要求；4)简化和更新的模具和部件设计原理，充分利用MuCell®所提供的更 大流动长度，以及较低的锁模力、模具温度和模腔 压力。 主讲： 亚洲区总经理唐锦荣先生 唐锦荣先生是卓细公司的亚洲区总经理。卓细公司是MUCELL?微细发泡技术的全球独家专利供应商。他住在香港并负责建立亚洲区的营销及服务基础架构，来配合MUCELL?在亚洲区的迅速发展。 他毕业于香港大学并获得工程学士及工商管理硕士。他曾经在几家国际性企业的亚洲区负责营销及管理工作22年多。 主讲单位：卓细公司 TREXEL 公司是MUCELL?微发泡技术的全球独家供专利供应商。与传统注塑成型部件相比，采用MUCELL?微发泡注塑成型技术生产的塑胶部件更轻、更薄、更平整、更笔直、在极端工作温度下尺寸更稳定。MUCELL?技术以较低的成本生产质量更好的部件，而且提供更快的模具验证。MUCELL?技术已成功应用于数百个不同领域，包括汽车、商业设备、工业和电子零件等。 网址：https://www.wendangku.net/doc/45368222.html,