RIF telecon 18 December 2008 -- 18 Dec 2007

<csma> Scribe: Hassan Ha�t-Ka�i

<csma> Scribenick: hak

<csma> zaki, reset agenda

<csma> scribenick: Hassan_Ait-Kaci

<LeoraMorgenstern> (I will just be on tthe IRC for a while; stuck in a meeting.)

Admin

<Hassan> No agenda amendments ...

<Hassan> Accepting last week's minutes postponed to next week?

<csma> PROPOSED: accept the minutes of December 4 telecon

<Hassan> Propose to accept those of Dec 4 2007 telecon

<csma> http://lists.w3.org/Archives/Public/public-rif-wg/2007Dec/att-0050/04-rif-minutes.html

<Hassan> RESOLVED: accept the minutes of Dec 4 2007

<Harold> Sandro, What were the highlights of the OWL f2f most relevant to RIF?

<Hassan> Christian worries about posting of meetings early enough...

<Hassan> Merry everything ... :-)

<Hassan> Action 394 done

<Hassan> Action 395 done

<Harold> http://www.w3.org/2005/rules/wg/wiki/Response_to_PPS1?action=diff&rev2=9&rev1=8

<Hassan> Harold says see Wiki for Action 395

<Hassan> Harold comments his changes in the document

<Hassan> Ask MK to review the changes ...

<Harold> What were the highlights of the OWL f2f most relevant to RIF

<Hassan> Igor wonders about OWL F2F meeting in Manchester...

<ChrisW> ^Igor^Harold

<Hassan> Sandro was there ...

<Hassan> Sandro does not have anything to report

<Hassan> Harold wonders about DL safe rules in OWL

<Hassan> Sandro says that no decision in the OWL WG regarding this has been taken so far

<Hassan> Just getting the basics to get the WG going

<Hassan> RIF/OWL task force (Peter Patel-Schcheider and Uli Sattler on the OWL side and Mike Dean and Jos Debruijn on ours

<Hassan> Any other liaison?

<Hassan> None

<csma> http://www.w3.org/2005/rules/wg/track/issues/40

<Hassan> Issue 40 - about builtins

<PaulaP> http://www.w3.org/2005/rules/wg/wiki/List_of_BLD_built-ins

<Hassan> last week the syntax for evaluated preds and funcs was resolved

<Hassan> this week we need to discuss the rest

<Hassan> item: what builtins for BLD?

<Harold> http://www.w3.org/2005/rules/wg/wiki/List_of_BLD_built-ins

<Hassan> proposal: include all that in the builtins page?

<csma> PROPOSED: BLD builtins will at least include those being currently

<csma> listed on the builtins page

<Hassan> Paula: the status of some of them needs to be discussed because many have proposed sets of builtins

<Hassan> csma: since the others are not here ...

<Hassan> csma: there 3 sets (1) numerics (2) strings (3) date and time

<Hassan> csma: idea is not to exclude anything but to decide the mininum set we need

<csma> PROPOSED: BLD builtins will at least include those currently being listed in the "list of supported builtins" section of the buildin page

<Hassan> ChrisW: this is hard to record

<Hassan> Sandro: put a link to the front of the page

<AxelPolleres> May I remind of conversion functions... just came to my mind again:

<Hassan> csma: there is a level of indirection in the links

<AxelPolleres> http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/0003.html

<markproctor> sorry I'm late, was in another call previously.

<Hassan> Sandro: proposes "this is the list of builtins in the next working draft..." (sorta...)

<Harold> I think it is this link: http://www.w3.org/2005/rules/wg/wiki/List_of_BLD_built-ins?action=recall&rev=23

<sandro> http://www.w3.org/2005/rules/wg/wiki/Functions_and_Operators_on_Numerics

<Hassan> ChrisW proposes the add the links to to three pages of proposed builtins

<sandro> http://www.w3.org/2005/rules/wg/wiki/Functions_on_Strings

<sandro> http://www.w3.org/2005/rules/wg/wiki/Functions_and_Operators_on_Dates_and_Times

<sandro> (implicit ?action=recall&rev=1 to each of those)

<Hassan> ChrisW: propose to put an action on someone to fix it

<Hassan> Sandro: propose the action to be to put it into a TR document

<Hassan> Paula?

<Harold> Current appendix:

<Harold> http://www.w3.org/2005/rules/wg/wiki/Core/Specification

<Hassan> Action on Harold to fix the document(s) accordingly

<ChrisW> ACTION: Harold to add builtin page as a new appendix to BLD [recorded in http://www.w3.org/2007/12/18-rif-minutes.html#action01]

<rifbot> Created ACTION-397 - Add builtin page as a new appendix to BLD [on Harold Boley - due 2007-12-25].

<Hassan> csma: anyone objecting to the notion of having the current list of builtins in the BLD

<Hassan> should speak up

<Hassan> csma: if we do we may also want functions in addition to predicates?

<Hassan> MK: what semantics?

<Hassan> MK: functions as builtins require a notion of error ...

<ChrisW> are all the proposed builtins total functions? (Has anyone checked?)

<Hassan> csma: using a predicate notation ?

<Hassan> MK: then error will mean failure (false)

<csma> P(f(a)) = P(x) AND Pf(x a)

<ChrisW> what about designating a special URI as a return value ?

<sandro> Hassan: I can write you a semantics for functions, with errors, with no problem. I don't see the difficulty here.

<sandro> MichaelKifer: But we have functional expressions. We'll have to explain how to unwrap these functional expressions. This gets complicated.

<ChrisW> e.g. rif:error

<ChrisW> as a return value when a function fails

<sandro> MichaelKifer: csma, your approach make sense, but then what happens when you apply a function to a function? It's not *BIG* problem, but we'll have to do something about it.

<sandro> Hassan: Sorry, why is applying a function to a function a problem?

<Harold> Michael, P(g(f(a))) = P(x) AND g(x y) AND f(y a)

<sandro> MichaelKifer: We'll have to explain that functions are syntactic sugar for predicates, and we'll have to explain how you unwrap them to predicates.

<Harold> s/ Michael, P(g(f(a))) = P(x) AND f(x y) AND f(y a)/ Michael, P(g(f(a))) = P(x) AND g(x y) AND f(y a)/

<sandro> (no problem, hassan. I was trying to tell you I would scribe while you spoke, but was muted.)

<AxelPolleres> http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/0003.html

<Hassan> Axel: functions are needed for conversions (from one type to another)

<Hassan> MK: still is not convinced - it needs work

<sandro> MichaelKifer: the unary function examples are simple; it gets more complicated, and will take a page or so.

<Harold> P(g(f(a1 ... anN))) = P(x) AND g(x y) AND f(y a1 ... anN)

<sandro> MichaelKifer: similar to the text about frames, but more complex.

<sandro> Hassan: All functions are unary, by Currying.

<sandro> Hassan: Many arguments is one argument, etc.

<Harold> Hassan, do you really propose Currying for RIF?

<Hassan> MK: needs to explain more

<Harold> (http://en.wikipedia.org/wiki/Currying)

<Hassan> ChrisW: we could require that external functions calls be total functions

<Hassan> MK: cannot garantee that

<Harold> But, again, I support Michael, let's omit functions in RIF 1.0 FOR MAKING THINGS NOT MORE COMPLICATED.

<Hassan> MK: argues that one cannot define the semantics of the predicate upon functional error

<Harold> * Functions would call for Equality (and not all people don't want that)

<Harold> * We would have a predicate/function duplication of builtins

<Hassan> harold: wonders about equality of functions

<Hassan> harold: it complicates things

<Harold> Once you have builtin functions like plus and square, then people will ask for user-defined functions like sumofsquare(?L) = ...

<Harold> (and we need equality)

<Hassan> csma: we would need to explain how we unwrap predicates as functions for the semantics ...

<Hassan> MK: sure ...

<Hassan> MK: how to name the introduced predicates? all this need to be made explicit ...

<Hassan> MK: if functions are syntactic sugar, we need to give the semantics of the "real" thing they stand for

<Hassan> csma: but some systems using BLD might have both functions and predicates

<Hassan> MK: that's a problem

<GaryHallmark> I would like user defined functions

<AxelPolleres> in BLD, they are fine, in CORE no... if we get there.

<Hassan> csma: functions are useful because many languages have them

<Harold> Hi Gary, so do you like Equal in BLD?

<GaryHallmark> harold: yes

<ChrisW> +1 for having them

<Hassan> MK: not objecting to functions, just that they add complications

<Harold> Gary, OK it's still in there (but not in what we thought would be the Core).

<GaryHallmark> for PRD, perhaps all functions are builtin or user-defined

<Hassan> MK: needs to make the syntactic sugar unwrap and what the eventual things are must be made clear

<Harold> I see

<Harold> Gary.

<sandro> PROPOSED: Built-in functions will have corresponding built-in predicates, and the built-in functions will be treated as syntactic sugar for the corresponding built-in predicates.

<sandro> Hassan: The basic syntactic sugar of CLP is all you need here.

<sandro> Hassan: The constraints should have the capacity of being well-denoting expressions.

<sandro> MichaelKifer: If we only dealt with rule languages this wouldn't be a problem, but when you think about extending to FOL, well.... I'm avoid making committments which complicate that. Once we decide to translate differently in the Head vs Body, then we break the idea of BLD being a subset of FOL.

<sandro> MichaelKifer: The constraint is a conjunct?

<sandro> Hassan: The constraint is anything. It can be an oracle.

<sandro> MichaelKifer: So the FOL dialect would have to be a "constraint FOL" ?

<sandro> Hassan: No, the constrain is just a relation.

<sandro> MichaelKifer: A constraint is a formula, right? ( a predicate, a relation ) How is it going to be related to the main formula? A conjunct or what?

<csma> p(f(a)) :- body -> p(x) :- body AND x = f(a)

<sandro> Hassan: You don't need to worry about that. The connection is just the shared variables. This is explained very clearly in @@@

<ChrisW> seems to me we've gotten off track

<Hassan> MK: functions appearing in the head of a rule makes things complicated

<ChrisW> functions treated as syntactic sugar for predicates cause problems in the head, and will complicate an extension to e.g. FOL?

<GaryHallmark> a better semantic match for my PR engine is to model a distinguished "error" element in the domain

<AxelPolleres> I agree that built-ins (functions or predicates, both I assume) in head are problematic

<sandro> Can we just outlaw builtins in the head?

<MichaelKifer> i already proposed this - csma didn't like

<AxelPolleres> We can safely disallow them in heads. so what's the problem?

<ChrisW> +1 to disallow in head

<ChrisW> i like keeping bld a subset of FO

<sandro> (as do I)

<Hassan> sandro: what does csma need bi's in the head?

<AxelPolleres> We talk about built-ins, not actions!!!

<AxelPolleres> a function or predicate is something with a fixed semantics, not something which changes the world

<AxelPolleres> you talk about := not about ==

<sandro> Ah - I get it. If p(x) then q(f(x))

<ChrisW> :)

<markproctor> sorry my other phone went off

<AxelPolleres> I don't understand why this is built-ins still.

<Harold> Christian's example without introducing Equal: p(f(a)) :- body -> p(x) :- body AND f(x a)

<ChrisW> Well, BLD doesn't do a lot of useful things

<ChrisW> if p(x) AND y=f(x) THEN q(y)

<AxelPolleres> If you would expand christian's example to predicates as discussed before, the actual builtin call would be in the body.

<AxelPolleres> yup.

<Hassan> csma: is reluctant to pass a resolution on this now

<Hassan> Gary Hallmark: just treat undefined as an exception -> maps the value of the predicate to false

<Harold> Gary, Michael, in "strict" functional languages an error element raised somewhere makes all enclosing expressions into errors.

<Hassan> MK: need a different semantics to treat undefined (special URL?), then what this denotes

<Hassan> csma: how do the FOL rule languages deal with this?

<Hassan> MK: they don't - they issue an error - it is not in the semantics

<ChrisW> i'm not sure we need to have a model theory for errors

<Hassan> csma: summing up - we want functions (maybe in the head) and semantics of error

<Hassan> ChrisW: we don't need to account for error model-theoretically

<Harold> If we want to be "strict", then we need something equivalent to saying f(a1,...,aJ-1,error,aJ+1,...,aN) = error for all f.

<Hassan> MK: if so, then we need to restrict the use of functions to reach a meaningful compromise

<Hassan> csma: why not flag it as an error?

<Hassan> MK: then it would be a syntactic issue, but with BI's you can't do this because not all is statically verifiable

<Hassan> MK: we need to define the meaning of the expression when evaluating it gave an error

<Harold> The "Catch" operator is "non-strict".

<Harold> Catch(a1,...,aJ-1,error,aJ+1,...,aN) != error

<Harold> (see http://en.wikipedia.org/wiki/Functional_programming)

<Hassan> ChrisW: did we really mean to treat error in FOL as well? I do not think that it should be boggle us down ... we can do something else

<Hassan> MK: what "something else"?

<Hassan> csma: looking for a victim ... :-)

<PaulaP> bye...

<Harold> Paula and All, I did my ACTION-397: http://www.w3.org/2005/rules/wg/wiki/Core?action=diff&rev2=64&rev1=63 (I hope you are fine with the spelling of "builtin")

<ChrisW> -ChrisW

<ChrisW> :)

<Hassan> MK: proposes to put the burden of having function symbols on the translator (they define the synctatic surgar they mean)

<ChrisW> BLD+-+--

<Hassan> +1

<ChrisW> Dear Santa, please bring me a model theory for errors

<Hassan> csma: proposes to adjourn

<sandro> :-)

<ChrisW> bye all happy new year!

<sandro> happy december, everyone

<AxelPolleres> for a crude 3valued logics for errors for filters... look at the sparql spec ;-) good bye.

<AxelPolleres> it's not so bad, btw.

<AxelPolleres> bye now!

<csma> scribenick: hassan

<sandro> sorry - personal phone call.

- DRAFT -

RIF telecon 18 December 2008

18 Dec 2007

Attendees

Contents

Admin

Summary of Action Items

Scribe.perl diagnostic output