RIF Telecon 8 Jan 2008 -- 8 Jan 2008

<csma> Hi EtnaRosso! Who are you?

<EtnaRosso> hi csma

<EtnaRosso> i don't think we never meet

<EtnaRosso> hi ChrisW is starting a meeting?

<csma> EtnaRosso, are you a member of the RIF WG?

<EtnaRosso> no no

<EtnaRosso> have a good meeting, see you

<csma> Thank you. See you.

<ChrisW> do we have a scribe?

<csma> No scrbe, if I remember correctly

<Hassan> Am I the only one on the phone?

<ChrisW> yes

<ChrisW> coming

<Hassan> It's lonely out here ... :-(

<csma> coming

<ChrisW> Scribe: StellaMitchell

Admin

<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2007Dec/att-0087/2007-12-11-rif-minutes.html

<ChrisW> RESOLVED: Accept minutes of Dec 11 telecon

chrisw: minutes from Dec 11 meeting. Any objections? ... no

<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jan/att-0000/18-rif-irc.html

<ChrisW> RESOLVED: Accept minutes of Dec 18 telecon

chris: minutes from Dec 18. Any objections? ... no objections

chrisw: There is now a new wiki page for posting regrets

<csma> http://www.w3.org/2005/rules/wiki/TeleconRegrets

chrisw: there will be a link to it on the new home page soon
... use this page from now on. it will have all the regrets for all the meetings.
... the official record of regrets is the minutes of the meeting

Liason

any news from liasons?

jos: should we report about RIF-OWL task force now?
... we will have our first meeting tomorrow, and we have been discussing a proposal

chris: when do you tihnk you'll have something to show the working group?

jos: 2 weeks, not final but something

chris: resposes to pfps comments. these are on the main page. I think number 1 is finished
... people can have a few days to look at it, then we'll send it out
... unless someone objects. Will send response later this week.

<AxelPolleres> Can you paste the link again? thnx

<ChrisW> http://www.w3.org/2005/rules/wg/wiki/Response_to_PPS2

chris: I don't think the 2nd response is ready.
... change 2 to 1 to get first response
... any other liason news?

Issue 44

BLD & Core

chris: I posted proposals for resolution of issues 41 and 43

<ChrisW> PROPOSED: Close Issue-43 by including in BLD subclass formulae of the form a ## b. In the RDF compatibility document, ## and rdfs:subClassOf will be connected appropriately, i.e. whenever a ## b holds, a rdfs:subClassOf b is required to hold.

chris: the change here is that there is a formal relationship between rdf and rif subclass relations
... any discussion on this?
... we will now vote on this

<sandro> +1

vote on IRC

<csma> -0

<DaveReynolds> +0

<IgorMozetic> +1

<josb> +0

<Hassan> +0

<PaulVincent> +0

<LeoraMorgenstern> +1

oops, sorry

<mdean> +1

<Harold> +1

<AxelPolleres> +1

<AxelPolleres> What is the diff between +0 and -0, btw?

<MichaelKifer> +1

<sandro> repeating: <ChrisW> PROPOSED: Close Issue-43 by including in BLD subclass formulae of the form a ## b. In the RDF compatibility document, ## and rdfs:subClassOf will be connected appropriately, i.e. whenever a ## b holds, a rdfs:subClassOf b is required to hold.

<ChrisW> RESOLVED: Close Issue-43 by including in BLD subclass formulae of the form a ## b. In the RDF compatibility document, ## and rdfs:subClassOf will be connected appropriately, i.e. whenever a ## b holds, a rdfs:subClassOf b is required to hold.

<ChrisW> PROPOSED: Close Issue-41 by including in BLD membership formulae of the form c # a. In the RDF compatibility document, # and rdf:type will be connected appropriately, i.e. a # b holds iff a rdf:type b holds.

cw: next is issue 41, membership
... any discussion on this?

csma: I wonder if this resolution would impact the way membership is handled with XML documents or XML schema data models or other data models
... ...the fact that it is equivalent to rdf:type

cw: only use it if semantics is appropriate for your case

csma: we want it to be used by all rif users, not just in the case of rdf documents
... I don't know whether there is an impact; I think we need to consider the question
... ...(dave's use case)

jos: this is for use with different data models, not just rdf
... this proposal already assumes object oriented xml, so it might work
... for general xml it would not work, because membership is different from xml schema type

<Hassan> I understand the same as ChrisW ...

csma: I thought we didn't give semantics to rif membership, we just said it is equivalent to rdf:type

cw: the semantics for rif membership are given in the rif document

jos: the equivalence (with rdf) holds when you are talking about rif rdf combinations
... it would be possible to define a weaker kind of correspondence
... if you don't combine it with rdf (external rdf graph), then you don't inheirit any of the rdf semantics

cw: bld semantics stands by itself

csma: from the interchange point of view: between an rdf rule engine and a c++ rule engine
... if they have the same semantics as rdf:type, it is ok, but if not not
... maybe we will need to have different membership relations for different kind of data models

hassan: I don't think RIF is defined to be compatible with RDF.. it just happens to be in this case
... don't need different relations for different data models, you may just have to do some interfacing

cw: this is the type relation used by basic logic dialects

<Harold> Jos, what about OWL compatibility? How will "a # b holds iff a rdf:type b" generalize to DL-inferred OWL memberships?

csma: prd will also need membership relation, if it makes sense to have the same one and have it in core, that would be preferable

jos: rif membership is not the same as the rdf:type construct
... there is a correspondence, but it is not the same

also, if there are different type of membership relations, you will have to encode them differently in rif

scribe: but wg seems to want to have one particular relation in the language

cw: any other discussion?
... does anyone want to ojbect to this proposed resolutiion? ... no

cw: vote on IRC

<Hassan> +0

<sandro> +1

<IgorMozetic> +1

<Harold> +1

<AxelPolleres> +1

<DaveReynolds> +0

<csma> 0

<MichaelKifer> +1

<LeoraMorgenstern> +1

<josb> Harold, this will depend on how OWL compatibility will be defined in the end; see also http://www.w3.org/2005/rules/wg/wiki/SWC/OWL-Compatibility

<mdean> +0

<josb> +0

<PaulVincent> =0

<GaryHallmark> +1

cw: 7 for, 5 abstain

<ChrisW> RESOLVED: Close Issue-41 by including in BLD membership formulae of the form c # a. In the RDF compatibility document, # and rdf:type will be connected appropriately, i.e. a # b holds iff a rdf:type b holds.

<Harold> Jos, great, I guess the RIF-OWL task force is looking into this?

<josb> Harold. correct

<ChrisW> PROPOSED: Core does not have membership and classification.

cw: a few people requested that we also have a resolution that these features will not be in the core language
... any discussion on this? does anyone object?

csma: the question is if we want to have the same membership and classification in prd, then I think it makes sense to have them in core

cw: that would need further study before we pass a resolution?

csma: I'm not sure

jos: not having membership and classification in core, does not preclude having them in prd

csma: right, but if everyone needs them for rule interchange it would make sense to have them in core

cw: csma, do you want to postpone this vote?

<IgorMozetic> I vot for vote!

<josb> we can always overturn a resolution if we have more info

csma: I just wanted to raise this point, and see what others think?

harold: csma, do you think you will need one of these things (membership, classification) in prd?

csma: in prd we will need a way to check class membership

<josb> yes

<DaveReynolds> probably :-)

cw: does anyone object to having membership in core?

<ChrisW> PROPOSED: Core does not have membership and classification.

sandro: I think no one wants these relations in core and no one objects, is that right?

cw: people don't feel strongly about it

sandro: I don't think we are ready to decide this yet

<Hassan> +1 with sandro - what's the rush before we have used the RIF for real?

sandro: I am in favor of having them in core

<PaulVincent> What rule language classes (dialects) would NOT have membership / classification? I wonder

sandro: if every dialect needs them

cw: ok, we will postpone this vote, and we need to open an issue on it

<josb> Paul, all rule langs based on rdf or owl do not need # or ##

<GaryHallmark> I can see them in Core bodies, but not in heads, but that seems complex to specify

<ChrisW> ACTION: christian to open an issue on whether membership and classification are in core [recorded in http://www.w3.org/2008/01/08-rif-minutes.html#action01]

<trackbot-ng> Created ACTION-399 - Open an issue on whether membership and classification are in core [on Christian de Sainte Marie - due 2008-01-15].

<Hassan> Paul: What about Prolog?

Issue 44

<ChrisW> http://www.w3.org/2005/rules/wg/track/issues/44

cw: this is the issue about named arguments to predicates and functions in bld
... any discussion on this issue?

csma: what is the purpose of having two different slotted notations: frame and named argument uniterms?

<AxelPolleres> well, jos now we defined # as syntactic sugar for rdf:type, so in presentation syntax it might be more convenient (like "a" in turtle/n3), but you are right it is not NEEDED.

cw: named argument uniterms to not implicitly create an object, so if you're using a relational semantics you don't have to create an other object

csma: if you deal with relational semantics, why do you need the name for the arguments?
... why not use positional uniterms when you have relational semantics
... what is the benefit of having them named?

<josb> +1

cw: if you have a predicate that has a lot of arguments and you don't want to specify all of them

mk: with named args, you have to specify all, but you don't need to remember their order

<GaryHallmark> let's simplify things and drop slotted uniterms

<josb> +1 agree with Gary

<DaveReynolds> +1 to Gary

<Harold> Let's look at this CLIPS example:

<Harold> (deffacts trouble_shooting

<Harold> (car_problem (name ignition_key) (status on))

<Harold> (car_problem (name engine) (status wont_start))

<Harold> (car_problem (name headlights) (status work))

<Harold> )

<Harold> http://en.wikipedia.org/wiki/CLIPS

mk: with positional arguments, if all are not there, it's not clear which is missing

csma: harold, I do not understand the example posted by harold above

<DaveReynolds> Harold - aren't these slots, not named arguments in uniterms?

harold: this example shows named arguments, where the order does not matter, it is a convenience

csma: it constructs objects

harold: but there is no oid

hassan: we have decided to distinguish between frames and terms, but they are basically the same thing

<Harold> Dave, do you mean slots in frames vs. named arguments in uniterms?

csma: we have proposed semantics for frames and named argument uniterms. do you think we could choose just one of these?

<DaveReynolds> Harold, yes.

hassan: yes, the best compromise that can express most things
... they are just labelled graphs

cw: the main difference between these two is the oid issue. how important is that?

<Harold> Then, I think it is good to have both.

harold: without the oid, we cannot apply the function, therefore we need named argument uniterms

csma: re: clips example above. if my ignition key is on and engine won't start and headlights don't work. wouldn't there need to be an object here?

<ChrisW> ack

harold: but the 3 inner uniterms would be anonymous

mk: i think we are getting sidetracked. we are not defining a language, we are defining a framework
... we have frames, positional terms, and named argument terms, is that we will have dialects that use these styles, and we want to facilitate interchange

cw: any other discussion?

<IgorMozetic> +1 for mk

daver: about what mk said, do we have a use case that requires named uniterms?

<ChrisW> OO JDREW & CLIPS

<josb> I prefer to not have them, but can live with mk's compromise (like the membership and subclass compromises)

daver: those are production dialects

<Harold> We have a nice transition: positional uniterms -add slots-> slotted uniterms (with named arguments) --add oids-> slotted frames

cw: are there logic languages that have these?

mk: oo jdrew is a logical language

<Hassan> Same opinion as josb (i.e., do not care either way, leaning toward the simpler - i.e., not having them)

daver: what do you mean by a transition?

<AxelPolleres> slotted frames are definitly NOT an "extension" of sloted uniterms...

<AxelPolleres> ... I wonder a bit about what Harold means here.

harold: interchange format, so need to accomodate clips

daver: that would be prd dialect, not bld

<AxelPolleres> anyway, I think the abstract model definition accomodated for all, so it wouldn't need be a problem.

<LeoraMorgenstern> I think we should have it ...

cw: does anyone feel strongly that we shouldn't have named argument uniterms?

<LeoraMorgenstern> I didn't realize we were being polled yet

cw: let's have a straw poll

<Hassan> -0.00001

<DaveReynolds> - 0.5

<Harold> +1

<MichaelKifer> +1

<ChrisW> STRAW POLL: Having named uniterms in BLD

<LeoraMorgenstern> +1

<AxelPolleres> +0.7

<IgorMozetic> +0.8

<sandro> +0.75

<mdean> -0.5

<PaulVincent> -0

<josb> +0

<LeoraMorgenstern> If only we could vote in the primaries this way.

<GaryHallmark> -0.5

cw: I would like to know who would object to this

<csma> -0

<sandro> +0

<josb> +0

<GaryHallmark> -0

<Hassan> -0

<PaulVincent> -0

<AxelPolleres> We have a semantics for it, it is clear what it means, no reason to delete it from BLD...

daver: -0.5 means I might object, but I am not sure yet

<csma> I change my -0 for a -0,5

<AxelPolleres> I obviously wouldn't like it in core.

<Harold> So it's again a question of core vs. bld.

<csma> based on Dave's interpretation of -0,5

<josb> -1 for having it in Core

Issue 47

<ChrisW> http://www.w3.org/2005/rules/wg/track/issues/47

cw: this issue is about equality

<AxelPolleres> yes, core should be datalog w/o equality, (as discussed/suggested sometimes), right?

cw: ...equality is currently in bld semantics, but it is difficult to implement

<AxelPolleres> .... (the yes was to harold)

mk: it's a useful thing that is hard to implement, but can be partially implemented easily

sandro: this came up during the conformance discussion
... we want it to be possible to completely implement RIF

<IgorMozetic> +1 for sandro

sandro: we want there to be conformant implementations

<Harold> Axel, Jos, if we were to have no Clips-like slotted uniterms (with named arguments) in core, there would be an increased risk that prd would not be built on core (and perhaps not on bld, because that might be too much).

mk: won't slow down the usual cases

<GaryHallmark> Harold, I think your CLIPS example does in fact have OIDs

sandro: ok, that is not so bad

<ChrisW> gary - can you scribe next week?

<GaryHallmark> Harold, look at http://www.ghg.net/clips/download/documentation/bpg.pdf page 206 for example

<GaryHallmark> chrisw, ok

<ChrisW> thanks!

mk: ground equality. can not really specify this cleanly in the language

<DaveReynolds> I'm confused by the term "implementation" here, implementing RIF means implementing a translator, not a rule engine

mk: it will make a mess out of the language if we try to specify the easily implemented cases
... at the language level

<sandro> (So, I understand MichaelKifer to be saying that he (Flora) can implement BLD. Some kinds of equality will be slow to handle, some will be fine, and all can be done.)

cw: does anyone in the group really want equality removed from BLD because it is hard to implement efficiently in its full generality?

<AxelPolleres> No way to remove it from BLD, I see BLD rather as a dialect which CAN be implemented, but not which MOST rule engines could cope with.

<DaveReynolds> Seems preferable to postpone to a higher dialect

<Harold> Gary, "in fact"? Do you mean there will be three oids generated and returned to the user? Generating oids can be seen as transiting from slotted uniterms to slotted frames.

sandro: process note: the usual way this works is that during candidate recommendation we have to provide evidence that there are at least two complete implementations

<AxelPolleres> I see BLD more as a "repository" which subdialects/profiles can draw the clear definitions from.

cw: I'm not sure how strict a requirement that is; OWL didn't have complete implementations

axel: I see bld as the semantic framework for logic based definitions of rule languages...but it doesn't mean that any single rule system needs to implement every feature in bld

cw: but bld is the basic logic dialect

<sandro> Axel argues for BLD as UNION. I beleive it should be the INTERSECTION.

<Harold> Axel, I agree, this was also Michael's and my *interchange format* argument.

<AxelPolleres> Harold, yes!

<AxelPolleres> ... I get it now. We will not implement full BLD, but it is useful to have it semantically defined within RIF.

<sandro> straw-proposed: remove equality from BLD

cw: is there anyone who is even leaning towards wanting to remove equality from bld?

<GaryHallmark> Harold, the first assert creates fact-id 1, the second creates fact-id 2, etc. and these fact-ids may be used later to retrieve slot values

<AxelPolleres> s/it defined/equality defined/

<sandro> -0 keep equality in BLD

<AxelPolleres> We need a core profile or subdialect or whatever you want to call it.

<sandro> er -- that is, I want to keep equality in BLD.

csma: I am leaning in that direction, but less than I was before

cw: let's have a straw poll

<ChrisW> STRAW: closing issue 47 without action

<Harold> Axel, I agree, although we could run full BLD in a FOL porver with Equality.

<sandro> +1

<josb> +1

<Harold> +1

<LeoraMorgenstern> +1

<DaveReynolds> -0

<IgorMozetic> +1

<MichaelKifer> +1

<AxelPolleres> +1, with still claiming for a CORE profile/subdialect

<mdean> +1

<csma> =0

<GaryHallmark> +1 to keep equality in bld

cw: we will try to have a resolution on this at next week's telecon

<AxelPolleres> Did we now raise/record an issue?

cw: any objections to adjouring?

AOB - pick a scribe

<Harold> Gary, Thanks.

<PaulVincent> bye

- DRAFT -

RIF Telecon 8 Jan 2008

8 Jan 2008

Attendees

Contents

Admin

Liason

Issue 44

BLD & Core

Issue 44

Issue 47

AOB - pick a scribe

Summary of Action Items

Scribe.perl diagnostic output