<Harold> Hi Axel!

<AxelPolleres> Hi!

<AxelPolleres> do we have the Core conf call now?

<AxelPolleres> dial-in number as usual?

<Harold> Can u try to join with the EU phone number?

<AxelPolleres> the normal code?

<Harold> Yes, try it.

<Harold> this is RIF-CORE

<AxelPolleres> maybe one word?

<AxelPolleres> anyway...

<AxelPolleres> in the worst case, we can just save and send around the IRClog manually

<AxelPolleres> perfect

<AxelPolleres> scribe: AxelPolleres

<scribe> scribenick: Axel Polleres

<AxelPolleres> http://www.w3.org/2005/rules/wiki/Core

<AxelPolleres> issues are summarized at: ???

<AxelPolleres> harold: let's go through the issues.

<AxelPolleres> ... first one: keep membership "#" in core.

<AxelPolleres> Dave: trying to keep it as small as possible.

<Harold> Michael, thanks

<Harold> it was again a high-pitch noice.

<AxelPolleres> Dave: syntactic suger should rather not be included.

<AxelPolleres> ... similar to but not quite the same as rdf:type.

<AxelPolleres> ... preferences for avoiding confusion.

<Harold> We are discussing Agenda items

<Harold> Michael, maybe u have to type here.

<Harold> Open Core issues [2] and initial PROPOSED resolutions

<AxelPolleres> Can we summarize the diffs between # and rdf:type again?

<Harold> Michael, re "PROPOSED: Keep membership/subclass in Core", what is the benefit of "(maybe limiting these constructs to rule bodies)"?

<AxelPolleres> Axel: type is ok, only subclass is discussed.

<Harold> Is it this? When we allow membership/subclass only in rule bodies, # and ## cannot be reDEFINEd.

<AxelPolleres> Gary: main issue is that they are both (subclass/##, membership/#) should not be allowed in the conclusions

<Harold> Michael, can u type in something here???

<AxelPolleres> Gary: datamodels translated into RIF might have memership/subclass (e.g. Java Beans)

<MichaelKifer> I think the benefit is that in PRD the ##/# things cannot be augmented/redefined by rules.

<AxelPolleres> ... datamodel could be translated rather with OWL or an ontology language rather than RIF

<AxelPolleres> Dave: you want membership test in Core?

<Harold> Thanks, Michael!

<AxelPolleres> ... in a PR setting, you say you can't change membership, yes?

<Harold> Dave, would you be even less object with such a restriction?

<AxelPolleres> Gary: it is the same status as equal foe me, just as equal.

<Harold> Dave, would you even less object with such a "(maybe limiting these constructs to rule bodies)" restriction?

<AxelPolleres> Dave: seems reasonable, #/## only in rule bodies.

<AxelPolleres> Axel: BUT rdf:type is the same as #, so we can't allow one and disallow the other in Core.

<DaveReynolds> Dave response to Axel: the use of # is a syntactic restriction only, RDF users could still have rdf:type in conclusion

<Harold> Dave: Even with the restriction, #/## could still be possibly confused with the similar RDF constructs.

<AxelPolleres> Gary: Not everyone has to implement RDF as their datamodel

<AxelPolleres> Axel: Either #/## in both body and head or nowehere, all other is unclear, if the rdf versions are allowd (rdf:type, rdfs:subClassOf)

<DaveReynolds> Gary: subclass is so rarely used don't require its inclusion in Core

<Harold> All: Since we are scribing in a distributed manner, "PersonName: ..." (colon) should be restricted to taking notes about what PersonName said. "PersonName, ..." (comma) should be used for addressing PersonName.

<AxelPolleres> "PROPOSED: Keep membership/subclass in Core"

<AxelPolleres> was the original

<DaveReynolds> PROPOSED: RIF Core will not include subclass (##)

<DaveReynolds> PROPOSED: RIF Core will include member (#) but syntactically restricted its use in rule bodies. Note that in RIF-RDF the equivalent property rdf:type would still be permitted in rule heads.

<GaryHallmark> rationale: PRD rules almost always start with "if p is a person and p.age > 16 and ... then ...

<GaryHallmark> also, almost no PRD system allows ... then p is a person

<AxelPolleres> Dave: In XML syntax we have "member" for # but also rdf:type is allowed.

<GaryHallmark> but ok ... then p.type = "person"

<AxelPolleres> ... so the compromise might work.

<DaveReynolds> Axel: would prefer both allowed, without restrictions.

<DaveReynolds> Gary: would object if they are allowed in conclusions.

<AxelPolleres> Axel: Dave's proposals are fine for me

<Harold> > > http://www.w3.org/2005/rules/wg/track/issues/71

<Harold> > > PROPOSED: Core should keep unrestricted equality and external function

<Harold> > > calls in rule bodies and keep external functions calls in rule heads.

<AxelPolleres> next one issue 71

<AxelPolleres> PROPOSED: Core should keep unrestricted equality and external function and predicate calls in rule bodies and keep external functions calls in rule heads.

<AxelPolleres> Objections?

<DaveReynolds> Seems fine.

<Harold> (The above PROPOSED for issue 48 was accepted by us here.)

<AxelPolleres> agreed by all.

<AxelPolleres> next one:

<Harold> > > http://www.w3.org/2005/rules/wg/track/issues/74

<Harold> > > PROPOSED: Core should keep both frames/objects and

<Harold> > > (positional-argument) predicates/relations.

<AxelPolleres> Dave: we don't have predicates in RDF, we have to simulate that, but should work. Just frames would be better for us.

<AxelPolleres> ... but I won't gonna object.

<GaryHallmark> Just frames is better for us, too

<AxelPolleres> Harold: Also better for you Gary?

<MichaelKifer> are all these PROPOSED things the ones to be proposed to the WG?

<Harold> Michael, yes, that's the idea.

<AxelPolleres> ... Is there a standard relation between datalog rules and frames-only?

<Harold> Gary: I think that's ok.

<AxelPolleres> Gary: should be ok.

<Harold> Axel: Emulate by introducing new IDs?

<Harold> Gary: Using Java beans.

<AxelPolleres> Gary: right, new id/object per tuple.

<AxelPolleres> Harold: Should translator be part of the spec?

<Harold> We could have a 'standard' translation of this kind.

<AxelPolleres> ...(from tuples to object)

<Harold> "Two-level Core".

<Harold> Axel: Cannot be part of spec, since eg in RDF u would use BNodes, in Flogic somthing else...

<Harold> But maybe some Rel-to-Obj mapping.

<AxelPolleres> Gary: A Note, as opposed to a concrete guidance, seems suficient here.

<Harold> (Like there is a more or less standard Obj-to-Rel mapping.)

<AxelPolleres> PROPOSED: Core should keep both frames/objects and (positional-argument) predicates/relations.

<Harold> > > http://www.w3.org/2005/rules/wg/track/issues/75

<Harold> > > PROPOSED: Core should keep disjunction in rule bodies (cf. Gary's UC).

<AxelPolleres> Gary, you would allow then a(X) :- Or( b(X) c(Y) ). ?

<GaryHallmark> axel, no I don't need that case

<GaryHallmark> e.g. if p is a person and p.age < 14 or p.age > 33 or p.smoker = "yes" then ...

<AxelPolleres> Dave: if it is only a syntactic transformation, then fine.

<GaryHallmark> note p is bound outside of the Or (i.e. by a membership

<DaveReynolds> Axel: the issue is safety again, see above rule example, if C(Y) is true then X can be unbound

<Harold> Strict SafeNESS

<AxelPolleres> Axel: Or in thbodies is strongly related to safeness.

<AxelPolleres> ... I can formulate the various safeness definitions by the F2F, probably, but won't have time before to write it down :-(

<AxelPolleres> PROPOSED: Core should keep disjunction in rule bodies, only if this is permitted by the solution to issue-70.

<AxelPolleres> :-)

<Harold> > > http://www.w3.org/2005/rules/wg/track/issues/76

<Harold> > > PROPOSED: Core should keep unrestricted equality in rule bodies (cf.

<Harold> > > ISSUE-71).

<Harold> >

<Harold> > Agreed.

<AxelPolleres> fine... we don't need that anymore.

<Harold> > > http://www.w3.org/2005/rules/wg/track/issues/70

<Harold> > > PROPOSED: Parameterize the conformance clauses of Core with

<Harold> > > safeness requirements "strict", "weak", and "none" (default: "none").

<Harold> My clarification:

<Harold> I meant "strictly-safe" (a), "weakly-safe" (b), and "unsafe" (d)

<Harold> conformance levels similarly as defined/linked in/from issue 70.

<Harold> Perhaps a version of Dave's (c) could become another level.

<Harold> http://www.w3.org/2005/rules/wg/track/issues/70

<DaveReynolds> Harold: to see safeness have to do data flow analysis, which may not always be possible so have to default back to unsafe

<GaryHallmark> I think strict safeness is ok for PRD

<DaveReynolds> Axel: unless binding patterns are declared can't find anything more out. What would be an example?

<DaveReynolds> Harold: if you know the query, the constants in the query would propagate.

<DaveReynolds> Axel: but that is safe *use* of ruleset, not that the ruleset itself is safe

<DaveReynolds> Axel: how would you define weakly safe core without binding patterns?

<AxelPolleres> ACTION: Axel to write down the definitions of strict and weak safety of a ruleset. [recorded in http://www.w3.org/2008/09/22-rif-minutes.html#action01]

<trackbot> Created ACTION-577 - Write down the definitions of strict and weak safety of a ruleset. [on Axel Polleres - due 2008-09-29].

<Harold> Michael, can u say something?

<AxelPolleres> Michael, can you type instead?

<Harold> I only hear the high-pitch noice.

<AxelPolleres> ... on IRC?

<AxelPolleres> BTW: I have not much time left (5-10min)

<AxelPolleres> I am afraid they kick me out of the room in some minutes.

<Harold> It's called SafeNESS.

<AxelPolleres> Dave: In jena we have both LP style and PR style

<GaryHallmark> probably the stricter the better (but don't forbid disjunction completely) is best for PRD

<AxelPolleres> Michael: binding patterns depend on execution strategy

<AxelPolleres> ... strict safety is ok.

<Harold> The 'Safeness' discussion seems to move us towards procedural semantics ...

<Harold> PROPOSED: Core will have a strict safeness restriction.

<AxelPolleres> Dave: would object.

<Harold> PROPOSED: Parameterize the conformance clauses of Core with safeness requirements "strict" and "none" (default: "none").

<AxelPolleres> ok, seems we have all, I need to leave!

<Harold> (modulo nice word for "none")

<Harold> All agree.

<AxelPolleres> bye!

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/edi n/ed in/
Succeeded: s/to use/its use/
Found Scribe: AxelPolleres
Inferring ScribeNick: AxelPolleres
WARNING: No scribe lines found matching previous ScribeNick pattern: <Axel\ Polleres> ...
Found ScribeNick: Axel Polleres
WARNING: No scribe lines found matching ScribeNick pattern: <Axel\ Polleres> ...

WARNING: 1 scribe lines found (out of 209 total lines.)
Are you sure you specified a correct ScribeNick?

ScribeNicks: Axel Polleres, AxelPolleres

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: All Axel AxelPolleres BTW Dave DaveReynolds Dave_Reynolds Gary GaryHallmark Michael MichaelKifer MoZ NRCC P10 P9 PROPOSED aaaa aabb aacc be harold now rationale scribenick should trackbot was
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 22 Sep 2008
Guessing minutes URL: http://www.w3.org/2008/09/22-rif-minutes.html
People with action items: axel

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report