01:07:35 sandro has joined #rif 14:06:47 msintek has joined #rif 14:07:02 cgi-irc has joined #rif 14:07:37 sandro has joined #rif 14:08:16 csma has joined #rif 14:08:26 PaulV is scribe 14:08:30 DaveReynolds has joined #rif 14:08:35 RRSAgent, pointer? 14:08:35 See http://www.w3.org/2006/11/05-rif-irc#T14-08-35 14:08:40 scribeNick: PaulVincent 14:09:02 Continuing UC&R discussion 14:09:13 cgi-irc has joined #rif 14:11:17 Item 10: extensible format for rules - discussion - proposed - for upward compatibility of dialects 14:13:34 PaulV has joined #rif 14:14:15 ChrisW has joined #rif 14:14:24 Discussion on bwd compatibility 14:14:43 Christian: suggested need for fwd compatibility 14:14:55 John: need to define dialect first 14:15:17 ChrisW has changed the topic to: 5 Nov RIF F2F4 Agenda: http://www.w3.org/2005/rules/wg/wiki/F2F4 14:15:35 mdean has joined #rif 14:16:20 John: May need to add new dialects as well as extend existing ones... 14:16:29 MikeDean and BenjaminGrosof are teaching a tutorial today 14:16:33 GaryHallmark has joined #rif 14:16:34 josb has joined #rif 14:16:55 Christian: ... but RIF extensions / dialects may or may not be standardised 14:18:39 DaveR: Need to consider fwd/bwd compatibility for tech design of RIF 14:23:35 Proposed wording: It must be extensible to add new dialects of RIF. It must be possible to extend the standard RIF dialects. 14:25:14 ACTION: on Alex to list (clarify) issues raised by this requirement 14:25:14 Sorry, couldn't find user - on 14:26:11 ACTION: Alex to list (clarify) issues raised by the extensibility requirement 14:26:11 Created ACTION-170 - List (clarify) issues raised by the extensibility requirement [on Alex Kozlenkov - due 2006-11-12]. 14:26:18 Alan: topic on merging rulesets: <> 14:29:08 Christian: is this a requirement on RIF vs a requirement to avoid precluding merging 14:31:13 "RIF must support effective merging of rule sets" 14:33:06 Laura: Merging may require metadata to support effective merging 14:34:57 s/Laura/Leora 14:35:22 GaryH: merging is a fn of the rule engine / system 14:36:05 "RIF should not impair the ability to merge rule sets" 14:36:19 Leora: ... but the choices for rule consolidation may require additional metadata etc from the rule sources 14:38:06 Option1: RIF should not prevclude the abulity to merge rule sets 14:38:22 Option 2: RIF should support the ability to merge rule sets 14:39:04 RIF should admit the ability to merge rule sets 14:39:13 RIF should facilitate the ability to merge rule sets 14:42:06 LeoraMorgenstern has joined #rif 14:42:41 PaulV: RIF should support the necessary constructs to support merging of rule sets 14:42:52 facilitate 14:43:13 Hassan: RIF should facilitate the merging of rule sets 14:45:31 RESOLVED: RIF should support the ability to merge rule sets 14:46:14 Proposal - RIF will support the identification and processing of rulesets 14:46:45 Christian: but this mentions processing ... 14:48:39 RESOLVED: RIF will support the identification of rule sets. 14:50:05 ------- DaveR: overview of breakout on Syntax 14:51:18 PROPOSED: RIF will use URIs (IRIs) in the style of RDF and OWL to identify at least predicates, functions, datatypes, constants, rules, rulesets. 14:51:54 JosD has joined #rif 14:52:42 DaveR presenting http://lists.w3.org/Archives/Public/public-rif-wg/2006Nov/0017.html 14:53:32 PROPOSAL2: 14:54:33 JosDB: But namespace prefixes aren't preserved 14:54:49 Peter: "accidental capture" 14:55:09 Peter: I don't see that as a problem. That's a stupid-translator thing. 14:56:03 PROPOSAL2: Translators to and and from languages which do not use URIs as names will need to use namespace prefixes or other name-mapping system 14:57:51 mkifer: does this preclude local names for constants? 14:58:20 Christian: Locals do not need URIs 14:59:04 mkifer: some constants should not be exposed. 15:01:40 peter: make it "identifiers of" 15:02:02 mkifer: not precluding the idea of local names. 15:03:29 JosD has joined #rif 15:03:31 text "globally named" inserted 15:04:16 Hassan has joined #rif 15:04:22 An Introduction to XML and Web Technologies (Paperback) 15:04:22 by Anders Moller, Michael Schwartzbach 15:05:25 Sorry, I meant to post: http://www.cs.ucsd.edu/~goguen/projs/inst.html 15:05:39 Names should be global or local. If global, use URIs. 15:05:52 DaveR: Local names are a separate discussion 15:06:11 "Institutions" are a formal means to manage "signatures" (i.e., local, global naming) 15:08:19 RESOLVED: RIF will use URIs ... as per e-mail modifed with "globally named", and projected on Dave's slide 15:09:10 proposal 2 -- RIF will provide metadata vocabulary for recording mapping. 15:09:13 Harold has joined #rif 15:09:24 "extensible" 15:14:18 PaulV: so there can be a JSR which says how to use JSR-94 with RIF and say what these bindings are 15:15:33 Gary: relationship to Java rule engines working against Java objects 15:15:51 Dave writes: This metadata annotation meschanism should be extensibike to allow groups outside RIF to agree on such annotations 15:16:05 Peter: not sure what that means, .... 15:16:12 Dave withdraws it 15:17:22 Gary: So when I get a ruleset with annotations linking stuff to Java fields, I need to understand it 15:17:35 Dave: No, it's not semantically significant 15:17:47 Chris: Well, it is significant if you're Java. 15:18:20 PaulV: we need to elaborate this against use cases... 15:18:39 PaulV: I agree with Gary, it would be much nicer to have java objects referenced in rules, instead of mapping from URIs. 15:19:10 Christian: I don't agree. If we interchange directly the names of java classes, that restricts use. 15:19:34 PaulV: True, but that assumes an extranet use of RIF 15:19:52 PaulV: I'd just like us to explore this, in terms of examples. 15:20:01 Chris: What document might this go in. 15:20:37 Dave: This is not text for a document. It's a WG resolution, to let us move forward into the details. 15:21:39 Dave: Some document will present the vocabular and explain this. 15:21:54 RESOLVED: NAMING-BREAKOUT-PROPSAL-2 15:22:06 WorkItem: local names 15:22:30 Proposed Issue about round tripping. 15:22:41 How should we map constants from an example like this? Legacy Rulebase 1: invaded(GaiusJuliusCaesar,Britain). Legacy Rulebase 2: crossed(GaiusJuliusCaesar,Rubicon). Suggestion: An 'object-detection' mechanism (outside the scope of RIF) could make a 'global name' assumption for the symbol GaiusJuliusCaesar of both rulebases and map them to a single IRI in RIF (such as to http://en.wikipedia.org/wiki/Julius_Caesar). 15:22:53 Chris: What would the closing criteria be? 15:23:19 Dave: Is requirements on the round-tripping. 15:24:04 Sandro: semantic rounttripping / performance roundtripping / syntactic sugar roundtripping... are all possible requmts 15:25:46 Issue: Which rule features (semantic, syntactic, performance, ...) survive round-tripping? 15:26:28 Allen: this is a requirement on the translators, or on the spec 15:27:40 Chris: need an action on a chair to Debra on roundtripping... 15:28:17 ACTION: Sandro talk to Deborah about getting this issue on the issues list 15:28:17 Created ACTION-171 - Talk to Deborah about getting this issue on the issues list [on Sandro Hawke - due 2006-11-12]. 15:46:22 JosD has joined #rif 16:00:13 Allen has joined #rif 16:00:37 Peter, any chance we can get a projector cable for the room next door, if we have another breakout there? 16:01:12 RRSAgent, make record public 16:02:22 kifer_ has joined #rif 16:02:43 AllenG has joined #rif 16:03:44 GiorgosStoilos has joined #rif 16:03:51 kifer_ has joined #rif 16:04:12 Scribenik: MichaelKifer 16:04:16 AxelPolleres has joined #rif 16:04:54 ScribeNick: kifer_ 16:05:58 Alex: why the "a" in "All standard RIF dialects havbe a precise syntax and semantics" 16:06:22 (recaping the decisions): CORE will be positive horn 16:06:35 (proposal) 16:06:52 Code and dialects will have precise semantics 16:07:09 RESOLVED: RIF will provide a framework for defining RIF dialects 16:07:17 s/Code/Core 16:07:25 RIF will provide a framework for defining RIF dialects (resolved) 16:07:55 csma: I support this proposal because I was convinced that this was doable and anything else would be a research project 16:08:05 s/havbe/have 16:08:28 agrees with the resolutions not because he prefers this way, but because it would be a research project otherwise 16:08:41 Chris: With any resolution, we can reconsider it if there is new evidence 16:08:54 Chris: "is slotted syntax positive Horn" 16:09:59 Chris: The resolution about Horn does not preclude discussions about slotted, datatypes, disjunction in the body -- we can still have discussion about whether those are positive Horn. 16:10:13 CORE is positive Horn from now on - no further discussion about that. What is still open are things like slotted syntax, data types, disjunctions in the body, conjunctions in the head. 16:10:14 Chris: So "negation in core" will not longer be a subject for discussion. 16:10:45 RESOLVED: The RIF CORE will be positve Horn. 16:11:07 Christian: Now I will begin a research project to overturn this resolution! [joking] 16:11:32 ag has joined #rif 16:11:36 Chris: We need negation in Phase 1 to be useful. 16:11:46 Chris: and should be easy 16:12:05 Chris: negation is easy to do in the context of dialects. 16:12:18 Chris: we know how to extend positive horn with NAF and First-Order Negation. 16:12:45 Scribenik: kifer_ 16:14:07 MarkusK has joined #rif 16:15:02 Sandro: So this means the Rec, a year from now, will include at least two dialects, probably three --- Core, Core+NAF, Core+CNeg 16:15:11 Paul: What's the motivation? 16:15:48 Christian: Examples of rulesets seem to always include negation. 16:16:24 csma: negation is important for practical applications 16:17:41 Gary: core by itself is not very useful 16:18:09 chris: whoever wants a particular dialect must work on it 16:21:23 daveR: are we sanctioning an open season on adding new dialects? 16:22:01 chris: each new dialect must be checked agains the requirement of "limited # of dialects" 16:23:42 Sandro: We can overlap work -- working on dialects on Phase 1 16:24:11 Sandro: we can build new dialects in phase 1 without having to get them through to Recommendation. 16:30:46 all: discussion of whether some dialects should be in the phase1 rec 16:31:28 PROPOSED: WG will define RIF dialects in Phase 1, eg including negation, not necessarily in a Rec. 16:32:24 csma (with ilog hat): not necessary to have dialects in the rec, but reasonable drafts of some dialects are needed 16:35:04 The Positive Condition Language can be regarded as a Subcore that can be used as the building block for both Positive Horn Rules and for Positive Production Rules (which also need actions / state change). An extended Condition Language with Negation can then become the building block for both a dialect of an extended Horn Rules with Negation and a dialect of Production Rules with Negation. This 'lego' block approach allows the reuse of dialects. Here, both the 16:36:03 Positive Condition Language and the Condition Language with Negation are used twice. 16:36:08 PROPOSED: WG will define useful RIF dialects in Phase 1, eg including negation, not necessarily in a Rec. 16:36:28 RESOLVED: WG will define useful RIF dialects in Phase 1, eg including negation, not necessarily in a Rec. 16:36:48 RESOLVED: Phase 1 will include drafts of some useful dialects 16:39:36 afternoon breakouts: 16:39:44 1. abstract syntax and semantics 16:40:15 2. Extensibility of syntax 16:40:56 rifraf - can work on OWL ontology of rifraf or start outlining dialects 16:41:11 4. Test cases 16:42:36 s/rifraf/3. RIFRAF/ 17:00:14 JosD has joined #rif 17:43:08 sandro has joined #rif 17:56:11 JosD has joined #rif 18:11:42 mdean has joined #rif 18:32:50 JosD has joined #rif 19:14:07 JosD has joined #rif 19:33:59 MarkusK has joined #rif 19:34:09 ChrisW has joined #rif 19:36:13 GaryHallmark has joined #rif 19:37:19 GaryHallmark has left #rif 19:37:28 GaryHallmark has joined #rif 19:37:47 MarkusK has left #rif 19:37:48 nothing happens? 19:37:51 MarkusK has joined #RIF 19:38:13 cgi-irc has joined #rif 19:38:40 DaveReynolds has joined #rif 19:38:44 msintek has joined #rif 19:38:46 Hassan has joined #rif 19:38:58 josb has joined #rif 19:39:29 ScribeNick: msintek 19:39:52 RRSAgent, pointer? 19:39:52 See http://www.w3.org/2006/11/05-rif-irc#T19-39-52 19:41:33 Topic: next F2F 19:42:38 CMSA: is Innsbruck F2F6? 19:44:31 large objection for additional F2F between MIT and Innsbruck meetings 19:45:50 2nd half of February is preferred for F2F5 19:46:45 3 days more useful than 2? 19:47:37 GiorgosStoilos has joined #rif 19:48:08 voice feeds needed? 19:50:56 Allen needs to know 2 vs 3 days etc. 19:54:20 Allen will specify deadline for decision 19:55:35 weekend probably not possible 19:56:22 Topic: reports from breakout sessions 19:56:28 csma and leora express desire to avoid meetings on weekends 19:58:04 Axel reporting from RIFRAF 19:58:26 starting points: bottom-up vs. top-down 19:59:31 ... do both directions 20:00:30 Action: Sandro will provide template 20:00:30 Created ACTION-172 - Will provide template [on Sandro Hawke - due 2006-11-12]. 20:01:46 msintek, please try to keep actions detailed enough to make sense out of context. 20:01:51 DaveReynolds has joined #rif 20:02:50 (i edited 172 on the web to be "Provide template for authoring RIFRAF instance data") 20:03:50 Axel: procedure to collect next interation 20:06:37 ... slides contain list of people to work on specific sections 20:08:58 CSMA: deadline: mid december 20:09:40 (Sandro will put actions in the system) 20:11:54 CSMA: what is REWERSE classification 20:13:12 Axel: will make clear how discriminators are related 20:13:32 ACTION: Leora to revise and ontologize RIFRAF, section 1 due 2006-11-30 20:13:32 Created ACTION-173 - Revise and ontologize RIFRAF, section 1 due 2006-11-30 [on Leora Morgenstern - due 2006-11-12]. 20:14:42 CSMA: is there impact on the design of the core? 20:15:13 Axel: in the end, dialects fit in the framework as well 20:16:37 ACTION: Hassan to revise and ontologize RIFRAF, section 2 - due 2006-12-15 20:16:37 Created ACTION-174 - revise and ontologize RIFRAF, section 2 [on Hassan Ait-Kaci - due 2006-12-15]. 20:16:38 Hassan and others: discussion of what will be mapped (dialects as abstract systems etc.) 20:16:46 ACTION: Allen to revise and ontologize RIFRAF, section 3 - due 2006-11-30 20:16:46 Created ACTION-175 - revise and ontologize RIFRAF, section 3 [on Allen Ginsberg - due 2006-11-30]. 20:16:55 ACTION: Sandro to revise and ontologize RIFRAF, section 4 - due 2006-11-30 20:16:55 ACTION: Paula to revise and ontologize RIFRAF, section 5 - due 2006-11-30 20:16:55 ACTION: Axel to propose and ontologize RIFRAF on negation - due 2006-11-30 20:16:55 ACTION: Axel ask Frank if he'll revise and ontologize Section 6 - due 2006-11-30 20:16:55 Created ACTION-176 - revise and ontologize RIFRAF, section 4 [on Sandro Hawke - due 2006-11-30]. 20:16:55 Sorry, couldn't find user - Paula 20:16:56 Created ACTION-177 - propose and ontologize RIFRAF on negation [on Axel Polleres - due 2006-11-30]. 20:17:00 Created ACTION-178 - ask Frank if he\'ll revise and ontologize Section 6 [on Axel Polleres - due 2006-11-30]. 20:17:25 ACTION: Paula-Lavinia to revise and ontologize RIFRAF, section 5 - due 2006-11-30 20:17:25 Created ACTION-179 - revise and ontologize RIFRAF, section 5 [on Paula-Lavinia Patranjan - due 2006-11-30]. 20:17:28 Harold will be asked to review ontology 20:18:18 Dave: reporting back from the "whatever" :-) group 20:18:24 Harold has joined #rif 20:19:05 (i.e., group on dialects ....) 20:19:38 ... rule components: core = variable decl, antecedent, consequent 20:19:51 ... dialects might add further 20:20:11 ... dialects: starter set = lp, pr, fol 20:20:23 ... is FOL in scope 20:20:51 ... lp purity (prolog sub-dialect of lp?) 20:21:09 ... led to disc. on ordering 20:21:30 ... which was discussed a lot 20:22:08 ... by default, synt. ordering not preserved; ordering construct will be provided 20:22:22 PaulaP has joined #rif 20:22:30 ... needed for dialects with order-dep. semantics 20:23:22 Paul: Why not order? 20:24:01 Dave: Because merging is much harder with ordering. 20:24:46 Dave: being unordering is a nice property for distributed things. 20:25:18 [ This is not written as a proposal, yet ] 20:25:27 Dave: syntax extensions 20:25:57 ... all rif standard dialects should use a common rif syntax, extending only where necessary 20:27:04 ... syntax extension mechanisms: XML substitution groups / RDF 20:27:50 ... is RDF permissable as XML syntax? 20:28:08 ... charter just says "normative xml syntax" 20:28:18 ... csma interprets this as xml schema 20:28:54 ... dave: rdf metadata opens door to use rdf 20:30:00 ... has to be decided 20:31:15 Issue: decide on XML Schema vs. RDF/XML as concrete syntax conforming to charter 20:32:22 Dave: extensions: need notion of common libraries (e.g., mathematical operators)= 20:33:48 (clarified that SOME mathematical operators might be in core.) 20:34:25 csma: are there other views on this? 20:34:35 Peter: common syntax: not rdf? 20:35:01 Sandro: how do you introduce new operators? 20:35:48 ... played with XML Schema: addition seems to be very difficult 20:36:16 CSMA: in some cases doable with subst. groups 20:37:39 Sandro: RelaxNG probably ok 20:38:59 CSMA: essence is that for new dialects one builds on a common syntax: goal: even if dialects are developed in parallel this will not end in chaos 20:39:32 s/ok/ok for RIF to use, if we really want/ 20:42:16 Alex: importance of keeping the provenance when merging rule sets 20:42:37 BREAK! 20:42:39 msintek has left #rif 20:44:47 msintek has joined #rif 20:49:38 PaulaP has joined #rif 20:50:06 DaveReynolds has joined #rif 21:01:02 test 21:04:40 AxelPolleres has joined #rif 21:04:53 Reporting from the session on technical design - semantics 21:05:32 AxelPolleres has left #rif 21:05:54 and abstract syntax 21:06:25 Christian: we should also discuss plans for the next spec and WD 21:06:40 Harold: focus on work by Hassan 21:07:09 Harold: slots and constraints as main building blocks 21:08:14 Harold: ideas to generalize existing proposal towards CLP 21:08:49 Harold: a generalized slotted syntax is presented 21:09:42 Harold: Herbrand atoms can be enriched by slotted atoms 21:10:53 ...and Herbrand terms by slotted terms 21:11:53 Harold: the slides will be also available, so no need to write details 21:12:07 ...in the session's minutes 21:13:31 Christian: what about the quantification part? Is it also covered? 21:13:41 Chris: it is not in this proposal 21:14:11 Christian: the quantification part contains also constraints on the variables and their types 21:14:37 Chris: it is a placeholder for possible extensions 21:15:33 Christian: Does this mean that we have now 4 parts in a rule? 21:15:46 Harold: yes 21:16:59 Sandro: What means canonical here? 21:17:17 Chris: it is a normative one actually here 21:18:00 Christian: to be rephrased - if a model theory exists it should be normative 21:18:20 Chris: go back and start with the syntactic part so as to take decisions 21:18:26 Suggested and probably approved: If there is a model theory, it is normative. If there is no model theory, but a proof therory, it is normative. If there is niehter, but an operational semantics, it is normative. 21:19:27 Hassan: slotted terms are more general than Herbrand terms 21:19:56 ...and have a bsic data model based on constraints 21:20:13 s/bsic/basic 21:20:57 Alex: It is required to make constraints explicit? 21:21:14 Chris: the non-constraint part is positional 21:21:35 Hassan: we could also propose a kind of black-box approach for constraints 21:21:53 Christian: we have two levels of shorthands 21:22:19 Sandro: I'm very happy with this design 21:22:41 Dave: it seems you have orthogonal things here 21:22:57 Hassan: the abstraction mechanism is based on constraints 21:23:24 Chris: it is in the charter to support slotted terms 21:23:38 Jos: is this the reason also for introducing constraints? 21:23:46 Jeff: but why in the core? 21:23:58 The design I'm seeing that I like is that by definition p(x,y,z) = p{1->x, 2->y, 3->z}. 21:24:01 Hassan: the core gives just the abstraction mechanism 21:24:49 I wonder if we need a URI for "1". :-) :-) (and yet very serious.) 21:24:58 Jos: constraints in the core are of very limited nature 21:25:54 Jeff: can you provide references for the fact that datatypes can also be based on the proposed mechanism? 21:26:04 Hassan: yes, of course 21:26:22 Jeff: I need to read these documents first 21:26:49 Jos: need also to take a look at examples and use cases 21:27:06 Christian: you do not define formula in this approach 21:27:17 Alex: do you need a constraint solver? 21:27:28 Hassan: no, you don't 21:28:06 Chris: e.g. typing constraints can be mapped to something that understands such kinds of constraints 21:28:20 Michael K: typing is another issue 21:28:58 Alex: what is the difference between typing constraints and these presented in the proposal? 21:29:16 Alex: what about OWL? 21:29:33 Michael K: we talk here about another types of constraints 21:29:45 Hassan: typing can be also dynamic 21:30:00 ...for example to narrow search 21:30:34 Christian: we need to have an abstract syntax for the RIF core 21:30:56 ...and the semantics so as to understand this proposal 21:31:26 Hassan: this is simply an abstraction mechanism for specifying specific things 21:31:46 Harold: we have conjunction formulas 21:31:58 LeoraMorgenstern has joined #rif 21:32:06 ...in this proposal that are based on very simple constraints 21:32:19 ...we need just simple constraints in the core 21:32:33 Sandro: clarify what kind of decision we need here 21:33:05 ...is there any reason for objecting to this proposal? 21:33:18 Jos: I need to see details 21:33:35 Alex: practical significance of introducing constraints 21:33:54 Chris: it can't be worse than the existing proposal 21:34:25 Alex: we need some nice examples for representing data models with constraints 21:35:08 Michael K: are you asking about documents on why CLP is useful? 21:35:12 Alex: no 21:35:53 Christian: can you provide examples of rules where you would like to see a translation using constraints? 21:36:01 ...would that help? 21:36:28 Chris: constraints are completely optional 21:36:49 Sandro: but if I receive a constraints I have to handle it!! 21:37:04 Chris: constraints can be empty 21:37:50 Christian: the instantiation of the constraint part in the core is true? 21:38:37 Hassan: if you need to represent data models, you can have the constraints as a kind of built-in 21:39:30 Christian: would it help is Hassan provides concrete examples? 21:39:43 s/is/if 21:40:10 Jeff: we need to be clear what this extension brings 21:40:36 Chris: I don't understand what you don't understand 21:41:07 Peter: if the constraint is empty you don't get the core! 21:41:47 Chris: we have a set of constraints that map Herbrand terms to slotted terms 21:41:59 Chris: no, actually not 21:42:20 Chris: THE ONLY CONSTRAINTS YOU CAN WRITE, IN THE CORE, ARE THE ONES IN GREEN 21:42:35 Chris: we may have also other kinds of constraints 21:42:39 ...later on 21:43:28 ...restricted set of constraints for the core 21:43:46 JosD has joined #rif 21:43:53 Jos: I'm fine with this clarification 21:44:13 Jeff: I need something written 21:44:32 Axel: can you also map back to Herbrand terms? 21:45:08 Michael K: this is just theoretical 21:45:37 Hassan: yes, for Axel's question 21:46:02 Christian: what is the condition for this proposal to be accepted or not? 21:46:24 Jeff: I need to see something in the wiki 21:46:44 Alex: together with references from the literature 21:46:56 ...and also mention some benefits 21:47:20 Hassan: we have now slotted terms 21:47:51 Michael K: other kinds of constraints may be part of the core 21:48:59 ACTION: Harold to edit a wiki page for the proposal on extending the existing work with constraints 21:48:59 Created ACTION-180 - Edit a wiki page for the proposal on extending the existing work with constraints [on Harold Boley - due 2006-11-12]. 21:50:31 Chris: objections to the semantic hierarchy slide? 21:50:55 Christian: the normative semantics will be the model theory 21:51:31 Chris: The WG will follow this, and we will recommend it to others. 21:51:32 Sandro: what if somebody declares the proof theory for a dialect as being the normative semantics? 21:51:47 Chris: they are not RIF-compatible 21:53:01 Gary: why not in the case of multiple existing theories just say which one is normative? 21:53:15 Dave: +1 to Gary's point 21:53:41 Peter: this is wrong 21:54:40 ...the dialect for production rules will come just with operational semantics 21:54:50 Sandro PROPOSED: In the RIF-WG, model theories will be normative; in their absense it will be proof theories; in the absense of both it will be operation semantics. 21:54:54 Sandro: suggest another wording 21:55:28 Jos: you didn't say anything about dialects 21:55:58 Peter: a formal specification is a formal specification for something 21:56:15 PROPOSED: For standard RIF dialects, model theories will be normative; in their absense it will be proof theories; in the absense of both it will be operation semantics. 21:57:14 Christian: if you want the operational semantics as normative, then you simply don't give a model and a proof theory 21:57:55 Peter: but we could reject such a dialect if we think that such a model or proof theory for this dialect exists 21:58:30 Gary: if they are 3, programmers will read just the operational semantics 21:59:00 Sandro: the semantics hierarchy gives us guidance 21:59:14