See also: IRC log
Remotely:Mike Dean (on IRC until noon)
Observers:Christine Golbreich <Christine.Golbreich@univ-rennes1.fr> (not affiliated to a W3C Member) : attending monday, tuesday
(Chair: Christian de Sainte Marie; Scribe: Sandro
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
... One of the objectives of this meeting is to have people talk to each other, including in small groups. Thus the long lunch break.
(Chair: Christian de Sainte Marie; Scribe: Gary
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
allen: now named business process design
... rif would help redesign or improve biz process
frank: tried to make the case more compelling
frank: driver: dynamic integration of
... 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
<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
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
...suggested: 2.2 Ruleset Integration for Medical Decision Support
...suggested: 2.Interative User Training Via Reactive Rules
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.
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!
<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
are they cases where
you do the integration by hand now?
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
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
...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)
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.
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).
1. this UC should concentrate on the
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.
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
csma: Should this go into a UC? Recognizing a common data model is ok, but more?...
...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.
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.
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.
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).
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.
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?
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
Chris: an open
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
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
rich set of logical connectives and have a way of marking rules with
modals. We can look at a practical way
of satisfying req of ucs.
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.
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
John: Why are you worried? A
good rule is one that helps the business