<sandro> Changhai: in foo # X X is a type, not a collection....

<sandro> Sandro: Is this work necessary to PRD?

<sandro> Paul: Yes, althoug maybe we need even better access to XML (than frames allow).

<sandro> Gary:My proposal is pretty much how our product works (jaxb style -- flash conversion). The XPath peek & poke approach would be something we'd have to hide in translation.

<sandro> Gary: I'm not wedded to using the schema to construct names. JAXB just uses the local names.

<sandro> sandro: If RIF doesn't do this, you'll need to do a non-standard version of this?

<sandro> csma, paul, gary: yes.

<sandro> paul: PRR dodges this issue.

<sandro> Adrian: reaction-ruleml has a way to do something like this.

<sandro> csma: You could re-use this work with UML instead of Schema.

<sandro> "Using RIF with XML and Object-Oriented Data" ?

<sandro> csma: I think we'll be content with just "Using RIF with XML"

<AdrianP> additionally in a query /constraint expression language you could explicitly define closures over object relations which can not be done directly in FOL

<sandro> csma: If you want to *really* retrieve a class and it's subclasses, you need to do it several different ways, given XMLS.

<PaulVincent> Way ahead suggestion: have 1 or more DSLs evaluate these approaches for embedding XML-enabled PRD in their docs, eg MISMO?

<sandro> PROPOSED: Create a new document, something like "Using RIF with OWL", addressing ISSUE-37 and ISSUE-38, in the space of Gary and Christian's proposals, for RIF rules to use XML data wth and without a schema. What it specifies should work with Core, BLD, and PRD, and is important to the success of RIF.

<sandro> gah. typo of "OWL" for "XML" :-)

<sandro> PROPOSED: Create a new document, something like "Using RIF with XML", addressing ISSUE-37 and ISSUE-38, in the space of Gary and Christian's proposals, for RIF rules to use XML data wth and without a schema. What it specifies should work with Core, BLD, and PRD, and is important to the success of RIF.

<sandro> csma: it's important that whatever we do relies on features in current engines. and be extensible for doing stuff like more of XPath in the future.

<sandro> PROPOSED: Create a new document, something like "Using RIF with XML", addressing ISSUE-37 and ISSUE-38, in the space of Gary and Christian's proposals, for RIF rules to use XML data wth and without a schema. What it specifies should work with Core, BLD, and PRD, and is important to the success of RIF.

<ChrisW> i haven't been part of the discussion

<ChrisW> but i would strongly object to starting new work

<sandro> PROPOSED: Create a new document, something like "Using RIF with XML", addressing ISSUE-37 and ISSUE-38, in the space of Gary and Christian's proposals, for RIF rules to use XML data wth and without a schema. What it specifies should work with Core, BLD, and PRD, and is important to the success of RIF. This technology is not just for use of XML data, but for using XML Schemas to communicate data models.

<sandro> ChrisW, Gary, Paul- and the ILOG (and IBM company) folks say they have to have this for PRD to be useful.

<ChrisW> I've heard the same argument for a lot of things in RIF

<csma> The alternative to starting a new doc is including it in PRD.

<csma> since this is useful to other dialects as well, better put it in a separate doc instead of a PRD section

<ChrisW> finish the work on PRD first, then consider this for a note. But only when the existing drafts are at LC

<ChrisW> no new work

<ChrisW> i repeat, no new work

<sandro> sandro: I think the risk of new-work is somewhat reduced buy having it be an independent document.

<Harold> Also look into related work such as Schema-Aware Queries and Stylesheets (http://www.stylusstudio.com/schema_aware.html) and Schema-aware processing with XSLT (http://www.ibm.com/developerworks/xml/library/x-schemaxslt.html).

<ChrisW> this has too many other implications

<ChrisW> i will object

<sandro> sandro: We could publish a VERY DRAFT WD on this, which is just the cut and paste of Gary's and CSMA's proposals, to [as csma says] let people know this kind of work is doable, so they know PRD might be useful.

<sandro> gary: In our product, we tried an xpath thing, but ended up putting the whole document in, because it worked better for what customers wanted.

<sandro> csma: I want to borrow XPath.

<sandro> gary: RIF CL is already a query language, so it's kind of painful to combine it with another, like XPath.

<sandro> csma: true.

<sandro> BREAK until 17:00

<sandro> scribenick: Michael_Kifer

<sandro> restarting

CSMA: issue: forall is different in BLD and PRD

<sandro> csma: Forall means something different in PRD from Core. It means "for each value that you can bind" ... which has the same effect. But PRD also needs the real forall...?

<sandro> sandro: (listening to Changhai's example) You want an aggregate. if forall x...

<sandro> sandro: so this, in practice, needs closed world assumption,

<sandro> jos: or negation

<sandro> gary: we have this now in PRD via "not exists".

the issue seems to be "forall" outside of the rule vs. "forall" in the rule body

<sandro> paul: "if at least 3..."

<sandro> csma: So the forall inside the rule and outside the rule are really the same?

<sandro> Michael_Kifer: Yes

<sandro> Jos: Yes

decided that this is a non-issue

<Harold> BLD's Forall can work over infinite sets such as {0, s(0), s(s(0)), . . .}:

<Harold> Forall ?N ( nat(s(?N)) :- nat(?N) )

<josb> Next topic, please!

<sandro> csma: on board:

<sandro> forall ?x ( ?x # Car)

<sandro> if forall ?y ( ?y # Door )

<sandro> ?x[door->?y] and ?y[color->red]

<sandro> then Paint It Blue

<sandro> (all agree, the two forall as "the same", and can use the same syntax.)

<sandro> (if the language were to support forall inside a condition.)

Next: issue 39, RIF should support import or inclusion of rulesets

<josb> http://www.w3.org/2005/rules/wg/track/issues/39

import is in core already. CSMA: might cause conflicts in conflict resolution strategies

<sandro> agreed: if PRD imports with a different Res.Strat. it should ... say what happens. (one rules, or error, or something.)

proposed: close issue 39

<sandro> PROPOSED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time.

because core already has import

<josb> +1

<Harold> +1

<sandro> Michael_Kifer: i'd like includes would be including rules, not whole documents....

<sandro> PROPOSED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time (in part because we don't know what it might mean).

<sandro> +1

<josb> ++1

+1

<josb> +++1

<sandro> Sandro: it sounds like Core:imports wont be a pain to implement in PRD, even though it doesn't do all the fance stuff some PRD engines really want in imports.

<sandro> csma: Import is specified in the dumb way -- without juggling priorities -- so it's not very useful in PRD.

<sandro> gary: Yeah, someday we'll need to specify complex ways to do import in PRD.

current import mechanism is too primitive for PRD. Need to expand it in the future for PRD

<sandro> PROPOSED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time (in part because we don't know what it might mean). It ends up in PRD, where it's not ideal, but not really harmful. Some PRD may do a more sophisticated import at some point.

csma: the current import mechanism in core is acceptable, but it is not very interesting for prd.

<sandro> PROPOSED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time (in part because we don't know what it might mean). 'Imports' ends up in PRD, where it's not ideal, but not really harmful. Some version of PRD may do a more sophisticated import at some point.

<sandro> +1

<sandro> Harold: when you find the better imports, propose it to the rest of RIF!

<Harold> +1

<josb> +1

+1

<AdrianP> +1

<GaryHallmark> +1

<PaulVincent> +1

<sandro> RESOLVED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time (in part because we don't know what it might mean). 'Imports' ends up in PRD, where it's not ideal, but not really harmful. Some version of PRD may do a more sophisticated import at some point.

<sandro> Sandro: let's put "filters" ("such that" expressions) as syntactic sugar into Core.

<sandro> MK: bounded quantifies.

<cke> good idea

<josb> Let's not. The syntax is already complicated enough

<sandro> Sandro: So, if we have to do a LC2 -- then we can talk about this.

<sandro> ISSUE: Should we put bounded quantifiers into Core? (forall x such than x # C ...) (esp if we need an LC2 for BLD anyway)

<trackbot> Created ISSUE-91 - Should we put bounded quantifiers into Core? (forall x such than x # C ...) (esp if we need an LC2 for BLD anyway) ; please complete additional details at http://www.w3.org/2005/rules/wg/track/issues/91/edit .

<sandro> MK: bounded quants are not very useful in BLD, and the re-writing is a little tricky.

<sandro> csma: Many rules are written with BQs, and people don't want to discard that optimization. Also, you need BQs for any else-clause.

Forall ?X in C (h :- body) is Forall ?X (h :- body and C).

<sandro> ADJOURN - 1 minute late

<josb> http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=higgins+portland&sll=37.0625,-95.677068&sspn=34.945679,58.886719&ie=UTF8&ll=45.51541,-122.680957&spn=0.001887,0.003594&z=18&iwloc=A

<josb> http://maps.google.com/maps?f=d&source=s_d&saddr=SW+5th+Ave&daddr=1239+SW+Broadway,+Portland,+OR+97205+(Higgins+Restaurant)&hl=en&geocode=FYaBtgId7w6w-A%3B&mra=cc&dirflg=w&sll=45.515407,-122.680786&sspn=0.001887,0.003594&ie=UTF8&z=18

<josb> coffee: http://maps.google.com/maps?f=d&source=s_d&saddr=45.515221,-122.679648&daddr=128+SW+3rd+Ave,+Portland,+OR+97204+(Stumptown+Coffee+Roasters)&hl=en&geocode=&mra=mi&mrsp=0&sz=15&dirflg=w&sll=45.518045,-122.676859&sspn=0.015095,0.028753&ie=UTF8&z=15

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/,/-/
Succeeded: s/RESOLVED/PROPOSED/
Found ScribeNick: Michael_Kifer
Inferring Scribes: Michael_Kifer

WARNING: No "Topic:" lines found.

Default Present: Mike_Dean, Hassan_Ait-Kaci, Christian, Gary, Harold, Adrian, Jos, Paul, Micheal_Kifer, Changhai, Sandro, Stella, +44.145.441.aaaa, DaveReynolds, +1.212.781.aabb, LeoraMorgenstern, StellaMitchell, ChrisW, Stella_Mitchell
Present: Mike_Dean Hassan_Ait-Kaci Christian Gary Harold Adrian Jos Paul Micheal_Kifer Changhai Sandro Stella +44.145.441.aaaa DaveReynolds +1.212.781.aabb LeoraMorgenstern StellaMitchell ChrisW Stella_Mitchell

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: 15 Jan 2009
Guessing minutes URL: http://www.w3.org/2009/01/15-rif-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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