See also: IRC log
<ChrisW> Scribe: LeoraMorgenstern
<csma> list agenda
<csma> list agendum
<csma> drop agendum 6
Chris: I am removing F2F11 from the agenda, since there are some things that need to be figured out further.
PROPOSED: Accept minutes of 20 May 2008
RESOLUTION: Accept minutes of 20 May 2008 as published on mailing list
PROPOSED: Accept minutes of 6 May 2008
RESOLUTION: Accept minutes of 6 May 2008
Chris: agenda amendment: In place of discussing F2F11, we'll discuss some public comments.
Liaison: Nothing new
csma: we passed quite a number of resolutions... on BLD and other docs ... We resolved to publish BLD and SWC as last call working drafts, ... UCR as 3rd call working draft, FLD as second public working draft, DTB and PRD as first public working drafts> ... all of this subject to some editorial changes ... labelled a number of features in BLD as being at risk, such as equality being in the head (of rules) ... resolved to ask for 1-year extension. ... along with a work plan describing objectives.
csma:plan is to bring BLD, SWC, FLD, DTB, to recommendation status
sandro: We need to get people to work on PRD. Not clear we have the staffing for this.
csma: Hopefully first published working draft on PRD will get people working on this.
<Harold> Both Gary and AdrianP are interested to co-edit PRD.
<PaulVincent> +1 yes I should get involved in PRD...
ACTION 517 on Jos to review FLD --- FLD not out yet
Action 515 moved pending review
csma: question on Gary's action for 514
Action 515 completed pending review
action 513 completed
action 512 to review Axel's change to DTB is continued
action 510, 511 on csma are continued. (One is done but must be redone.)
action 509 on Adrian and Gary: continued (version to be reviewed not out yet.)
action 507 on csma to align syntax table between PRD and BLD awaiting freezing of BLD syntax by Harold.
action 506 on Michael to make editorial changes to dtb with links to BLD ... not due for tomorrow.
All Michael's actions due in 2-3 weeks.
Action 505 on Sandro continued.
<Harold> June 15
<Harold> June 16
Action 504 on Harold continued.
all actions on Harold are continued
action 495 on Adrian is continued
action 492 on csma to review changes to SWC continued
action 491 on Jos completed.
<ChrisW> ACTION: sandro to review explanatory text in section 2 SWC [recorded in http://www.w3.org/2008/06/03-rif-minutes.html#action01]
<trackbot-ng> Created ACTION-518 - Review explanatory text in section 2 SWC [on Sandro Hawke - due 2008-06-10].
action 480 on Jos to add explanatory text to swc and reply to Dan's comment : completed and pending review.
csma: Jos, did you get an answer from Dan?
<josb> I did not get an answer yet
action 475 to look into mime registration on sandro: continued
action 454 on Chris: continued
action 152 continued
chris: Publication plan is on the main page
csma: what are new deadlines for
all the documents?
... is SWC available now for review?
... available for review with exception of proofs in the appendix.
... should be done in by the end of the week
... can only be frozen after BLD and DTB are finalized, because there are dependencies.
... but reviews can be done before then, subject to the constraints of the dependencies (marked in editor's notes)
... I am trying to get Axel to review the proofs.
sandro: not problem with Adrian's
reorganization of text
... but there are some use cases that I just don't like.
... some have broken links, some have other problems.
... in some cases, I have suggested (in an email) alternate wording
<sandro> I think we're meeting this.
<sandro> BLD passes.
<sandro> rif-core part unknown.
csma: no problem with this, either, except for the fact that there's no real Core --- there's BLD now.
sandro: will there be text saying
how we're doing on these requirements?
... (agreeing with csma) may be expected, but we don't have to do them.
csma: but we must have something to say in case someone asks.
sandro: where there's something to be said, it would be nice to make a comment. Must discuss with Adrian.
<sandro> sandro: let's annotate the requirements with respect to where we are right now, maybe?
chris: I disagree. Not a good idea at all.
<sandro> csma: yeah, maybe
chris: should make the doc crisper and shorter. To discuss in this doc how BLD meets the requirements puts too much focus on BLD. But to put it into the BLD doc would make that unnecessarily long.
<sandro> It must be possible to create new RIF dialects which extend existing
<sandro> dialects (providing backward compatibility) and are handled
<sandro> gracefully by systems which support existing dialects (providing
<sandro> forward compatibility).
<sandro> change to: (thus providing ...)
sandro: I think my suggested change to the text of this requirement, pasted above, is clearer.
<PaulVincent> Surely "fwd compatibility" is a requirement on the translator, not on RIF itself?
csma: will propose resolution next week to change text as suggested.
sandro: (answering Paul) No, this is a requirement on RIF to say what RIF processing software does.
<Harold> Re 5.1.3: In some sense, we now often specialize (FLD/FOL+ -> BLD -> Core) rather than extend (Core -> BLD -> FOL).
Paul: sounds like a
recommendation, not an enforceable requirement.
... really just a practicality issue, not a fundamental disagreement of the desirability of this requirement.
<PaulVincent> -1 - vote now
sandro: let's just vote on this now, unless anyone wants more time.
<sandro> PROPOSED: change text of 5.1.3 to: It must be possible to create new RIF dialects which extend existing dialects (thus providing backward compatibility) and are handled gracefully by systems which support existing dialects (thus providing forward compatibility).
csma: no one seems to want more time.
<sandro> RESOLVED: change text of 5.1.3 to: It must be possible to create new RIF dialects which extend existing dialects (thus providing backward compatibility) and are handled gracefully by systems which support existing dialects (thus providing forward compatibility).
<sandro> seems fine
<sandro> doing fine
csma: we're doing fine with this.
<sandro> doing okay, I think
csma: no problem, except for the fact that we don't have such an experience wiht implementation
harold: We are having this experience with W3C's existing XSV validator and doing fine.
csma: this requirement is problematic. We don't have this completed.
sandro: my thought on what this means is that RIF plus extensions must cover all widely deployed rules languages.
<Harold> Re 5.1.5: We successfully use W3C's existing XSV validator for BLD's XML schema.
<josb> and RDF/OWL extensions
<sandro> Drop 5.1.6? Or mark it as unattainable?
Gary: need to weaken the text of
... but certainly 5.1.4 and 5.1.6 overlap
<sandro> PROPOSED: drop coverage requirement 5.1.6, since we don't have RIFRAF.
sandro: the point of 5.1.6 is
that we wanted to enumerate what we wanted to cover.
... but we're not doing that. We don't have RIFRAF.
<sandro> PROPOSED: drop coverage requirement 5.1.6, since we are not doing RIFRAF.
<LeoraMorgenstern> That is, I think it's hard to attain, but I don't like the idea of dropping it entirely.
<mdean> + .5
<LeoraMorgenstern> If we did have RIFRAF, we'd be forced to test the existing RIF on selected languages.
<Harold> Gary, function symbols nested to any fixed depth only (hence, no recursion into these nestings) can theoretically be 'flattened'.
<LeoraMorgenstern> And very likely, gaps in RIF would show up.
<sandro> PROPOSED: Change text of 5.1.6 to: RIF standard dialects must cover the major shared features of all widely-deployed rule languages.
<LeoraMorgenstern> Sandro, will there be an enumeration of "all widely-deployed rule languages"?
<sandro> no, LeoraMorgenstern
<LeoraMorgenstern> So, how meaningful is this requirement?
<LeoraMorgenstern> Will there be an enumeration of "major shared features"?
<sandro> Jess and Prolog
<sandro> Jess and Prolog and FOL.
<GaryHallmark> Harold, yes, and Skolem functions, too. But lists won't work...
<PaulVincent> Suggestion: RIF standard dialects must not exclude any rule language feature in any extensively deployed rule language ...
<Harold> Jess and Prolog and F-logic :-)
sandro: should be : if there's a
feature in at least two widely deployed rules languages, we
should cover it.
... but if it's only in one such language, maybe we don't need to cover it.
<sandro> PROPOSED: For this next draft of UCR, change 5.1.6 to note that we're still working on this.
csma: perhaps we should work on the text of this resolution for next week. (Comment made before Sandro's proposal above.)
<PaulVincent> +1 and I can take an action to attempt suitable wording...
<ChrisWelty> how about something like: To achieve widespread adoption, RIF dialects should cover shared features from many well-known rule languages
csma: we don't want to refer to RIFRAF anymore
<ChrisWelty> +1 drop reference to RIFRAF
csma: any objection to dropping any reference to RIFRAF?
<IgorMozetic> +1 to drop RIFRAF
csma: no objections, so that's what we'll do.
<sandro> PROPOSED: For this next draft of UCR, add an editor's note to 5.1.6 to note that we're still working on how to define a coverage requirement. (unless we come up with some consensus text before publication)
<sandro> RESOLVED: For this next draft of UCR, add an editor's note to 5.1.6 to note that we're still working on how to define a coverage requirement. (unless we come up with some consensus text before publication)
<sandro> The RIF specifications must provide clear conformance criteria,
<sandro> defining what is or is not a conformant RIF implementation.
<ChrisWelty> its not a rephrasing, but it is more accurate for what we have
<sandro> PROPOSED: rephrase 5.2.1 to: The RIF specifications must provide clear conformance criteria, defining what is or is not a conformant RIF implementation.
chris: it's not a rephrasing. It's a different requirement.
<sandro> (shrug about "rephrasing". re-articulate? :-)
<sandro> RESOLVED: rephrase 5.2.1 to: The RIF specifications must provide clear conformance criteria, defining what is or is not a conformant RIF implementation.
csma: passed by lack of objection
<sandro> as well as I understand this, it's part of fallbacks / forward compatibilty.
<sandro> sandro: ah -- I see what this would be useful
<sandro> all good
<sandro> all good :-)
<sandro> all good :-)
<sandro> prefer "small" number
<sandro> PROPOSED: in 5.2.6 change "limited" to "small"
csma: objection to "limited" --> "small" ?
chris: I don't see much of a difference
sandro: take out reference to phase 1 semantics
chris: phase 1 is defined in the charter
sandro: we've abandoned that
<GaryHallmark> suggest changing Phase 1 to RIF
chris: in fact, we haven't.
chris: Actually, this should be the public comments discussion.
chris: when we responded to Peter's comments from last year, he responded to our response, and we never responded to that response.
<sandro> Looking at http://www.w3.org/2005/rules/wiki/RIF_Working_Group
Action on Jos to respond to Peter.
<sandro> ACTION: jos to start work on response to http://www.w3.org/2005/rules/wiki/Response_to_PPS3 [recorded in http://www.w3.org/2008/06/03-rif-minutes.html#action02]
<trackbot-ng> Sorry, amibiguous username (more than one match) - jos
<trackbot-ng> Try using a different identifier, such as family name or username (eg. jdebruij2, jderoo)
Jos: can look at it by next week, but not necessarily to respond .
<sandro> ACTION: jdebruiij2 to start work on response to http://www.w3.org/2005/rules/wiki/Response_to_PPS3 [recorded in http://www.w3.org/2008/06/03-rif-minutes.html#action03]
<trackbot-ng> Sorry, couldn't find user - jdebruiij2
<sandro> ACTION: jdebruij2 to start work on response to http://www.w3.org/2005/rules/wiki/Response_to_PPS3 [recorded in http://www.w3.org/2008/06/03-rif-minutes.html#action04]
<trackbot-ng> Created ACTION-519 - Start work on response to http://www.w3.org/2005/rules/wiki/Response_to_PPS3 [on Jos de Bruijn - due 2008-06-10].
<ChrisWelty> ONE EYEBack to UCR Requirements Discussions
<Harold> Gary, finitely nested lists could also be flattened, somehow like this: p(a,[1,,3],c) => p(a,%L1,1,%L2,%L1,2,%L3,3,c), where %Li 'indexes' list elements.
sandro: would like to drop this, since it's confusing.
chris: I know what we meant by it. We don't want to run into what we ran into with OWL.
<josb> then, it is in both dialects
chris: regarding integration with RDF.
<sandro> sandro: if an implementation is labeled, and the label is used in deciding whether to process, then documents in the intersection are rejected when they should not be.
<sandro> PROPOSED: extend meeting by 10 minutes
<LeoraMorgenstern> let's continue next week:
<ChrisWelty> +1 adjourn
<sandro> csma: restart at 5.2.9 Dialect Identification next week.