W3C

- DRAFT -

RIF telecon 18 December 2008

18 Dec 2007

Agenda

See also: IRC log

Attendees

Present
Hassan_Ait-Kaci, csma, Harold, IgorMozetic, Stella_Mitchell, ChrisW, PaulaP, Gary_Hallmark, Sandro, AxelPolleres, Mark_Proctor, MichaelKifer, LeoraM
Regrets
JosDeBruijn, PaulVincent
Chair
Christian de Sainte Marie
Scribe
Hassan Haït-Kaçi

Contents


<csma> Scribe: Hassan Haït-Kaçi

<csma> scribenick: Hassan

<csma> zaki, reset agenda

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

Admin

No agenda amendments ...

Accepting last week's minutes postponed to next week?

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

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

RESOLUTION: accept the minutes of Dec 4 2007

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

Christian worries about posting of meetings early enough...

Merry everything ... :-)

Action 394 done

Action 395 done

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

Harold says see Wiki for Action 395

Harold comments his changes in the document

Ask MK to review the changes ...

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

Igor wonders about OWL F2F meeting in Manchester...

<ChrisW> ^Igor^Harold

Sandro was there ...

Sandro does not have anything to report

Harold wonders about DL safe rules in OWL

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

Just getting the basics to get the WG going

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

Any other liaison?

None

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

Issue 40 - about builtins

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

last week the syntax for evaluated preds and funcs was resolved

this week we need to discuss the rest

item: what builtins for BLD?

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

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

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

csma: since the others are not here ...
... there 3 sets (1) numerics (2) strings (3) date and time
... 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

ChrisW: this is hard to record

Sandro: put a link to the front of the page

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

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.

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

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)

ChrisW: propose to put an action on someone to fix it

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

Paula?

<Harold> Current appendix:

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

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

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

should speak up

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

MK: what semantics?
... functions as builtins require a notion of error ...

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

csma: using a predicate notation ?

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> scribenick: sandro

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

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

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.

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)

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

(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

<scribe> scribenick: Hassan

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

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?

MK: needs to explain more

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

ChrisW: we could require that external functions calls be total functions

MK: cannot garantee that

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

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

harold: wonders about equality of functions
... 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)

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

MK: sure ...
... how to name the introduced predicates? all this need to be made explicit ...
... if functions are syntactic sugar, we need to give the semantics of the "real" thing they stand for

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

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.

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

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

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

<Harold> I see

<Harold> Gary.

<sandro> scribenick: 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.

Hassan: The basic syntactic sugar of CLP is all you need here.
... The constraints should have the capacity of being well-denoting expressions.

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.
... The constraint is a conjunct?

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

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

Hassan: No, the constrain is just a relation.

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)

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

<scribe> scribenick: 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)

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.

csma: is reluctant to pass a resolution on this now

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.

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

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

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

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

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.

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

csma: why not flag it as an error?

MK: then it would be a syntactic issue, but with BI's you can't do this because not all is statically verifiable
... 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)

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

MK: what "something else"?

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

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

<ChrisW> BLD+-+--

+1

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

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.

<markproctor> hmm I just got cutt off

<ChrisW> telecon is over

<markproctor> ok

<ChrisW> sandro, can you join for a sec

<markproctor> heh, we still didn't get to discuss uniterm for slotted representations

<csma> no :-(

<csma> btw, do you want them or not?

<markproctor> well they are needed for production rules

<csma> can you past a use case on the mailing list?

<markproctor> but over all I think its necessary, not just for production rules, to have anonymous slotted notation

<markproctor> frames insist that it has a url

<markproctor> which isn't always the case

<markproctor> anyway we can discuss this in another call

<csma> @Mark, what do you mean, frame insist that it has an URL? The slot name? Not if it is rif:local, does it?

Summary of Action Items

[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/02/23 21:38:13 $