See also: IRC log
<ChrisW> Scribe: Adrian Giurca
<ChrisW> /topic #rif 16 Jan RIF agenda: http://lists.w3.org/Archives/Public/public-rif-wg/2007Jan/0073.html
<csma> Adrian can you hear me?
agiurca yes, I'm here
<ChrisW> scribenick: agiurca
<ChrisW> We approve http://lists.w3.org/Archives/Public/public-rif-wg/2007Jan/att-0066/02-rif-minutes.html?
<ChrisW> APPROVED: accept minutes of 2 Jan telecon
<markproctor> I've dialied in
<markproctor> I thought I'm suppose to get a code when I dial in, which I give to Zakim?
<csma> yes, it is 74394
<markproctor> for some reasonit just goes straight through into the call
<AlexKozlenkov> sorry about that
<csma> ACTION-206:Check information needed for foreign visitors, deadline for reg [on Allen Ginsberg - due 2007-01-16]. ACTION CLOSED
Harold: There May be difficult for some people to get funding for travel. I propose possibly demos and talks to the next F2F...
ChrisW: Harold and Michael to have the first working draft by the end of the next F2F
... In the F2F it was disscussed the Core design.
... Is the Core a part of any dialect?
... What is the nature of the Core? What we mean by implementing the Core
o There will be many different forms of tools working with RIF - editors, pretty printers, rule engines etc. Here we're only going to talk about RIF rule engines by which we mean a combination of a rule engine for some existing language plus a translator which translates between a fragment of that language and a RIF dialect.
o We have at least two notions of how a given RIF rule engine might conform to a RIF dialect. I think Michael calls these "conforms" and "implements"; I'll use "complies" and "implements" to avoid prejudging the definition of "conformance".
o A RIF rule engine complies with RIF dialect D if there is a 1-1 semantics-preserving mapping from the engine's language (L) into (not necessarily onto) D. Where "semantic-preserving" might mean preserving the set of atomic consequences of all translated rulesets.
<csma> o A RIF rule engine implements a RIF dialect D if there is a reverse mapping from D into L which preserves semantics. So the engine implements all of D, correctly.
csma: Just a part of the rule engine can be complaint to the dialect
<AlexKozlenkov> That is not what is Dave is saying
csma: A rule language that implements a dialect must implement Core
<AlexKozlenkov> compliance, yes
AlexKozlenkov Compliance is the keyword for any rule
FrankMcCabe the gcd between production rules and common logic rules is empty
<AlexKozlenkov> Frank +1
csma: We cannot require that all conformant rule languages implement the whole Core?
<AlexKozlenkov> We absolutely require RIF to provide for both production rules and common logic, Prolog and the like
ChrisW: Two directions: From L to Core and From Core to L
... A language implements the Core if you can translate the Core into that language.
<LeoraMorgenstern> into and out of?
<AlexKozlenkov> The word is complies.
<FrankMcCabe> How about export and import?
ChrisW: Translating a rule language into the Core = complies
<AlexKozlenkov> No, this is not injection
<csma> right, not injection
<AlexKozlenkov> Injection is to go from the _whole_ of the language
<FrankMcCabe> The terms implements and complies have a lot of baggage. I suggest import and export
<csma> Alex, I am not sure, but I understand that this is exactly what Dave/Michael mean by 1-1 mapping into but not onto Core
<AlexKozlenkov> Precisely my understanding
complies = translating a rule language into a (subset) of Core
FrankMcCabe I propose import / export for these definitions
<Harold> Nice idea, but import / export usually refers to modules / knowledge bases within languages not the languages themselves.
<FrankMcCabe> you might not be able to export all of yourself
<csma> Yes, but this has nothing to do with conformance (how much of yourself you can export)
agiurcaIf we can't translate into the Core how the Core will be used for interchange?
csma: Let move the this discussion on email.
ChrisW: We have: translation, direction of translation and "degree/amount" of the translation on each direction.
<FrankMcCabe> these are talks about having talks :)
<AlexKozlenkov> Hardly possible
ChrisW: It is desirable that Core to be a language
<FrankMcCabe> horn is recursive
csma: About example of Gary: the rule was translated preserving its meaning
<Harold> A 4th dimension would be the "complexity" of the translation: this can range from trivial renamings of symbols to very obscure encodings.
FrankMcCabe: One question is if we refer to the declarative semantics and/or procedural semantics
csma: For the Core just declarative part is important
AlexKozlenkov: If we consider the Core a minimum of RIF dialects may be difficulties with production rule systems
ChrisW: The Core will be Horn.
<AlexKozlenkov> OK
ChrisW: (To FrankMcCabe) Give us an example of a Horn rule that cannot be translated into a production rule system
<igor> eg, horn with functors
csma: The questionn is if a production rule system can implement the Horn Model theory.
DaveR: One of the possible barier is the recursive nature of rules
<Harold> Frank, I didn't see we need to implement a PR interpreter to encode Horn examples such as append.
ChrisW: I need example of a rule that cannot be translated from Core into a PR system
<Harold> The direction was from Core to PR.
<FrankMcCabe> It is the other way that will need an interpreter.
MichaelK: The Core is a foundation for RIF dialect or is a specific dialect?
<FrankMcCabe> +1 to foundation
<Harold> Michael, we can have both RIF Core and RIF Foundation (see today's email thread "Re:Thoughts on RIF core, dialects, conformance").
<markproctor> aren't we missing the point? both systems are turing complete, thus both can emulate each other. But because you can emulate something in a forward chainig engine, does not mean it makes sense? a backward chaining rule implemented in a forward chaining engine would be considered a kludge.
csma: The question is if the Core is a dialect then every rule language must implement the Core
<DaveReynolds> Christian - didn't PaulV object to horn with recursion?
MichaelK: Better to have Core as a useful dialect and then profiles
<csma> Dave - not after it was shown that PR did not lose the semantics, as far as I remember
MichaelK: Profiles allows to move forward...
... The Horn logic is the natural subset. Lets use it to the Core
... Profiles can be useful for the dialects also
<FrankMcCabe> are translations reversible?
<Harold> DaveR and MichaelK, if we have some profile, say RIF P, that restrict Core features, vendors could still say they support Core Profile RIF P.
<csma> Or, if Core profile P is implemented by everybody, we could just call it cCore and have Core included in every dialect
Harold: We should have profiles. Each vendor may support one (or more ) profiles
<MichaelKifer> i dont believe that we are overturning any prior decision or anything that is written in the charter
Francois: We need to define a Core mandatory for all rule vendors
<Harold> Francois, we can have a small set of standard profiles.
<Harold> If a large enough number of wide-spread PR systems don't support recursion, then a profile can reflect this with a restrictive attribute recursive="no".
Frank: I agree with Francois.
<MichaelKifer> If we will be strict on compliance then we won't make any progress. Let's allow profiles, move forward, and then the market will decide.
<Harold> Francois, sorry, yes, you are right we then also need a semantics for recursive=no".
<Francois> Yes, core must be mandatory.
<Harold> That semantics might be simple :-)
<Francois> The answer to the what question "what is core?" is the essential task of the WG.
csma: Agree with Michael proposal (Core and profiles)
<Harold> So, Christian, everyone who proposes a restriction, should also specify its semantics.
<Harold> Francois, yes of course, we can only afford a *small* set of **standard** profiles.
MichaelK: Other reasons for
profiles: for example, function -free Horn rules.
... We will be strict in defining profiles.
Alex: Profiles parametrize the Core. For example recursion is a simple "flag".
csma: May be the function-free issue is an application decission.
<Harold> We can span the space of variation (in particular, restriction) by defining the dimensions/parameters.
<ChrisW> axck csma
Allen: Vendors will implement
dialects
... Dialects will be based on parameterized Core
<AlexKozlenkov> Parametrized core is still a foundation
<Harold> Allen, I agree: only for RIF-defined dimensions/parameters can vendors make restrictions.
<AlexKozlenkov> Allen +1
<Harold> So far we have only two dimensions/parameters/attributes/flags recursive={"yes","no"} and functions={"yes","no"}. Any other ones?
<AlexKozlenkov> Profile is a flavor of the core, not an alternative core
<DaveReynolds> Harold: restrictions on arity of predicates? (binary for RDF :-))
<Harold> We have to also look at all combinations of these.
<Harold> E.g., recursive="no" and functions="no".
ChrisW: How much work is to be done for a Core proposal?
MichaelK: Constraints in the Core do not play any role
<Harold> Dave, yes: binary={"yes","no"} should be added.
MichaelK: I'm not in the favor of including constraints in the Core. We may include them in dialects
<Harold> Note the connection between the current dimensions/parameters/attributes/flags discussion with the 'dscriminators' in RIFRAF.
<csma> Dave, Harold - I disagree: opting out should not be allowed for convenience, but motivated by impossibility, or at least strog difficulty
<AlexKozlenkov> Michael +1
<Harold> Christian, OK, strong reasons must be cited.
<DaveReynolds> Christian: I'm not sure I like profiles at all, I was just responding to Harold's request for what might make other features that could be profiled. Certainly JenaRules are restricted to binary, but that I wasn't expecting to be able to be implement RIF anyway.
MichaelK: If we include constraints then there will be some problems with the semantics of the constraints
<Harold> About (CLP) constraints: the f2f breakout always introduced constraint calls only as optional (see SYNTAX in http://www.w3.org/2005/rules/wg/wiki/CORE/Rules/Horn): HEAD ':-' BODY [ '&' CALL ]
<markproctor> sorry I missed the proposal
<markproctor> can someone give me the subject and date for the email.
<markproctor> I have no idea if its possible to do it universal.
<markproctor> but I would have thought a unified constraint model - a > b, c != a etc, would be very important.
<Harold> Having []-optional constraints in is only a small step away from having constraints in a dialect. My take was Hassan wanted to introduce them as a foundation.
<MichaelKifer> +1
<csma> +1 to extend
<AlexKozlenkov> Let us read it carefully this week and evaluate pros and cons
Allen_Ginsberg: May be later will do a profile CLP based
<csma> +1 to Allen_Ginsberg: let us gather pros and cons to constraints and put it on the agenda in the close future
This is scribe.perl Revision: 1.127 of Date: 2005/08/16 15:12:03 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/procs/pros/ Found Scribe: Adrian Giurca Found ScribeNick: agiurca Default Present: Harold, FrankMcCabe, agiurca, Francois, Deborah_Nichols, ChrisW, Dave_Reynolds, Leora_Morgenstern, csma, StellaMitchell, AlexKozlenkov, pfps, Allen_Ginsberg, josb, igor, MarkusK, Michael_Kifer, Gary_Hallmark, markproctor, Gerd_Wagner, Mike_Dean Present: Harold FrankMcCabe agiurca Francois Deborah_Nichols ChrisW Dave_Reynolds Leora_Morgenstern csma StellaMitchell AlexKozlenkov pfps Allen_Ginsberg josb igor MarkusK Michael_Kifer Gary_Hallmark markproctor Gerd_Wagner Mike_Dean Regrets: PaulaLaviniaPatranjan JeffPan MohamedZergaoui HassanAitKaci Agenda: http://lists.w3.org/Archives/Public/public-rif-wg/2007Jan/0073.html Got date from IRC log name: 16 Jan 2007 Guessing minutes URL: http://www.w3.org/2007/01/16-rif-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]