See also: IRC log
Next meeting will be next week, July 24th.
Action 327 on csma to put datasets on agenda for meeting DONE
Action 325 on csm to publish minutes of F2F6 DONE
Action 324 on Chris to ask Deborah Nichols about minutes of 6-26 is still open
Unclear if that was done or not.
PROPOSED: accept meetings of July 10 minutes telecon.
RESOLUTION: accept meetings of July 10 minutes telecon
Action 324 CONTINUED since Chris is not here.
PROPOSED: accept minutes of meetings of F2F6 in Innsbruck
That will be kept open until next week since Harold and possibly others didn't have a chance to go through them.
No amendments to agenda.
<johnhall> SBVR - nothing to report
No actions for this item.
No news about liaison.
There are 3 proposals for F2F. One is Harold's, in New Brunswick.
Another is ChrisW's in New York.
There's also a possibility to collocate with OMG meeting in Jacksonville the week of September 26th.
<csma> http://www.w3.org/2005/rules/wg/wiki/F2F7
John Hall is looking into the possibility of collocating with OMG.
No information yet on costs per person from wiki
csma: if we make the decision next week, earliest for f2f is Sept. 18 [due to mandatory 8-week period between time of decision and f2f].
csma: If we make decision next week, earliest for f2f is Sept. 25.
Chris: We can have f2f In Hawthorne, NY on Sept 27-28
or Oct. 3-4 (W, Th)
... there would be no costs other than transportation
Johnhall: costs [for Jacksonville, FL] would be approx. $120 per head per day
Discussion on dates for possibilities for f2f7 at IBM
ACTION on Leora to find out what dates are available besides the dates that Chris has reserved.
sandro: we should close poll by July 23 and make decision by July 24.
csma: one week for decision, especially in vacation time, is too short.
<PaulaP> no objection
sandro: we've been discussing this for months
chris: agrees with sandro
csma: any objection to closing
poll on July 23?
... hearing no objection, we'll close poll on July 23.
Action 323 (make a pass at updating the extensibility page based on the discussions and strawmen) on Sandro is due next week
Sandro: would like to put that off for one more week
Action 309-311 (unified strawman proposal for asn --> xml system) are completed; will be discussed today
Action 303, 301 on Jos and Harold, and one on Michael to remove overlapping sorts
Harold: done
Michael: done
csma: any objection to keeping it open until we discuss it?
action 298 on Gary to show how to use xml schema for app data model: completed and closed
Action 260 to put short entry on data sets, outlining the issues on Dave: done
There are a number of actions open in Architecture ( http://www.w3.org/2005/rules/wg/track/products/11 ); these are open until August
<Harold> Modularization: http://www.w3.org/2005/rules/wg/wiki/Arch/RIF_Components/RIF_Dialect_Structure
3 resolutions:
to better understand RIF Core, create 2 task forces,
one focusing on Horn, one focusing on production rules
<csma> PROPOSED: To better understand what RIF Core could be, create two
<csma> task forces in RIF, one focusing on Horn and one focusing on production
<csma> rules.
<csma> PROPOSED: Rename the current "RIF Core" draft: "RIF Horn dialect".
<csma> PROPOSED: Create a "RIF PR dialect".
csma: idea is not to have
divergent dialects
... idea is to have a better idea of what a PR dialect would
be, what kind of extensions we'd need
... it seems clear that PR dialect couldn't be an extension of
current RIF Core
<sandro> Harold, you're just saying you think the current Core should be *named* something other than "RIF Horn Dialect"? Or you want it to BE something different?
csma: have to go down to find common core, from which both HR dialect and PR dialect come
Harold: anyway, we have gone beyond Horn, with equality, etc.
<IgorMozetic> what about: RIF LP dialect ?
<sandro> Harold: "RIF Logic Dialect"
chris: Harold isn't saying to
extend the core, merely to change the name
... since anyway, what's in core now is beyond Horn
<sandro> Michael: "RIF Logical Core Dialect"
michael: that's why it makes sense to call it logic
csma: we don't want to forego idea of having one common core
Michael: makes sense to develop a core for logic dialects, and a core for production rule dialects, both of which come from a simpler common core
<DaveReynolds> Perhaps use "base" - "PR Base" and "LP Base"
csma: we don't want the term core except for in the one core from which all PR and HR dialects spring forth.
<ChrisW> too close to "data base"
<sandro> you beat me, Dave, I was just going to suggest "base" :-)
+1 Dave
<sandro> "RIF Logic Base Dialect"
csma: base too close to database
<sandro> "RIF Logic Basis"
<sandro> "RIF Basic Logic Dialect"
<Harold> PROPOSED: To better understand what RIF Core could be, create two task forces in RIF, one focusing on a Logic Basis and one focusing on a PR Basis.
<ChrisW> "RIF Basic Logic Dialect"
<ChrisW> "RIF Basic PR Dialect"
<ChrisW> ?
csma: to Michael --- you're not proposing to extend the basis logic dialect? PR will almost certainly have notion of negation.
<DaveReynolds> ChrisW: +1 (though if we only worry about the names we are home and dry :-))
Michael: No
csma: except for name, any
objection to creating these 2 task forces?
... i.e., any objection to these 3 resolutions?
... okay, hearing no objection, we'll pass the resolutions once
we decide on the names.
<AllenGinsberg> 0) RIF COMMON CORE 1) RIF LOGICAL DIALECTS CORE 2) RIF PR DIALECTS CORE
csma: we'll probably just use the names basic logic and basic pr in conversation.
csma: (to allen:) basic or basis better than term "core"
<ChrisW> DaveR: naming discussions are usually longer than technical ones
<ChrisW> ...because everyone understands the discussion
<DaveReynolds> ChrisW: agreed :-)
Allen: we should have a task force for the common core, at the same time as the other two task forces, otherwise it might seem as if we're abandoning idea of common core.
<sandro> (I like Allen's suggestions, too.)
csma: we'd keep the plenary telecon
<Harold> Allen, Yes, we can have a 'twin core', and later (re)discover the 'common nucleus' underneath.
csma: but some telecons would be
more relevant to logic task force; some more relevant to production rules
task force.
... idea is not for two task forces to separate.
... therefore, we don't want to have a core task force: that is
the working group itself.
The proposed resolutions now become:
<sandro> csma: RIF Basic Logic Dialect, RIF Basic PR Dialect
<csma> PROPOSED: To better understand what RIF Core could be, create two
<csma> task forces in RIF, one focusing on Horn and one focusing on production
<csma> rules
<csma> PROPOSED: To better understand what RIF Core could be, create two
<csma> task forces in RIF, one focusing on Horn and one focusing on production
<csma> rules
<csma> PROPOSED: To better understand what RIF Core could be, create two
<csma> task forces in RIF, one focusing on
<csma> a logical dialect and the other one focusing on production rules
<csma> dialect
<sandro> PROPOSED: To better understand what RIF Core could be, create two task forces in RIF, one focusing on a logical dialect and the other one focusing on a production rules dialect
no objection so
<sandro> RESOLVED: To better understand what RIF Core could be, create two task forces in RIF, one focusing on a logical dialect and the other one focusing on a production rules dialect
Onto second resolution
<csma> PROPOSED: Rename the current "RIF Core" draft: "RIF basic logic dialect"
RESOLUTION: Rename the current "RIF Core" draft: "RIF basic logic dialect"
Onto third resolution
<csma> PROPOSED: Create a "RIF basic PR dialect"
RESOLUTION: Create a "RIF basic PR dialect"
csma: Regarding organization of
these task forces, we'll continue as we have, but will have new
email topics, and new sets of actions, so we can focus
discussion on one or the other.
... no need to go further, no need for formal
organization
... I've been working on strawman for basic PR dialect; hope to
publish it before the end of the week, to start off the
discussion.
... sandro put out a strawman for this in email
sandro: In Innsbruck, we talked
about requirements for RIF XML serialization. Not many
requirements.
... One firm requirement: (Leora to Sandro: Missed it --- what was this requirement?)
... could pick a language that was a subset of rdf/xml,.
allowing use of rdf tools.
... Harold pointed out one flaw in the way rdf does data types
... good to aim for both communities
csma: didn't see relationship between xml syntax strawman and rif serizalization strawman sent out yesterday
sandro: mapping from asn to xml
schema
... and mapping from the instance level
... those 2 mappings are strongly connected, inform each
other,
... but don't subsume one another
csma: in object-oriented language like ilog,
and many java pr engine, we would have a rif object model
conforming with asn syntax, systematically derived from xml
syntax. The mapping would not go from internal model for rules in
engine to xml, but from internal representation in engine to
abstract asn representation to xml document.
... in that view, I don't think we need rif syntax data structure
that Sandro proposed
... I would expect that: xml syntax for rif dialect is concrete
syntax for that rif dialect.
... asn is abstract syntax for that same dialect.
... so I understand the first xml syntax strawman because I
understand how to derive xml syntax from asn abstract
syntax
... where asn syntax has classes like rules, if-then statements,
conditions,
... but now, in the serizalization strawman, I see yet another
syntax for rif, with none of these abstract concepts.
sandro: let's forget about the
serialization strawman for now, then.
... I can go back to the way I was talking to it before.
michael: similar question to
csma's
... what' s the advantage of using the rdf syntax? Just that
you can use rdf tools?
... that's kind of vague ... what problem are we trying to
solve?
... and what are the advantage of your solution?
... I'm having difficulty understanding what it's all
about?
csma: doesn't undersatnd michael's question
sandro: Michael thinks that in the core doc, there's already a start at xml syntax
sandro: there isn't an existing syntax
michael: yes, there's something
sandro: but it doesn't give
datatypes
... not in the examples
michael: so, yes, we should do it better
sandro: so that's what I'm trying to do, to nail all that stuff down, and use what another working group has spent years working on.
<sandro> stuff like "$49" and "LeRif"
csma: in the working draft, there are
proposals for xml syntax, but they haven't been
furthered.
... question is not just: what is xml syntax for the current
draft, but how do we derive the xml syntax.
<GaryHallmark> the problem is we need some simple rules to transform a syntax in asn to a syntax in xml schema
<Harold> We already had discussed solutions for "$49" and "LeRif" here: http://www.w3.org/2005/rules/wg/wiki/A.1.1_Basis%3A_Positive_Conditions_over_Bipartitioned_Constants
csma: regarding why xml/rdf rather than not-rdf xml: if it gives us the possibility to use both kinds of tools, so that both rdf people and xml people can stay in their worlds, what's the drawback?
<GaryHallmark> the question is whether rdf/xml helps or hinders the solution to the problem
sandro: up to members of the working group to advocate for the tools they want to use.
<GaryHallmark> JAXB
< GaryHallmark> acronym for Java API for Xml Binding
sandro: for example, Gary has advocated for JAXB.
<GaryHallmark> pretty much any legal xml schema will "work" for jaxb, but it could yield a very cumbersome api
<csma> http://lists.w3.org/Archives/Public/public-rif-wg/2007Jul/0058.html
Action on Gary to check whether there would be problems with JAXB if the xml syntax would be derived from the asn in the email posted above.
csma: Gary, problem hidden in the translator?
<Harold> The translator would also need to be maintained, as we develop RIF through its lifecyle.
Gary: some confusion about how the translation would work .. .. don't know enough now to produce the translation ...
csma: Sandro, can you clarify this for Gary?
<sandro> ACTION: Sandro to produce XML Schema following his Serialization Strawman proposal -- due Julu 27 [recorded in http://www.w3.org/2007/07/17-rif-minutes.html#action01]
<rifbot> Created ACTION-328 - Produce XML Schema following his Serialization Strawman proposal -- due Julu 27 [on Sandro Hawke - due 2007-07-24].
<ChrisW> I have to leave the call.
<Harold> I noticed asn07 now being often mentioned in the discussion instead of asn06, although at F2F6 I heard asn07 was still purely experimental.
csma: there were a number of side
discussions ...
... (you (Sandro?)) proposed that the root of the document
should be one thing, Harold, that it should be another
Sandro: still useful to try to have this in RDF, but I know Harold doesn't agree.
<sandro> rdf:RDF to rif:RIF
Harold: it should be mappable to RDF
csma: we need to find a use case where the fact that it is rdf xml and not pure xml is a problem.
Dave: for the issue of how to
extend on top of RDF: in the OWL world, the issue is not one of
syntax, it's that OWL was trying to be a semantic extension
of RDF --- doing that sort of extension of RDF
caused semantic problems.
... But the proposal of RIF is not to do that. It's not that RIf doc
would be in RDF; it's simply to use RDF to encode things ..
therefore the semantic issues that the OWL community faced
would not arise.
<sandro> Dave: We'd need to be very careful in getting advice from OWL community here, since they have semantic issues (with being an RDF extension) which don't seem to apply to us.
csma: (responding to Harold): if we use rdf/xml only as syntax, as a carrier, what's the benefit to the rdf people?
<Harold> RDF syntax would allow that a rule has 'extra parts', which are just not mentioned here.
dave: as sandro said, we have a
well-defined self-describing syntax we can just get off the
shelf.
... second, we can use various tools.
... third, it's important that metadata be interpretable as rdf
and if you already have your syntactic encoding in rdf, you
have that.
<Harold> ... but RIF syntax should comply to a 'closed-property assumption'.
<DaveReynolds> Harold: sure, if you take a RIF document and add additional RDF assertions then it would either be no longer a legal RIF document or the additions would be treated as metadata
csma: to harold and/or sandro:in proposed serialization, for the examples in current draft, would serizalization give different result from proposed syntax in draft?
sandro: yes, for some of the leaves, like $49. ... for information already there, it shouldn't be significantly different.
sandro: we can show examples, so people can see this better.
Harold: DaveR, re: metadata, you had shown in your 'Worked example' how to embed a pure XML syntax into RDF.
Dave Reynolds:> Harold: yes, my original proposal was to avoid the RDF/XML discussion for the bulk of the condition language but retain it at the top level to permit metadata
DaveReynolds:> Leora - sorry I was trying to respond to Harold's IRC discussion .. I can see the abmiguity!
AOB: None
next agendum.
<JeffP> +1
<sandro> +1 adjourn