Network, remote attendance

We had a network problem during most of the day, resulting in most people being unable to get on IRC. During the afternoon, scribes took their notes off-line.

In addition, we did not have a polycom during the first session, thus making remote attendance difficult if not impossible.

introduction

(Chair: Christian de Sainte Marie; Scribe: Sandro Hawke)

Christian presents meeting objectives and reviews agenda (slides)

Christian: My objective is to finalize discussion on use cases. If we can't do then, that we need to agree on what to publish.
... We're starting late. The agenda may need to shift.

(long line at registration, although really only about 10 minutes.)

Christian: We might or might not do the split sessions
... One of the objectives of this meeting is to have people talk to each other, including in small groups. Thus the long lunch break.

09:00-12:00 - Review Use Cases I

(Chair: Christian de Sainte Marie; Scribe: Gary Hallmark)

christian: focus on the purpose of rule interchange
... e.g. it could be compliance
... or negotiation to refine the rule
... or to extend a published ontology

christian: RIF could be used without interchange, e.g. persistence

UC should make clear purpose of Publish/Interchange of Rule

...purpose of Translating the Rules into RIF

christian: look for gaps and overlaps in UCs

allen: would like OWL use cases as a model for ours
... uses cases should drive design requirements but not be over-analyzed

<sandro> +1 on Frank & Allen (don't worry about UC's being idiosyncratic -- just use them to drive Goals/Requirements.)

allen: use case names should catch people's interest

frank: look for fundamental drivers and issues rather than more cases

sandro: use cases should drive design decisions

<ericP> in the DAWG, use cases lead directly to requirements

<ericP> the two were cross-ref'd, which allowed us to drop redundant use cases

Information integration use case (poll results)

allen: now named business process design
... rif would help redesign or improve biz process

frank: tried to make the case more compelling

<sandro> http://www.w3.org/2005/rules/wg/wiki/UCR/Information_Integration

frank: driver: dynamic integration of information
... explore synergy of biz processes and rules

<sandro> Uli: is this about integrating data (via rules), or integrating rules?

frank: about integrating rules, not using rules to integrate data

<sandro> Frank: integrating rules.

<sandro> Frank: We need access to business rules of supply chain partners.

francois: ruleset integration should be a central theme of several use cases

<sandro> Francois: "Integrating rule sets"

<sandro> Jeremy: HP wants integration of data!

<josb> +1 agree with Jeremy; RIF should support information integration

<sandro> Christian: Yes -- if this section turns into Ruleset Integration, we need data mapping somewhere else.

frank: Hendler argues that RIF is for rule interchange, not information integration

francois: rif is for both information integration and rule set integration
... rule sets will need to be integrated sometime after they exist
... because the rule sets are developed in parallel

<sandro> Christian: if each user does the data mapping rules on their own, ... that doesn't scale.

<sandro> ... I need to import that rules.

<sandro> Jeremy: If I can publish my mappings in a publically understanding format, then it does scale.

<sandro> ...: But Jena rules doesn't solve the problem -- we need RIF so people can publish the rules for re-use.

<sandro> Frank: Is RIF yet another rule language for describing mappings.

francois: porting rules is hard
... but we can enable publishing

sandro: would like more concrete details about possible data mapping use case

<sandro> sandro: I specifically heard Frank say "We need access to business rules of supply chain partners" -- and I like that as a concrete, motivated use case

<sandro> sandro: And Jeremy seems to be motivated on data mapping.

frank: familiar with product that uses rules to map biz terms to IT term, but it doesn't involve rule exchange

<sandro> Jeremy: Is enterpirse information integration problem done in one giant leap (millions paid to SAP), or does one do it in a distributed small-steps manner? The latter requires publishing rules.

<sandro> sandro: Call that "Grassroots Data Integration"

<sandro> sandro: I'm hearing two use cases here : ruleset integration (eg for supply chain); grassroots data integration (eg vocabulary mapping business -to- IT vocabularies)

<sandro> "access to business rules of supply chain partners"

frank: supplier and customer relationships are different

<sandro> christian: do you need to execute the rules?

<sandro> frank: not clear

frank: i.e. the rules are not aggregated
... relationships are dynamic - data may come from you or partner, rules may be executed by you or partner

<sandro> portability vs publication

sandro: need to move to another use case

Coffee Break until 11:00

Decision Support use case (poll results)

(Chair: Christian de Sainte Marie; Scribe Deepali Krushraj)

<sandro> ... note Leora is not here

<sandro> ... Decision Support -> Integrating Rules from Multiple Knowledge Sources for Decision Support

csma: key focus of use case is integrating rules from multiple knowledge sources for decision support: pharmaceutical companies publishing drug notices as rulesets, medical KB etc

Uli Sattler: might want to distinguish between interoperation and integration

csma: will anyone argue for keeping the E-Learning use cases?

csma: this is clearly a use case of aggregation-- the E-learning use case scenario does not add value to this. Hence, might want to drop this

<josb> +1 on Sandro's comment; use case descriptions should be concise

this section needs some review to cover important points covered in straw poll comments

csma: what are the key dimensions of this use case?
...suggested: 2.2 Ruleset Integration for Medical Decision Support
...suggested: 2.Interative User Training Via Reactive Rules

FrancoisB: Name of use cases should mention the application field as well as the type of usage; main title as one axis, subtitle as another axis -- doesn't really matter which is which.
...Need to rename this section with maybe a subtitle.

Uli: another heading: added value from RIF

Francois: Give me an appplication based on Rules, and half a day, and I'll show you how you'll end up with rule interchange!

<sandro> +1

<josb> +1 agree with last comment Francois

sandro: does the WG agree that aggregating rules for decision support -- eg for drug proscribing -- is in scope for us, something to do.
...vote on who thinks that aggregating rules for decision support systems is in scope

paulV: are they cases where you do the integration by hand now?

Christine: you need to aggregate onotologies (as in Charter use case) as well as rules.

accessing and integrating rules from many sources to support decision -- is this a RIF Use Case?
resolved: in scope

csma: different from Integration use case in that you're integrating the rules here; into one single rule base

Hassan: Digest the rules.

different from integration use case is you take ownership on rules (instead of just applying them)

Gary: really want a few simple examples of rules in each use case!!

<sandro> (widely seconded)

2-3 people don't think it should be done. why not:

PeterPS: examples could be another source of contention, or could be wrong, or could concentrate attention on things that don't matter; eg endless arguments about the service syntax.

Allen: Did not support it because it is not crucial to formalize them; as long as it's clear, examples not needed. Might even be offputting
...rules don't have to use a formal syntax-- it could be in natural language

josb: rules can be in pseudocode
...this is rule 1: (in english)

Francois: be careful that people might read too much into examples -- like that this is the syntax we'll be using!

<sandro> (I wonder if each example could be captioned "Pseudo-code example")

mala: the interchange aspects are not brought out by examples.

csma: examples could be more protocol-like (to stress the interchange-related aspects)

Lunch break until 14:00

14:00-15:30 - Review Use Cases II

(Chair: Christian de Sainte Marie; Scribes: Giorgos Stamou, Hassan Ait-Kaci)

Cross-Platform Rule Development and Deployment use case (poll results)

csma: 10 people took it as is, few with some corrections and only one with no
...The "no" was Mala Malhotra's: expressing ruleset diffs as metainformation for RIF.
...what are templates? Schemas?

mala: I expressed in my e-mail the importance of templates
...it should have more power on interchange
...it is good to find differences and similarities across the rules
...it is easier if you are at the higher level of abstraction

mala: you could extract a template from the rule try to capture the similarity and difference, many vendors do this

csma: what is the added value of this to the rule interchange?
...is it better to interchange templates than rules?

paul: it is important for rule management, we don't execute templates they don't have semantics, maybe they are not relevant to RIF

jos(WHICH ONE?): what is a template?

paul: template is a design pattern, you have templates with parameters

jos(WHICH): is it rules about rules (metarules)

mara: yes

paul: so, it is possibly recommended, since a rule for a rule is a rule

harold: you need a kind of schema for the different parameters

csma: OK, the only no was for generalisation
...propose to add general intro to the UC to cover this
...Does this change address your comments?

mara: it does take my point into account, it is not in the contrary with my comment
...capturing common patterns in rules and use it for interchange is very useful

sandro: OK, nobody disagrees for that

csma: one more comment, the scenario in this usecase is for negotiation
...this need to be more clear

Allen: requires vendor-neutral representation of rules

csma: I agree, but you could do it without negotiation
...so you need to emphasise

christian(WHO?): people use different predicates for representing similar things
...so, template maybe do not cover this

mala: allow you to separate syntactic concerns than logic representation ones

Harold: you need a taxonomy of the predicates and RDFS gives you this opportunity

paul: if a vendor performs rule development, it should support rule templates

sandro: mala, finally you disagree with the usecase?

mala: the usecase represents a subset of the desired usecase

Sandro: let's keep this UC simple. Are "templates" really what characterizes this UC?

csma: initially it was just an instance of "vendor-neutral" rep. of rules to allow users of one rule system to switch to another.

Francois Bry: vocabulary varies among rule languages. Are templates what will allow adjust vocabularies among RL's with similar semantics? If so they are indeed important.

csma: what is Object model and what is rule's knowledge.

Sandro: The most likely scenario in any CP UC is simply to switch from one system to another and still have their ruleset work (moreless) as before.

Frank McCabe: There's a difference between Templates and Vocabularies. "Vendor-neutral" interchange is not what characterizes this UC. Another issue is "what features are needed for cross-platform interchange?". Templates are one of them. But not the only one. Everyone will have a set of desired features.

 Paul Vincent: All the relevant features for RIF are yet to be spelled out.

Allen Ginsberg: Do you (Sandro) wish to split this UC into two?

Sandro: no. It could be simpler, but there's no need to split it (dev. vs. depl.).

csma: Cross-Platform is the most basic RI scenario.

Donald Chapin:  Can we have a requirement that would solve this problem?

Sandro: Probably not the right time and place to answer this question.

csma: should we rename the UC?

hak: Why not label it according to both technology and application dimensions.

Sandro: moves to approve UC 2.3 modifies as CSMA's slide and move on.

(new title: "Negotiating e-Business Contracts across Rule Platforms"; and add paragraph: "This use case illustrates a fundamental use of RIF: to supply a vendor-neutral representation of rules, so that rule-system developers and stakeholders can do their work and make product investments without worrying about being locked into a particular system. It also illustrate the fact that the RIF can be used to foster collaborative work. Each developer and stakeholder can make a contribution to the joint effort without being forced to adopt the tools or platforms of the other contributors")

csma: Do we approve this UC?

Resolved by show of hands (noone against it).

Policy-based Transaction and access control use case (poll results)

csma presented the comments (in the process of straw poll) of "yes, but"

paula presented the comments of no and how she took them into account (Paula's email response to comments):

1. this UC should concentrate on the RIF
2. policies are the rules being interchanged
3. what is interchanged depends on the security level
4. uniform style of writing rules (in NL)
5. need of a common data model
6. this UC is not concise enough, although is has impolrved in precision
7. "P3P" (Platform for Privacy Preference) is not necessary - This UC is not about the platforms

Francois Bry: the point of this UC is to modulate the level of security. This UC should not require any data model.

Donald Chapin: This is a core question we need to deal with. No need to "reinvent" RDF. representing some data model is needed if we want to come up with a useful RIF. No interchange is possible without a common data model. Pick one (RDF, OWL, ...) ...

csma: Should this go into a UC? Recognizing a common data model is ok, but more?...

 Allen: many rule systems define their own data model.
...We should also consider RDF for data model but we can also avoid it

Chris Welty: there are two points being made: (1) sharing the data model and (2) sharing the facts.

donald: we do need to interchange facts

Hassan: I don't agree that if you interchange only rules without facts you don't get anything.
...we don't need to exchange the data model (e.g., CLP).

Sandro: What does it have to do with this UC?

Igor: Can we see what underlying data model is in this UC. Go back to the original case and chack what RL they use.

Paula: No need to implement the UC's rules.

F. Bry: Best to give examples in NL not to commit to any one specifically. Doing otherwise will not be understood.

Igor: I'm not convinced. Not a good idea because we should concentrate on what types of rules we want to interchange.

csma: Shouldn't this UC be made clearer: one the one hand, exposing the constraints the user has to comply with is useful for the user to decide whether or not to engage with the service; one the other hand exchanging the rules makes finding an agreement easier?

Allen Ginsberg: this UC name change? (new proposed title: "Disclosing and negotiating buyers and seller policies on e-commerce transactions).

Sandro: may we should postpone discussing the title.

csma: are the "requesters for edits" of this UC happy with releasing this UC "as is" (i.e., Paula's summary)

show of hands: yes/17, no/0.

RESOLVED.

Publication use case (poll results)

5 yes, 7 yes-buts, 1 no, 3 no-opinions.

csma: Mala proposed to merge this one with UC 2.5 (Interchange of Human-oriented BRs).

Don Chapin: I disagree: this UC (2.6) is all about rules not human-orientedness.

Uli: why not tie the Brain Anatomy UC with the Rich KR UC (2.8)?

csma: This use case is about using rules to explain the meaning or usage of a (published) vocabulary
...enriching an ontology with rules seems to be the common idea here.

Christine: isn't the central issue expressiveness of the formalism being used?

Jos de Bruijn: we won't be able to resolve this now.

Axel: this UC is desirable, but perhaps a more illustrative example more typically pertaining to publication should be proposed. I will submit one.

Break until 16:00

16:00-18:00 - Design Goals

(Chair: Chris Welty; Scribes: Igor Mozetic, Allen Ginsberg)

REWERSE (Francois Bry) (slides)

JosdeBruijn: Tarski vs. well-founded semantics ?

Francois: Both can be combined.

Hassan: Does semantics need to be composable or Tarski's?

Francois: Both, composable (more important) and Tarski's.

Harold: Actions events rules...

csma: No procedural semantics, but priorities are required?

Francois: I don't know how to do it.

DERI, RuleML (Michael Kiefer) (slides)

Sandro: Interoperability without rule exchange?

Michael: Send just queries, not rules themselves.

Igor: Why do you need RIF if rules are not interchanged, but just queries passed (like web services)?

Michael: Analogy: XML scheme import vs. include.

csma: Predefined set of languages or just a set of features?

Michael: Predefined set of languages (with given features).

SWRL (Peter Patel-Schneider) (slides)

Harold: Semantics cannot be operational?

Peter: Spec is not operational, implementation is.

JosdeBruijn: Do you consider stable model semantics simple?

Peter: No! Any non-monotonic semantics must include preference relation, but stable models is questionable as far as simplicity is concerned.

csma: No XML dialect for syntax?

Peter: Just functional style syntax (abstract).

csma: Human readable syntax is one of the targets?

Peter: Human readable syntax (parenthesized, functional) is good enough for RIF.

Production Rules (Paul Vincent) (slides)

Sandro: Are their logical interpretation of PRs in some cases?

Paul: can simulate logical behavior with PR

Christian:  distinction between rules specifying and rules executing. 

Sandro:  any interoperability btwn PR and non-PRS?

Paul:  sometimes, e.g. constraints,  a research topic.

Francois: clarification:  do you want to represent PRs within RIF or is RIF a PR lang?

Paul:  the former; source and target need be PR, not necessarily RIF

Hassan:  these (slides) are design goals for representing PR in the RIF

Michael Kifer:  how is OCL used in framework?

Paul:  A possible source lang for RIF (map PRR OCL into RIF), as an expression lang.

Hassan:  OCL used for data model, not in rules themselves.

Christian:  scoping of rules similar to issue of non-monoticity of working memory?

Chris: an open issue

Human-Oriented use case (John Hall) (slides)

Francois: Opens many interesting use cases.

csma:  interchange necessary not for inference, so you do not need a ruleset to have any logical or computational properties.

John:   you need to able to keep relations on rulesets.  For example to trace decsions come from.

csma: How do human-oriented rules differ from others?  Rule is either a logical rule or a prod rule. 

John: Structural rules can be used for guidance, for decision support by people.

Frank: it may not be obvious what the rules are in an organization.  Need meta-rule that says for a given query these are the rules to consider.

John:  this has consequences in the business world

csma: maybe what makes these rules different are that the predicates, atoms, contents are not evaluated by machine, but the rule structure themselves are logical

Discussions (20 min)

Frank: PR and FOL: what's the relationship?

Giorgos:  Process change, List requirements by priority, then do design goals.

Chris: we haven't decided on req yet.  This is the still preliminary discussion.

Uli:  other design goals besides req. , rule syntax should be nice.  Req. should also be "what I cannot live without."

Sandro:  We come up with list of req. and then do a straw poll with those kinds of possible responses.

Chris:  this is a preliminary discussion.  We are just getting perspectives.

Harold:  design goals presentors did not say which design goals were supported by the current User Cases.

Chris: Tying design goals to Use-cases (should be done).  Presentations were only 15 minutes.

Peter:  not all need to be tied to UCs.  A RIF has design goals imposed by fact that it is a rule language.

Chris:  qua member,  HUman ORiented rule stuff still makes me very unconformtable.  Dealing with rules to be interpreted by people seems like a disaster...

Donald:  UC is not mainly about human interpreted rules.  Rules for running a large org. 

Chris:  main req added seems to be for modal operators.

Donald: also higher order logic stuff.

John:  RIF should allow to distinguish whether you are talking about the real thing or the IT object

Francois:  have a rich set of logical connectives and have a way of marking rules with tags for modals.  We can look at a practical way of satisfying req of ucs. 

Chris:  human readable syntax not necessary.  Just that they should be interpretable,,, 

Donald:  can do without human readable syntax.

Francois:  when you write a java prog it is for human beings.

Chris:  but it is not a req.

Francois:  you don't need modal logic to express modalities on rules.    That is what those applications need and it is in scope

Harold:  Semantic Beaver (SBVR) is a formal but somewhat natural lang.  Talk to OMG people.

Donald:  SBVR can all be done in FOL. 

Harold:  But we start with Horn Logic.

Donald:  main point is that all rules will be formally representable.

Harold:  do you have a family of language?

John:  we have a formal model for SBVR (Terry Halpin).

Donald:  it is underpinned by a dialect of COmmon Logic.

Herman:   I am a bit scared about the human interpretation. Human are not perfect reasoners (imperfect rule engine); consequences?

John: Why are you worried? A good rule is one that helps the business