See also: IRC log
<sandro> ScribeNick: LeoraMorgenstern
<csma> agendum+ Admin
<csma> agendum+ Liaisons
<csma> agendum+ Public comments
<csma> agendum+ Actions review
<csma> agendum+ F2F12 debrief
<csma> agendum+ F2F13
<csma> agendum+ AOB (scribing)
<ChrisW> Scribe: LeoraMorgenstern
PROPOSED: Accept minutes of January 6, 2009 telecon
<csma> PROPOSED: approve the minutes of January 6
<csma> http://lists.w3.org/Archives/Public/public-rif-wg/2009Jan/att-0007/06-rif-minutes.html
RESOLUTION: approve the minutes of January 6
csma: any amendments to the agenda?
(None)
<csma> next item
csma: Any news from our liaisons?
... We might have news from our OWL liaison soon.. There is an action to get them to change their data types.
Sandro: We haven't had any communication with them, and it's rather urgent, because deadline for last call comments are Jan. 23.
... so we should register an objection immediately.
<sandro> from minutes:
<sandro> from minutes: RESOLVED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core. In RIF, the xsd numeric types will have disjoint value spaces (as in XSD1.1, unlike current OWL 2 drafts)-- we'll push for OWL to change and assume they will. [The owl:* types will be decided separately. Value spaces of Binaries will be decided separately. When those are decided, it will close ISSUE-81] ←
<sandro> http://www.w3.org/2005/rules/wg/meeting/2009-01-15#resolution_10
Chris: Since this is not just a discussion between Jos and Boris, but represents the decision of the RIF group (that the data types need to be changed), chairs should send a sensitive (politically correct) email.
Sandro: original idea was to have an informal discussion (thus the action on Jos), but since time is running out, a formal objection/email is necessary.
csma: I don't think Jos has done anything yet about it.
Chris: I will send a message to Ian and Alan letting them know.
... How did the actual discussion go?
... Are we leaning toward accepting other OWL data types and just rejecting non-disjointness?
Sandro: Yes
... Yes, non-disjointness is a real problem for built-ins. See Dave Reynold's example.
Chris: Now, OWL doesn't care about built-ins. So our objection is not specific to OWL, it's directed toward the interoperability of RIF and OWL.
... That is, this isn't a complaint about OWL itself. The message to them should stress this point.
... Our message should say that we believe OWL and RIF should be interoperable, and the non-disjointness would break that.
... I'm trying to put a positive spin on this: We want to be compatible and interoperable with OWL, and the non-disjointness would break that.
<ChrisW> ACTION: Chris to draft formal response to the OWL WG regarding datatype disjointness [recorded in http://www.w3.org/2009/01/20-rif-minutes.html#action01]
<trackbot> Created ACTION-698 - Draft formal response to the OWL WG regarding datatype disjointness [on Christopher Welty - due 2009-01-27].
Sandro: Perhaps there's a way of having two different perspectives on this. So that OWL could see types as non-disjoint, but RIF would see them as disjoint.
... Email should be sent by Friday, but better to do it by tomorrow before OWL telecon.
<csma> next item
csma: I saw no new public comments. We are done with responding to all previous public comments.
<csma> next item
Action-696 is done.
Action-695 continued?
<trackbot> Sorry, couldn't find user - 695
<sandro> action-696 clodes
<sandro> action-696 closed
<trackbot> ACTION-696 Start survey, including question about objecting to having it in north america again. closed
<Gary> my actions are continued
Action-693, Action-694, Action-691 continued
Action-690 continued,
All actions on Jos (from 682 and on ) are continued
<AdrianP> shall we close Action-693 since we just decided that Chris will send an email to the OWL WG?
Action-678 closed
<trackbot> ACTION-678 Send response to TK2 closed
Action-633 continued
Action-5092 continued
Action-592 continued
Action-579 continued
Action-588 continued
Hassan's action continued
Action-439 continued
Action-653 continued
Reviewing Pending actions now:
Action-591 is closed (discussed at F2F)
<sandro> action-591 closed
<trackbot> ACTION-591 Draft a straw proposal addressing part of ISSUE-37, in the area of navigating the schema/data. closed
Action-614 closed
<trackbot> ACTION-614 Start discussion on what test cases we need closed
<csma> next item
Action-631 still left open
<csma> next item
<apaschke> wrt test cases: we had a discussion document where I listed several test case types
<apaschke> http://www.w3.org/2005/rules/wiki/TCS
<apaschke> http://www.w3.org/2005/rules/wiki/TCS#Categories_of_RIF_Dialect_test_cases
Sandro: The minutes are in the wiki, but need to be cleaned up.
<sandro> http://www.w3.org/2005/rules/wg/meeting/2009-01-14
Sandro: There's a link on the minutes to the editable wiki version; you can edit that; and then preview nicely formatted version; then click on save button if you like what you see.
csma: We followed the agenda quite closely.
... We started by reviewing test cases, focusing on OWL and RDF.
... checked not just for BLD, but for core, so they could be approved for BLD and PRD.
... We approved 5 test cases (RDF_Combination_Blank_Node for BLD, Core, PRD, and Safe-Core; RDF_Combination_Constant_Equivalence_2 (all dialects);
RDF_Combination_Constant_Equivalence_3 (all dialects); RDF_Combination_Constant_Equivalence_Graph_Entailment_2; RDF_Combination_Member_1 (all dialects).
csma: we rejected one test case.
... Next, we discussed problems PRD with object representations --- whether objects could be properly represented using frames.
... Discussion focused on multi-valued attributes for frames vs. the fact that normally this can't be done for objects.
... Discussed extending syntax for frames to express cardinality of max 1.
... Focus was on syntax.
... Michael wasn't very happy; would have to rewrite chunk of specification.
<sandro> csma: Basic solution (from Gary) seems to be: leave multi/single difference to be implicit in whether the action used is ASSERT or MODIFY.
csma: should be able to come up with solution from PRD that would both respect interoperability and enable translation from PRD documents.
Sandro: csma, you have presented it in a neutral way, but in reality, there was consensus from everyone but Changhai, who has not yet given a specific reason for his objection.
csma: nevertheless, I would not yet have proposed a resolution on that. Still needs more thought and discussion.
<sandro> from minutes: PROPOSED: PRD will have have "Modify" action which removes all previous values for the given properties, then sets one new value as given. Implementations can be use the fact that values for a given property are only provided via MODIFY (never ASSERT), then it can be implemented as single-valued. ←
<sandro> 17:32:19 <cke> -1
<sandro> Changhai Ke: -1 ←
Chris: so, what was the outcome?
Sandro: I understood that we had consensus to do Gary's proposal, unless within the next 2 weeks, Changhai comes up with objection/alternative.
csma: Afternoon discussion on interoperability with xml and o-o xml
... Both proposals were considered, and have various (dis)advantages
... Both are feasible and can guarantee interoperability.
... No recommendation, but significant progress on an issue that's been pending for a year.
... Also, discussion on PRD issue raised by Mark Proctor and those in ILOG: That universal quantification of all variables might work differently in PRD.
... Specifically, that universal quantifier might work differently depending on whether scope of quantifier was rule or (??) just condition.
... conclusion: universal quantifier works the same, as expected.
... Moving on, now, to the second day.
... (First day was very effective in terms of understanding issues, second day was very effective in terms of closing the issues/ passing resolutions)
... Discussed how PRD interoperated with RDF and OWL.
... PRD will not interact directly with RDF and OWL; will just inherit the interoperability from Core.
... discussed the safeness limitation. Finiteness is not an issue wrt PRD.
... Jos has an action to write safeness condition in Core.
... PRD is an extension of Core with added safeness condition.
... We then closed issue 82
sandro: everyone comfortable with Core being maximal subset of PRD and BLD. Axel argued for smaller more Datalog version of Core.
csma: discussed why we needed two cores, one with safeness, and a smaller one with finiteness
<ChrisW> i am ok with non-finiteness in CORE as long as we call an examples of such a "Core Breach"
<DaveReynolds> :-)
csma: Then we discussed a number of issues in Core: issue 84
(issue 84 regards subclass)
csma: We also closed issues.
... closed issue 72, about skolem functions in Core. No, no objectification construct in Core.
... Regretfully, we couldn't find a good design to address this.
... closed issue 33, about xml data sources. We had discussed xml data sources the day before. Our mechanism for accessing xml and rdf is enough; all others use externals. IOW, blackboxed external access.
... Issue 78, of what to make external: We decided that only externals in BLD, PRD, Core will be predicates and functions. No external frames, etc.
... short discussion of xml schema: should be imported by PRD and BLD? (issue 69). Decided we'd have one Core schema, included in BLD and PRD.
... Had planned to discuss issues 80 and 81, but Axel wasn't available, as hoped, on the phone.
<sandro> (Sorry, only paying half attention, to watch inauguration)
[get missing stuff]
csma: Date time stamp --- changhai objected to this --- wanted to see real impact --- has an action to agree to the type, or come up with concrete objection.
<ChrisW> leora, this is all in the f2f meeting minutes - it's not critical to capture everything csma says
<ChrisW> ...only if there is discussion
csma: Discussion of next F2F: if possible, in Boston, so Sandro can attend.
No other business.
<Gary> go obama!
<csma> +1
<Harold> +1
<apaschke> bye