W3C

- DRAFT -

RIF F2F4 Day 2

5 Nov 2006

See also: IRC log

Attendees

Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
PaulV

Contents


Plenary session 1: wrap-up break-outs (continued from day 1)

<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].

Plenary session 2: wrap-up break-outs (continued)

<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

Plenary session 3: next F2Fs, debriefing break-outs

<msintek> ScribeNick: msintek

next F2F

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

reports from breakout sessions

<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!

Plenary session 4: debriefing break-outs (continued)

<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

Plenary session 5: meeting wrap-up

<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

Tech Spec wrap-up

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

Summary of Action Items

[NEW] ACTION: Alex to list (clarify) issues raised by the extensibility requirement [recorded in http://www.w3.org/2006/11/05-rif-irc]
[NEW] ACTION: Allen to edit sub-section on benefits based on earlier email [recorded in http://www.w3.org/2006/11/05-rif-irc]
[NEW] ACTION: Allen to revise and ontologize RIFRAF, section 3 - due 2006-11-30 [recorded in http://www.w3.org/2006/11/05-rif-irc]
[NEW] 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]
[NEW] ACTION: Axel to propose and ontologize RIFRAF on negation - due 2006-11-30 [recorded in http://www.w3.org/2006/11/05-rif-irc]
[NEW] 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]
[NEW] ACTION: Hassan to revise and ontologize RIFRAF, section 2 - due 2006-12-15 [recorded in http://www.w3.org/2006/11/05-rif-irc]
[NEW] ACTION: Leora to revise and ontologize RIFRAF, section 1 due 2006-11-30 [recorded in http://www.w3.org/2006/11/05-rif-irc]
[NEW] ACTION: on Alex to list (clarify) issues raised by this requirement [recorded in http://www.w3.org/2006/11/05-rif-irc]
[NEW] ACTION: Paula to revise and ontologize RIFRAF, section 5 - due 2006-11-30 [recorded in http://www.w3.org/2006/11/05-rif-irc]
[NEW] 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]
[NEW] 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]
[NEW] ACTION: Sandro talk to Deborah about getting this issue on the issues list [recorded in http://www.w3.org/2006/11/05-rif-irc]
[NEW] ACTION: Sandro to revise and ontologize RIFRAF, section 4 - due 2006-11-30 [recorded in http://www.w3.org/2006/11/05-rif-irc]
[NEW] ACTION: Sandro will provide template [recorded in http://www.w3.org/2006/11/05-rif-irc]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/11/18 01:14:45 $