<ChrisW> Scribe: Adrian Giurca

<ChrisW> /topic #rif 16 Jan RIF agenda: http://lists.w3.org/Archives/Public/public-rif-wg/2007Jan/0073.html

UCR

Admin

I'm here

<ChrisW> scribenick: agiurca

yes

<csma> can you hear me?

<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2007Jan/att-0066/02-rif-minutes.html

<markproctor> I've dialied in

<markproctor> I thought I'm suppose to get a code when I dial in, which I give to Zakim?

<ChrisW> APPROVED: accept minutes of 2 Jan telecon

<markproctor> for some reaosn it just goes straight through into the call

<AlexKozlenkov> sorry about that

<csma> yes, it is 74394

F2F

<csma> ACTION-206: CLOSED

Liason

Harold: Proposal for F2F: May be difficult for travel funding.
... Propose possibly demos and talks to the next F2F

<markproctor> I've tried calling in 3 times now

<markproctor> I put in the passcode and I get three bleeps, it never gives me an id back.

Technical Design

<csma> Mark, keep trying: we see you appear and then disappear... ChrisW had to try 4 times before he mase it, today!

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> compiance, yes

Alex: Compliance is the keyword for any rule

Frank: 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> Complies

<FrankMcCabe> how about export and import?

ChrisW: Translating a rule language into the Core = complies

<AlexKozlenkov> No, this is not injection

<FrankMcCabe> the terms implements and complies have a lot of baggage. I suggest import and export

<csma> right, not injection

<AlexKozlenkov> Injection is to go from the _whole_ of the language

<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

Frank: I propose import / export for these definitions

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

<Harold> Nice idea, but import / export usually refers to modules / knowledge bases *within* languages not the languages themselves.

If 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 recursice

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.

Frank: One question is if we refer to the declarative semantics and/or procedural semantics

csma: For the Core just declarative part is important

Alex: 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: 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 Horm Model theory.

Horn ->Horn

Dave: 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.

<Harold> The direction was from Core to PR.

ChrisW: I need exampleof a rule that cannot be translated from Core into a PR system

<FrankMcCabe> It is the other way that will need an interpreter.

<FrankMcCabe> +1 to foundation

Michael: The Core is a foundation for RIF dialect or is a specific dialect?

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

Michael: 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

Michael: 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.

MIchael: 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.

ChrisW: How much work is to be done for a Core proposal?

<Harold> E.g., recursive="no" and functions="no".

MIchael: Constraints in the Core do not play any role

<Harold> Dave, yes: binary={"yes","no"} should be added.

Michael: 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> Christina, 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.

Michael: Including constraints there are problems with the semantics

<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: May be later a profile CLP based

<csma> +1 to alex: let us gather pros and cons to constraints and put it on the agenda in the close future

<csma> +1

yes, of course

<Francois> bye.

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.