See also: IRC log
<PaulVincent> scribe: PaulV
Continuing UC&R discussion
Item 10: extensible format for rules - discussion - proposed - for upward compatibility of dialects
Discussion on bwd compatibility
Christian: suggested need for fwd compatibility
John: need to define dialect first
... May need to add new dialects as well as extend existing ones...
<sandro> MikeDean and BenjaminGrosof are teaching a tutorial today
Christian: ... but RIF extensions / dialects may or may not be standardised
DaveR: Need to consider fwd/bwd compatibility for tech design of RIF
Proposed wording: It must be extensible to add new dialects of RIF. It must be possible to extend the standard RIF dialects.
<scribe> ACTION: on Alex to list (clarify) issues raised by this requirement [recorded in http://www.w3.org/2006/11/05-rif-irc]
<rifbot> Sorry, couldn't find user - on
<sandro> ACTION: Alex to list (clarify) issues raised by the extensibility requirement [recorded in http://www.w3.org/2006/11/05-rif-irc]
<rifbot> Created ACTION-170 - List (clarify) issues raised by the extensibility requirement [on Alex Kozlenkov - due 2006-11-12].
Alan: topic on merging rulesets: <<RIF processing should include the ability to merge rulesets>>
Christian: is this a requirement on RIF vs a requirement to avoid precluding merging
<sandro> "RIF must support effective merging of rule sets"
Leora: Merging may require metadata to support effective merging
GaryH: merging is a fn of the rule engine / system
<sandro> "RIF should not impair the ability to merge rule sets"
Leora: ... but the choices for rule consolidation may require additional metadata etc from the rule sources
<sandro> Option1: RIF should not prevclude the abulity to merge rule sets
<sandro> Option 2: RIF should support the ability to merge rule sets
<sandro> RIF should admit the ability to merge rule sets
<sandro> RIF should facilitate the ability to merge rule sets
<sandro> PaulV: RIF should support the necessary constructs to support merging of rule sets
<sandro> facilitate
<sandro> Hassan: RIF should facilitate the merging of rule sets
<sandro> RESOLVED: RIF should support the ability to merge rule sets
Proposal - RIF will support the identification and processing of rulesets
Christian: but this mentions processing ...
<sandro> RESOLVED: RIF will support the identification of rule sets.
------- DaveR: overview of breakout on Syntax
PROPOSED: RIF will use URIs (IRIs) in the style of RDF and OWL to identify at least predicates, functions, datatypes, constants, rules, rulesets.
<sandro> DaveR presenting http://lists.w3.org/Archives/Public/public-rif-wg/2006Nov/0017.html
PROPOSAL2:
<sandro> JosDB: But namespace prefixes aren't preserved
<sandro> Peter: "accidental capture"
<sandro> Peter: I don't see that as a problem. That's a stupid-translator thing.
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
<sandro> mkifer: does this preclude local names for constants?
Christian: Locals do not need URIs
<sandro> mkifer: some constants should not be exposed.
<sandro> peter: make it "identifiers of"
<sandro> mkifer: not precluding the idea of local names.
<sandro> text "globally named" inserted
<Hassan> An Introduction to XML and Web Technologies (Paperback)
<Hassan> by Anders Moller, Michael Schwartzbach
<Hassan> Sorry, I meant to post: http://www.cs.ucsd.edu/~goguen/projs/inst.html <http://www.cs.ucsd.edu/%7Egoguen/projs/inst.html>
<sandro> Names should be global or local. If global, use URIs.
DaveR: Local names are a separate discussion
<Hassan> "Institutions" are a formal means to manage "signatures" (i.e., local, global naming)
<sandro> RESOLVED: RIF will use URIs ... as per e-mail modifed with "globally named", and projected on Dave's slide
<sandro> proposal 2 -- RIF will provide metadata vocabulary for recording mapping.
<sandro> "extensible"
<sandro> PaulV: so there can be a JSR which says how to use JSR-94 with RIF and say what these bindings are
Gary: relationship to Java rule engines working against Java objects
<sandro> Dave writes: This metadata annotation meschanism should be extensibike to allow groups outside RIF to agree on such annotations
<sandro> Peter: not sure what that means, ....
<sandro> Dave withdraws it
<sandro> Gary: So when I get a ruleset with annotations linking stuff to Java fields, I need to understand it
<sandro> Dave: No, it's not semantically significant
<sandro> Chris: Well, it is significant if you're Java.
<sandro> PaulV: we need to elaborate this against use cases...
<sandro> PaulV: I agree with Gary, it would be much nicer to have java objects referenced in rules, instead of mapping from URIs.
<sandro> Christian: I don't agree. If we interchange directly the names of java classes, that restricts use.
<sandro> PaulV: True, but that assumes an extranet use of RIF
<sandro> PaulV: I'd just like us to explore this, in terms of examples.
<sandro> Chris: What document might this go in.
<sandro> Dave: This is not text for a document. It's a WG resolution, to let us move forward into the details.
<sandro> Dave: Some document will present the vocabular and explain this.
<sandro> RESOLVED: NAMING-BREAKOUT-PROPSAL-2
<sandro> WorkItem: local names
<sandro> Proposed Issue about round tripping.
<Harold> 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).
<sandro> Chris: What would the closing criteria be?
<sandro> Dave: Is requirements on the round-tripping.
Sandro: semantic rounttripping / performance roundtripping / syntactic sugar roundtripping... are all possible requmts
<sandro> Issue: Which rule features (semantic, syntactic, performance, ...) survive round-tripping?
<sandro> Allen: this is a requirement on the translators, or on the spec
Chris: need an action on a chair to Debra on roundtripping...
<sandro> ACTION: Sandro talk to Deborah about getting this issue on the issues list [recorded in http://www.w3.org/2006/11/05-rif-irc]
<rifbot> Created ACTION-171 - Talk to Deborah about getting this issue on the issues list [on Sandro Hawke - due 2006-11-12].
<sandro> Peter, any chance we can get a projector cable for the room next door, if we have another breakout there?
<kifer_> Scribenik: MichaelKifer
<sandro> ScribeNick: kifer_
<sandro> Alex: why the "a" in "All standard RIF dialects have a precise syntax and semantics"
<chris> (recaping the decisions): CORE will be positive horn
<sandro> (proposal)
Core and dialects will have precise semantics
<sandro> RESOLVED: RIF will provide a framework for defining RIF dialects
RIF will provide a framework for defining RIF dialects (resolved)
<sandro> csma: I support this proposal because I was convinced that this was doable and anything else would be a research project
<scma> agrees with the resolutions not because he prefers this way, but because it would be a research project otherwise
<sandro> Chris: With any resolution, we can reconsider it if there is new evidence
<sandro> Chris: "is slotted syntax positive Horn"
<sandro> 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.
<Chris> 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.
<sandro> Chris: So "negation in core" will not longer be a subject for discussion.
<sandro> RESOLVED: The RIF CORE will be positve Horn.
<sandro> Christian: Now I will begin a research project to overturn this resolution! [joking]
<sandro> Chris: We need negation in Phase 1 to be useful.
<sandro> Chris: and should be easy
Chris: negation is easy to do in the context of dialects.
<sandro> Chris: we know how to extend positive horn with NAF and First-Order Negation.
Scribenik: kifer_
<sandro> Sandro: So this means the Rec, a year from now, will include at least two dialects, probably three --- Core, Core+NAF, Core+CNeg
<sandro> Paul: What's the motivation?
<sandro> Christian: Examples of rulesets seem to always include negation.
csma: negation is important for practical applications
Gary: core by itself is not very useful
chris: whoever wants a particular dialect must work on it
daveR: are we sanctioning an open season on adding new dialects?
chris: each new dialect must be checked agains the requirement of "limited # of dialects"
<sandro> Sandro: We can overlap work -- working on dialects on Phase 1
<sandro> Sandro: we can build new dialects in phase 1 without having to get them through to Recommendation.
all: discussion of whether some dialects should be in the phase1 rec
<sandro> PROPOSED: WG will define RIF dialects in Phase 1, eg including negation, not necessarily in a Rec.
csma (with ilog hat): not necessary to have dialects in the rec, but reasonable drafts of some dialects are needed
<Harold> 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
<Harold> Positive Condition Language and the Condition Language with Negation are used twice.
<sandro> PROPOSED: WG will define useful RIF dialects in Phase 1, eg including negation, not necessarily in a Rec.
<sandro> RESOLVED: WG will define useful RIF dialects in Phase 1, eg including negation, not necessarily in a Rec.
RESOLUTION: Phase 1 will include drafts of some useful dialects
afternoon breakouts:
1. abstract syntax and semantics
2. Extensibility of syntax
rifraf - can work on OWL ontology of 3. RIFRAF or start outlining dialects
4. Test cases
<msintek> ScribeNick: msintek
CMSA: is Innsbruck F2F6?
large objection for additional F2F between MIT and Innsbruck meetings
2nd half of February is preferred for F2F5
3 days more useful than 2?
voice feeds needed?
Allen needs to know 2 vs 3 days etc.
Allen will specify deadline for decision
weekend probably not possible
<sandro> csma and leora express desire to avoid meetings on weekends
Axel reporting from RIFRAF
starting points: bottom-up vs. top-down
scribe: do both directions
<scribe> ACTION: Sandro will provide template [recorded in http://www.w3.org/2006/11/05-rif-irc]
<rifbot> Created ACTION-172 - Will provide template [on Sandro Hawke - due 2006-11-12].
<sandro> msintek, please try to keep actions detailed enough to make sense out of context.
<sandro> (i edited 172 on the web to be "Provide template for authoring RIFRAF instance data")
Axel: procedure to collect next interation
... slides contain list of people to work on specific sections
CSMA: deadline: mid december
(Sandro will put actions in the system)
CSMA: what is REWERSE classification
Axel: will make clear how discriminators are related
<sandro> ACTION: Leora to revise and ontologize RIFRAF, section 1 due 2006-11-30 [recorded in http://www.w3.org/2006/11/05-rif-irc]
<rifbot> Created ACTION-173 - Revise and ontologize RIFRAF, section 1 due 2006-11-30 [on Leora Morgenstern - due 2006-11-12].
CSMA: is there impact on the design of the core?
Axel: in the end, dialects fit in the framework as well
<sandro> ACTION: Hassan to revise and ontologize RIFRAF, section 2 - due 2006-12-15 [recorded in http://www.w3.org/2006/11/05-rif-irc]
<rifbot> Created ACTION-174 - revise and ontologize RIFRAF, section 2 [on Hassan Ait-Kaci - due 2006-12-15].
Hassan and others: discussion of what will be mapped (dialects as abstract systems etc.)
<sandro> ACTION: Allen to revise and ontologize RIFRAF, section 3 - due 2006-11-30 [recorded in http://www.w3.org/2006/11/05-rif-irc]
<rifbot> Created ACTION-175 - revise and ontologize RIFRAF, section 3 [on Allen Ginsberg - due 2006-11-30].
<sandro> ACTION: Sandro to revise and ontologize RIFRAF, section 4 - due 2006-11-30 [recorded in http://www.w3.org/2006/11/05-rif-irc]
<sandro> ACTION: Paula to revise and ontologize RIFRAF, section 5 - due 2006-11-30 [recorded in http://www.w3.org/2006/11/05-rif-irc]
<sandro> ACTION: Axel to propose and ontologize RIFRAF on negation - due 2006-11-30 [recorded in http://www.w3.org/2006/11/05-rif-irc]
<sandro> ACTION: Axel ask Frank if he'll revise and ontologize Section 6 - due 2006-11-30 [recorded in http://www.w3.org/2006/11/05-rif-irc]
<rifbot> Created ACTION-176 - revise and ontologize RIFRAF, section 4 [on Sandro Hawke - due 2006-11-30].
<rifbot> Sorry, couldn't find user - Paula
<rifbot> Created ACTION-177 - propose and ontologize RIFRAF on negation [on Axel Polleres - due 2006-11-30].
<rifbot> Created ACTION-178 - ask Frank if he\'ll revise and ontologize Section 6 [on Axel Polleres - due 2006-11-30].
<sandro> ACTION: Paula-Lavinia to revise and ontologize RIFRAF, section 5 - due 2006-11-30 [recorded in http://www.w3.org/2006/11/05-rif-irc]
<rifbot> Created ACTION-179 - revise and ontologize RIFRAF, section 5 [on Paula-Lavinia Patranjan - due 2006-11-30].
Harold will be asked to review ontology
Dave: reporting back from the "whatever" :-) group
(i.e., group on dialects ....)
scribe: rule components: core = variable decl, antecedent, consequent
... dialects might add further
... dialects: starter set = lp, pr, fol
... is FOL in scope
... lp purity (prolog sub-dialect of lp?)
... led to disc. on ordering
... which was discussed a lot
... by default, synt. ordering not preserved; ordering construct will be provided
... needed for dialects with order-dep. semantics
<sandro> Paul: Why not order?
<sandro> Dave: Because merging is much harder with ordering.
<sandro> Dave: being unordering is a nice property for distributed things.
<sandro> [ This is not written as a proposal, yet ]
Dave: syntax extensions
... all rif standard dialects should use a common rif syntax, extending only where necessary
... syntax extension mechanisms: XML substitution groups / RDF
... is RDF permissable as XML syntax?
... charter just says "normative xml syntax"
... csma interprets this as xml schema
... dave: rdf metadata opens door to use rdf
... has to be decided
Issue: decide on XML Schema vs. RDF/XML as concrete syntax conforming to charter
Dave: extensions: need notion of common libraries (e.g., mathematical operators)=
<sandro> (clarified that SOME mathematical operators might be in core.)
csma: are there other views on this?
Peter: common syntax: not rdf?
Sandro: how do you introduce new operators?
... played with XML Schema: addition seems to be very difficult
CSMA: in some cases doable with subst. groups
Sandro: RelaxNG probably ok for RIF to use, if we really want
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
Alex: importance of keeping the provenance when merging rule sets
BREAK!
<PaulaP> scribenick: PaulaP
Reporting from the session on technical design - semantics
and abstract syntax
Christian: we should also discuss plans for the next spec and WD
Harold: focus on work by Hassan
... slots and constraints as main building blocks
... ideas to generalize existing proposal towards CLP
... a generalized slotted syntax is presented
... Herbrand atoms can be enriched by slotted atoms
... and Herbrand terms by slotted terms
... the slides will be also available, so no need to write details
... in the session's minutes
Christian: what about the quantification part? Is it also covered?
Chris: it is not in this proposal
Christian: the quantification part contains also constraints on the variables and their types
Chris: it is a placeholder for possible extensions
Christian: Does this mean that we have now 4 parts in a rule?
Harold: yes
Sandro: What means canonical here?
Chris: it is a normative one actually here
Christian: to be rephrased - if a model theory exists it should be normative
Chris: go back and start with the syntactic part so as to take decisions
<sandro> 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.
Hassan: slotted terms are more general than Herbrand terms
... and have a basic data model based on constraints
Alex: It is required to make constraints explicit?
Chris: the non-constraint part is positional
Hassan: we could also propose a kind of black-box approach for constraints
Christian: we have two levels of shorthands
Sandro: I'm very happy with this design
Dave: it seems you have orthogonal things here
Hassan: the abstraction mechanism is based on constraints
Chris: it is in the charter to support slotted terms
Jos: is this the reason also for introducing constraints?
Jeff: but why in the core?
<sandro> The design I'm seeing that I like is that by definition p(x,y,z) = p{1->x, 2->y, 3->z}.
Hassan: the core gives just the abstraction mechanism
<sandro> I wonder if we need a URI for "1". :-) :-) (and yet very serious.)
Jos: constraints in the core are of very limited nature
Jeff: can you provide references for the fact that datatypes can also be based on the proposed mechanism?
Hassan: yes, of course
Jeff: I need to read these documents first
Jos: need also to take a look at examples and use cases
Christian: you do not define formula in this approach
Alex: do you need a constraint solver?
Hassan: no, you don't
Chris: e.g. typing constraints can be mapped to something that understands such kinds of constraints
Michael K: typing is another issue
Alex: what is the difference between typing constraints and these presented in the proposal?
... what about OWL?
Michael K: we talk here about another types of constraints
Hassan: typing can be also dynamic
... for example to narrow search
Christian: we need to have an abstract syntax for the RIF core
... and the semantics so as to understand this proposal
Hassan: this is simply an abstraction mechanism for specifying specific things
Harold: we have conjunction formulas
... in this proposal that are based on very simple constraints
... we need just simple constraints in the core
Sandro: clarify what kind of decision we need here
... is there any reason for objecting to this proposal?
Jos: I need to see details
Alex: practical significance of introducing constraints
Chris: it can't be worse than the existing proposal
Alex: we need some nice examples for representing data models with constraints
Michael K: are you asking about documents on why CLP is useful?
Alex: no
Christian: can you provide examples of rules where you would like to see a translation using constraints?
... would that help?
Chris: constraints are completely optional
Sandro: but if I receive a constraints I have to handle it!!
Chris: constraints can be empty
Christian: the instantiation of the constraint part in the core is true?
Hassan: if you need to represent data models, you can have the constraints as a kind of built-in
Christian: would it help if Hassan provides concrete examples?
Jeff: we need to be clear what this extension brings
Chris: I don't understand what you don't understand
Peter: if the constraint is empty you don't get the core!
Chris: we have a set of constraints that map Herbrand terms to slotted terms
... no, actually not
<sandro> Chris: THE ONLY CONSTRAINTS YOU CAN WRITE, IN THE CORE, ARE THE ONES IN GREEN
Chris: we may have also other kinds of constraints
... later on
... restricted set of constraints for the core
Jos: I'm fine with this clarification
Jeff: I need something written
Axel: can you also map back to Herbrand terms?
Michael K: this is just theoretical
Hassan: yes, for Axel's question
Christian: what is the condition for this proposal to be accepted or not?
Jeff: I need to see something in the wiki
Alex: together with references from the literature
... and also mention some benefits
Hassan: we have now slotted terms
Michael K: other kinds of constraints may be part of the core
<scribe> ACTION: Harold to edit a wiki page for the proposal on extending the existing work with constraints [recorded in http://www.w3.org/2006/11/05-rif-irc]
<rifbot> Created ACTION-180 - Edit a wiki page for the proposal on extending the existing work with constraints [on Harold Boley - due 2006-11-12].
Chris: objections to the semantic hierarchy slide?
Christian: the normative semantics will be the model theory
<sandro> Chris: The WG will follow this, and we will recommend it to others.
Sandro: what if somebody declares the proof theory for a dialect as being the normative semantics?
Chris: they are not RIF-compatible
Gary: why not in the case of multiple existing theories just say which one is normative?
Dave: +1 to Gary's point
Peter: this is wrong
... the dialect for production rules will come just with operational semantics
<sandro> 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.
Sandro: suggest another wording
Jos: you didn't say anything about dialects
Peter: a formal specification is a formal specification for something
<sandro> 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.
Christian: if you want the operational semantics as normative, then you simply don't give a model and a proof theory
Peter: but we could reject such a dialect if we think that such a model or proof theory for this dialect exists
Gary: if they are 3, programmers will read just the operational semantics
Sandro: the semantics hierarchy gives us guidance
... to how to approach this issues
<sandro> RESOLVED: 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.
Christian: objections to the last phrasing?
no objections
Peter: we dropped the first part of the Harold's slide
<sandro> RESOLVED: RIF Core will be based on current model theory with suitable extensions
Christian: back to the constraints issues
... I think we can discuss other issues now
<JeffP> scribenick: JeffP
csma: when will the rifraf doc be available?
axel: mid Dec
... editor draft (internal) by mid Jan 2007
csma: do we have a work plan on UCR?
<scribe> scribenick: Jeff
<sandro> leora goes over what the UCR editors and contributors need to do
csma: work plan for UCR?
allen: can be done by end of Nov 2006
<sandro> LeoraMorgenstern, can you cut/paste that into e-mail to rif as something like Work Plan for UCR ?
<scribe> ACTION: Allen to edit sub-section on benefits based on earlier email [recorded in http://www.w3.org/2006/11/05-rif-irc]
<rifbot> Created ACTION-181 - Edit sub-section on benefits based on earlier email [on Allen Ginsberg - due 2006-11-12].
leora: shall we need some steps in between?
csma: shall we give Allen some time after Nov 30?
allen: Dec 5, 2006 would be fine
... there are some issues related to use cases which haven't been resolved
csma: we can get them discussed next telecon
... John's new texts on the use case are there
csma: do we want to publish the Nov 15 draft as a public one?
... or shall we wait for the XML syntax too?
... I think we should include
... otherwise it is not concrete enough for comments
peter: we need some way of describing the core using some current technique
harold: I did some experiment on XML Schema
... we can now validate against the current core now
csma: we should have as&s by the end of the month
sandro: relax ng might be a better option
gary: some tool can translate relax ng ionto xml schema
dave: is it a complete translation?
gary: haven't tried that before
<Harold> Content models written as DTDs can be automatically transformed into either XML Schemas or Relax NG schemas.
<sandro> ACTION: Sandro propose way to get to an XML syntax specification from the abstract syntax [recorded in http://www.w3.org/2006/11/05-rif-irc]
<rifbot> Created ACTION-182 - Propose way to get to an XML syntax specification from the abstract syntax [on Sandro Hawke - due 2006-11-12].
sandro: by the end of the week (for the above action)
... will talk to Harold later this week
harold: there are many different ways to do the same thing in xml schema, while in dtd there is only one way
csma: this means we can have the first editors' draft about as&s by the end of Nov
... more concrete descriptions for the new proposal should be provided before the WG can come up with a decision
... any action someone want to volunteer to clarify the new proposal?
... AOB?
hassan: I can show some demo on the parser generator JACC
csma: anyone interested in it?
(many people raised their hands)
(hassan starts the demo)
hassan: the limitations include it does not support attributes yet
csma: thanks Hassan
hassan: JACC is freely available
... and I am working on Java Web Start now
michael: any decision on ftf5?
csma: Allen will provide the dates asap
allen: maybe one week is enough
csma: next telecon would be next week, rather this one
Chris: lets thank peter for the organisations and hosts
... adjourn