See also: IRC log
<ChrisW> scribe: MarkusK
<DaveReynolds> DaveReynolds raised question of whether issue 12 would be addressed somewhere during the discussions
http://www.w3.org/TR/rif-ucr/#Requirements
csam: objective is to agree on definition of requirements, their origin (UC, charter, other), and their justification
s /csam/csma/
csma: some charter requirements are not in the UCR list yet
... aim only to identify work items for breakout sessions
4.1.1. Compliance model
<Harold> http://www.w3.org/2005/rules/wg/wiki/UCR/Requirements
"RIF must define a compliance model that will identify required/optional features."
no objections
4.1.2. Default behavior
"RIF must specify at the appropriate level of detail the default behavior that is expected from a RIF compliant application that does not have the capability to process all or part of the rules described in a RIF document, or it must provide a way to specify such default behavior."
from charter
csma: origin of requirements should be mentioned in the UCR document
sandro: UCR needs to provide justifications by use cases
csma: what about non-functional requirements that appear in charter? May not be justified by UCs.
chris: some requirements might not have concrete use cases, still they are important
csma: Question for breakout: Should all requirements be connntected to use cases? What exceptions are allowed?
no objections to 4.1.2.
4.1.3. Different intended semantics
"RIF must cover rule languages having different intended semantics."
csma: direct origin of requirement unclear
... does this need further clarification?
Breakout: issue 12, http://www.w3.org/2005/rules/wg/track/issues/12
4.1.4. Embedded comments
no objections
4.1.5. Embedded metadata
"RIF must support metadata such as author and rule name."
possible discussion on term "metadata"
4.1.6. Implementability
"RIF must be implementable using well understood techniques."
csma: some clarification might be needed. Why did we add that?
ivan: I think it is sufficiently clear
4.1.7. Limited number of dialects
"RIF must have a limited number of standard dialects and/or a common core."
<ChrisW> Scribe: Markus
csma: two different requirements: common core, limited number of dialects
sandro: the core is required by the charter
ivan: clarification needed on "limited number of dialects"
hassan: term "dialect" is unclear as well
Breakout: discuss meaning of "limited number of dialects"
4.1.8. OWL data
"RIF must cover OWL knowledge bases as data where compatible with Phase 1 semantics."
csma: note: requirements only for Phase 1, hence "Phase 1 semantics"
from UCs and charter
no objections
4.1.9. RDF data
"RIF must cover RDF triples as data where compatible with Phase 1 semantics."
dave: no a priori reason to limit Phase 1 RDF or OWL compatibility to OWL DL.
4.1.10. Rule language coverage
"RIF must cover the set of languages identified in the Rulesystem Arrangement Framework. See the Coverage section."
csma: might need rephrasing
... covered "features" are more important than "languages"
Breakout: discuss this requirement
csma: this is an umbrella requirement for the single languages' requirements
4.1.11. Semantic precision
"RIF must have a clear and precise (unambiguous) semantics to reduce the potential for error in the exchange of rules."
<sandro> "It depends what you mean by 'clear and precise semantics'" is a wonderful phrase
csma: discussion needed on meaning of "clear and precise"
... better discuss ofter discussing technical spec
hassan: clarification needed on what semantics is needed. Meta-semantics of RIF?
csma: yes, but discussion needed to fully clarify this
4.1.12. Semantic tagging
"RIF must have a standard way to specify the intended semantics (or semantics style) of the interchanged rule set in a RIF document."
term "semantic style" needs some clarification
ivan: some clarification needed, but glossary might suffice for this
hassan: "semantic style" refers to different kinds of semantics such as e.g. model theoretic semantics, proof theoretic semantics
4.1.13. Standard components
"RIF implementations must be able to use standard support technologies such as XML parsers and other parser generators."
csma: we might want to reorder the requirements to clarify their interrelation
4.1.14. Translators
<Harold> Re Rule language coverage, what about: RIF must cover the set of languages selected via the Rulesystem Arrangement Framework. See the Coverage section.
"RIF must not require rule systems to be changed; it must be implementable via translators."
Breakout: discuss 4.1.14
4.1.15. XML syntax
"RIF must have an XML syntax as its primary normative syntax."
4.1.16. XML types
"RIF must permit XML information types (where appropriate) to be expressed using XML Schema. See the charter on Datatype support."
dave: this was changed already
issue was that primitive xsd types should go into phase 1, while structured types are for phase 2
csma: correct version now is:
"RIF must support an appropriate set of scalar datatypes and associated operations as defined in XML Schema part 2 and associated specifications. See the charter on Datatype support."
from http://www.w3.org/2005/rules/wg/wiki/UCR/Requirements
other requirements might have been updated in this document as well
csma: no discussion of Phase 2 requirements now
<sandro> sandro: note that this rephrasing on XML schema drops the requirement, in the Charter, to support LISTS in phase 1.
csma: requirements from the charter
... mission covered by earlier requirements
... compatibility requirements with XML data, and RDF (where RIF overlaps with RDF); covered
<Harold> Re Limited number of dialects, what about Sandro's proposal: RIF must have a limited number of standard dialects based on a common core. (Both alternatives allowing the 'or' would hardly be acceptable: 1. No common core, 2. More than one core.)
csma: compatibility with use of SPARQL to query datasets
<sandro> Harold, my understanding is that question is out of order for this session -- this session is just to review and assign work items to the UCR breakouts.
csma: currently not covered, discussion needed to get requirement on that
... conformance
no comments
csma: "load and query", implications on requirements?
... do UCs in phase 1 support this?
<Harold> Yeah, just wanted to have your proposal (and my justification) be kept it in mind for that breakout.
alen: requirement is present in the medical UC, should be added
s /alen/allen/
<sandro> csma: 1. sematics specified in terms of queries
<sandro> csma: 2. merged rulesets
csma: "the syntax must support named arguments" is mentioned in charter, but not reflected in requirements
... phase 1 semantics
... rulesets mentioned, but currently no requirement
... some further requirements might not need explicit mentioning (e.g. support for "facts as well as rules"
... datatype support
... current requirements are somewhat less detailed, compare with requirements again
... work item is to check whether requirements from UCs are covered as well
harold: Re "SHOULD consider RDF as meta-data" -- can we strengthen the "should"?
csma: "should" comes from charter, further discussion for breakouts
allen: discussion on coverage http://www.w3.org/2005/rules/wg/track/issues/22
csma: already on work items
... break!
<sandro> scribe: Hassan
Work on RIF Technical Design
ChrisW: Currently we have 4 proposals - should boil down to one?
Current (1) Harold Boley et al.'s CORE condition language
(2) Hassan's CLP reformulation of a core formalism (as a Logical Framework)
(3) CSMA's proposal based on informal test cases?
(4) Dave Reynolds' proposal to use RDF - syntax level, possibly compatible with (1)-(3)
CSMA: not yet another semantics, but use *partial* semantics
... not incompatible with the others as well
<sandro> csma: "partial semantics" == "constraints on semantics"
Leora: I don't understand "partial semantics"
CSMA: "partial semamntics" means "incomplete specification that may be extended"
<Harold> Christian's Core with a 'partial semantics' would be compatible with the Condition Languages semantics in the sense that Conditions are 'partial rules'.
a/semamntics/semantics/
Harold: limited to conditions that are common to different styles of rules
CSMA: I do not know what the right constraints are but say, Modus Ponens ...
... find some way of making sense with some rules even though the full set of assumptions is not met
Harold: OK - we agree (in our proposal) and tried to formalize that but had to backtrack to what we have now
<GaryHallmark> harold: taxonomy of actions: 1. introspective (KB change), 2. bounded by programming environment, 3. real world actions
CSMA: I would like to do things another way: if we characterized some level of syntax and some semantics then interchange can be still achieved even though there is no complete agreement
Sandro: what CSMA is saying (IMO) is that we should be able to interchange among different styles of rules (say Prolog and Production)
<GaryHallmark> +1 to interchange of rules between producton rule and horn
Peter: everyone agrees if limited to Horn -
<GaryHallmark> peter: pure postive horn and PR should give same result
Hassan: let us not confuse Logic and Model Theory (Proof theory e.g., SOS, Natural Semantics, ...)
<Harold> Hassan, do you mean "operational semantics" in the sense of "rewrite-rule semantics"?
<sandro> PROPOSED: For positive Horn rules, RIF will use the direct and obvious mapping between production rule systems and logic programming systems.
<Harold> +1
<GaryHallmark> +1 to sandro's proposal
MichaelKifer: Sandro's proposal is already covered by ours
<Harold> Paula, what is your and Francois opinion on this now?
<PaulaP> Harold, I'm not sure I understand Christian's proposal
JosB: need only agree on the core shared - extensions may and will have different semantics
<sandro> Jos: the extension can have different semantics, they just need to reduce to the original semantics on the original inputs
<sandro> mkifer: Sandro, your proposal is like a law of nature
<Harold> Paula, I meant about Sandro's proposal of mapping at least between subsets of Production rules and Horn?
JosB: therefore no need for "partial" semantics - compatibility should not be based only on models, but also on other criteria (operational)
<PaulaP> Harold, I think Michael Kifer is right...it is obvious if the mapping is not 'problematic', that is in the case that the subset is a common one
ChrisW: can CSMA's prop be rephrased as using "partial" semantics in the sense that non core features could be expressed more "operationally"
CSMA: allow multiple interpretations as given
Peter: Why not be fully formal?
<sandro> Peter: there are formal semantics out there which say that a number of outcomes are all permissible
<Harold> Christian, do you want to formalize the following: "A rule with multiple intended interpretations should be captured as a single RIF rule"?
DaveReynolds: I like what CSMA is trying to get at: 2 things can be done (1) find test cases with multiple interpretations and (2) example on how to cover this test case
CSMA: need a task force for this
<Harold> (Instead one could capture it with - a conjunction of - several RIF rules.)
Ivan: I would like to understand why is it so important in term of a real UC?
<sandro> Chris: the use case is any interchange between LP and PR systems
Ivan: not a technical issue - why is this important?
Hassan: a rule may have multiple semantics (abstract, concrete, ...)
<Harold> Christian, such 'richness' of interpretations adds to the power of natural languages, but may not be the way to go for formal languages.
<Harold> scribe: Harold
Hassan's proposal:
Three levels:
* Change the level of abstraction: CLP
<sandro> 1. "abstract data model from rule"
* Model theory can only capture immutable truths. 70% have no logical truth.
<sandro> 2. lots of impure logical features
<sandro> (truths are good, but how to get there is better.)
<sandro> Hassan: stay OPERATIONAL and FORMAL, not just MODEL THEORETIC
* Use Hereditary Harrop Formulas to capture local quantification (with variables).
<sandro> Leora: When you say Operational, do you mean Proof Theoretic?
Leora: What does 'operational' mean here?
<sandro> I'm just taking extra notes, Harold.
<sandro> Don't worry about me.
Hassan: Only (formal) proof theory.
Alex: What about actions? Communication acts?
Hassan: Yes, there are references in the write-up.
Axel: Shall rule sets then declare what the operation semantics for computing consequences would be?
Hassan: RIFRAF should span the space for the operational semantics: a *meta* rule language, which is nice
<sandro> Hassan: a meta rule language -- a way to write down the proof theory of your rule language.
(abstract syntax trees)
Michael: Stable and Well-founded semantics are still not covered.
<sandro> mikifer: proof theory doesn't cover important things like stable model semantics
Hassan: RIght, it cannot capture everything.
Allen: Does this go towards fixpoint semantics (op. sem.)?
Hassan: Fixpoint only one possiblity.
<csma> What I wanted to add: There are not only rules, there are also ruelsets. I remember Uli saying, at one telecon, that the order in which rules are taken into account may change what is inferred; in many practical cases, it does not actually matter: what you would infer in the various cases is equally acceptable (equally preserves the meaning); only the semantics of the specific RL into which the RIF document is translated will decide which one(s) are actually produced.
Andreas: Op.sem vs. proof theory. There are really 3 levels: Model theory, proof-theory, op.sem. (algorithm).
Chris: lets do this offline.
<Hassan> Scribe: Hassan
ChrisW: My concern with the current proposal is extensiblity - not clear how to go about it
... Abstract Syntax makes more sense for extensibility
... (1) how formal should we be (2) what Abstract Syntax
DaveReynolds: What about the separation of data models?
ChrisW: It is compatible with the rest
... Identify "incompatibilities" among proposals...
<sandro> Chris: Separartion of Data Model can be done in any of the proposals
DaveReynolds: What about formal vs. informal semantics? Precise vs. imprecise?
Axel: A proof theory that is sound and complete is compatible by definition with model theory
ChrisW: Other disagreements?
CSMA: partial vs.permissive is a better dimension
<csma> I wondered if "precise VS permissive" meant the same as "partial VS complete" and whether the latter was clearer than the former
ChrisW: WHat is the disagreement?
<sandro> sandro: the disagreement is: "How are we going to specify the semantics"
ChrisW: Given a precise semantics how do we specify it?
... These are the issues to discuss
<scribe> scribe: Hassan
ChrisW: No decisions are to me made in the breakout sessions but we must clarify everything we are talking about
... Preferably in writing...
... BO sessions must be balanced in attendance
2 BOs planned after lunch (1) requirements
(2) technical design
Sandro: the BO should be "How do we specify the semantics?"
CSMA: can we have a 3rd BO on syntax?
ChrisW: SO 3 BO sessions: (1) UCR (2) How to specify Semantics (3) syntactic issues + vocabularies
... New sessions: (1) UCR (2) Partial vs. complete semantics (3) syntactic issues + vocabularies
... New sessions: (1) UCR 5 people (2) Partial vs. complete semantics 10 people (3) syntactic issues + vocabularies 8 people
... 90 mins for BOs and 30 mins plenary for debriefing
... Back to discussing URI's and vocabularies
... What about using URIs for everything is RIF
CSMA: Gerd Wagner started this discussion: what elements?
Sandro: this issue is to discuss the shape of RIF constructs as XML elements
Some members have specific examples we can discuss
Ivan: using ternary/binary predicates
ChrisW: each BO group will report back to the whole group: so we need BO session chairs
... and scribes ...
Allen Ginsberg will chair the UC&R session
Sandro will chair the syntax session
Chris Welty will chair the Partial vs Complete session
Paul Vincent will chair the UC&R session
Alex will scribe the syntax session
Deborah will scribe the syntax session
<GaryHallmark> scribe: GaryHallmark
<scribe> scribe: GaryHallmark
sandro: should we make decisions now?
chrisw: need to make decisions that affect next breakout
please see breakout session notes for details of this session
paulv: several issues about whether ruleset merging affects RIF
DaveR: should state whether RIF supports merging (don't have to say how)
again see breakout session notes for details of this session
alex: local names (e.g. local var) do not need URIs
josb: namespaces treated as per RDF
sandro: RIF can use URIs like RDF does
<Hassan> http://www.ihmc.us/users/phayes/IKL/SPEC/SPEC.html
harold: need slotted syntax
alex: roundtripping should be a requirement
<sandro> ACTION csma to do something about roundtripping, like put it on issues list
<sandro> ACTION: csma to do something about roundtripping, like put it on issues list [recorded in http://www.w3.org/2006/11/04-rif-minutes.html#action01]
<rifbot> Sorry, couldn't find user - csma
<sandro> ACTION: Christian to do something about roundtripping, like put it on issues list [recorded in http://www.w3.org/2006/11/04-rif-minutes.html#action02]
<rifbot> Created ACTION-165 - Do something about roundtripping, like put it on issues list [on Christian de Sainte Marie - due 2006-11-11].
<sandro> ACTION: Sandro to find out if we can assign a URI to xpath/xquery functions and operators [recorded in http://www.w3.org/2006/11/04-rif-minutes.html#action03]
<rifbot> Created ACTION-166 - Find out if we can assign a URI to xpath/xquery functions and operators [on Sandro Hawke - due 2006-11-11].
chrisw: role of CORE is to avoid n**2 translators
... the CORE semantics should be precise
... is positive Horn a useful CORE?
... even positive Horn may not be a subset of production rules
... negation is too contentious for CORE
Sandro: must do at least CORE for phase1
<csma_afterward> scribe: sandro
pfps, did you pick a time for dinner?
<pfps> dinner is "shortly" after 6
PROPOSED: that implementability, semantic precision, standard components, and translators be treated as "general".
RESOLUTION: that implementability, semantic precision, standard components, and translators be treated as "general".
<scribe> ACTION: PaulV to work with Allen on defn of covers [recorded in http://www.w3.org/2006/11/04-rif-minutes.html#action04]
<rifbot> Sorry, couldn't find user - PaulV
<scribe> ACTION: Paul to work with Allen on defn of covers [recorded in http://www.w3.org/2006/11/04-rif-minutes.html#action05]
<rifbot> Created ACTION-167 - Work with Allen on defn of covers [on Paul Vincent - due 2006-11-11].
<scribe> ACTION: Igor to work with Allen on defn of covers [recorded in http://www.w3.org/2006/11/04-rif-minutes.html#action06]
<rifbot> Created ACTION-168 - Work with Allen on defn of covers [on Igor Mozetic - due 2006-11-11].
RESOLUTION: "RIF must cover rule languages with different semantics."
I don't have a clue what it means, but I'm withdrawing my objection.
PROPOSED: "RIF must have a standard core and a limited number of dialects based upon that core"
RESOLUTION: "RIF must have a standard core and a limited number of standard dialects based upon that core"
PROPOSED: "RIF core must have a clear and precise semantics. Each standard RIF dialect must have a clear and precise semantics that extends the RIF core semantics."
... "RIF core must have a clear and precise syntax and semantics. Each standard RIF dialect must have a clear and precise syntax and semantics that extends RIF core."
RESOLUTION: "RIF core must have a clear and precise syntax and semantics. Each standard RIF dialect must have a clear and precise syntax and semantics that extends RIF core."
PROPOSED: "Dialect Identification", "RIF must have a standard way to specify the dialect of the interchanged rule set is a RIF document."
RESOLUTION: "Dialect Identification", "RIF must have a standard way to specify the dialect of the interchanged rule set is a RIF document."
<scribe> ACTION: Hassan to improve glossary [recorded in http://www.w3.org/2006/11/04-rif-minutes.html#action07]
<scribe> ACTION: Hassan improve glossary [recorded in http://www.w3.org/2006/11/04-rif-minutes.html#action08]
<rifbot> Created ACTION-169 - Improve glossary [on Hassan Ait-Kaci - due 2006-11-11].
PROPOSED: (implementable via translators) For every standard RIF dialect it must be possible to implement a translator for from rule lanuages covered by the dialect to RIF.
Allan: this comes from We're Not expecting people to do research to implement RIF
Chris: This doesn't say that you don't need to change your rule system.
Allan: Well, it implies it.
PROPOSED: (implementable via translators) For every standard RIF dialect it must be possible to implement translators between rule lanuages covered by the dialect and RIF without changing the rule language.
RESOLUTION: (implementable via translators) For every standard RIF dialect it must be possible to implement translators between rule lanuages covered by the dialect and RIF without changing the rule language.
PROPOSED: It must be possible to create new dialects of RIF and extend or modify existing ones upwardly compatible
Chris: let's put this off to tommorrow.