See also: IRC log
<csma> Scribe: Michael Kifer
<csma> scribenick: Michael_Kifer
<csma> agendum+ admin
<csma> agendum+ liaisons
<csma> *PROPOSED:* accept minutes of telecon April 21
<csma> RESOLVED: accept minutes of telecon April 21
<csma> *PROPOSED:* accept minutes of F2F13
<csma> http://www.w3.org/2005/rules/wg/meeting/2009-04-15
<csma> http://www.w3.org/2005/rules/wg/meeting/2009-04-16
<csma> http://www.w3.org/2005/rules/wg/meeting/2009-04-17
<ChrisW> +1
<csma> RESOLVED: accept minutes of F2F13
<csma> next item
<csma> next item
<josb> I suppose Axel is currently in the SPARQL telecon
<csma> next item
<AdrianP> Zakin, ??P36 is me
<ChrisW> action-796: complete
<trackbot> ACTION-796 Put correspondence between RIF and RDF lists on next week's agenda notes added
<ChrisW> action-796: closed
<trackbot> ACTION-796 Put correspondence between RIF and RDF lists on next week's agenda notes added
<trackbot> If you meant to close ACTION-796, please use 'close ACTION-796'
<ChrisW> close action-796
<trackbot> ACTION-796 Put correspondence between RIF and RDF lists on next week's agenda closed
<ChrisW> close action-795
<trackbot> ACTION-795 Start RIF publications page on the wiki closed
<ChrisW> close action-794
<trackbot> ACTION-794 Start publications page with first entry closed
<ChrisW> close action-786
<trackbot> ACTION-786 Makr argnamesinuniterms as rejected closed
<AxelPolleres> summarizing my actions:
<ChrisW> close action-759
<trackbot> ACTION-759 Add the syntax and semantics of lists to BLD closed
<ChrisW> ACTION: harold to update xml syntax of lists [recorded in http://www.w3.org/2009/04/28-rif-minutes.html#action01]
<trackbot> Created ACTION-797 - Update xml syntax of lists [on Harold Boley - due 2009-05-05].
<csma> next item
<josb> http://www.w3.org/2005/rules/wiki/RIF-RDF-Lists
Jos: we want RIF facility to deal with lists to also handle RDF lists. Can we link them?
Jos proposed a semantics for such linkage at http://www.w3.org/2005/rules/wiki/RIF-RDF-Lists
The wiki page also includes test cases. Some show the difference between RDF lists and RIF lists.
<DaveReynolds> Sorry, I have to go to my conflicting meeting. My comments on lists were in email - esp. whether restricting to well-formed RDF lists to avoid the introduction of equality would be worth it.
csma: conformance clauses require to support only well-formed lists.
<josb> http://www.w3.org/2005/rules/wiki/RIF-RDF-Lists#Multiple_lists_with_one_identifier
Discussion of the first list test case.There is a difference betw RDF and RIF semantics. For instance, in RIF a=b in that test case, while in RDF it does not.
<sandro> List(a b c) a=d
<sandro> One list with two first means EITHER: you have a malformed graph, OR you're equating the two firsts.
<ChrisW> axel, we are here: http://www.w3.org/2005/rules/wiki/RIF-RDF-Lists#Multiple_lists_with_one_identifier
Jos: not clear what to do with malformed RDF list graphs. Probably better to use conformance, since it is unclear how to tweak semantics.
Chris: can this be handled by adding additional import profiles?
<sandro> chris: How about: in core, this kind of list means what it means in RDF.
Maybe impose restrictions on the embeddings of RDF into RIF? That is, if you embed an RDF malformed list then it becomes just a bunch of triples.
Jos: this won;t satisfy the RDF types. Not clear what such coupling would mean then.
<sandro> +1 do it in Conformance
<sandro> that is --- say that folks don't need to implement head-equality just for rdf lists, in core.
<josb> +1
MichaelKifer:0
<AdrianP> 0
<ChrisW> 0
<sandro> STRAWPOLL: SWC will say, as a Conformance matter, that for combination with Core and RDF lists, you don't have to implement head-equality, just for lists.
<mdean> 0
<AxelPolleres> +0 slightly positive but not sure yet
<sandro> +1
<sandro> dave: +1 (via e-mail)
<sandro> but DONT CALL IT "malformed". it's just too expressive for Core.
<ChrisW> ACTION: josb to write conformance section for SWC [recorded in http://www.w3.org/2009/04/28-rif-minutes.html#action02]
<trackbot> Created ACTION-798 - Write conformance section for SWC [on Jos de Bruijn - due 2009-05-05].
<Zakim> sandro, you wanted to ask whether this stuff all only applies to rulesets that due certain kinds of imports?
<sandro> STRAWPOLL: mapping of rdf:list to rif:lists, as per Jos' email: -1 == extension , +1 == one-to-one
<sandro> jos: 1-1 mapping gives more flexibility; you can access the data either way, and play around however you want; export your results, as queries of RDF graphs, etc.
<sandro> jos: but 1-1 is harder to implement. in practice, you'll need to maintain two list structures in parallel. Jena has this. But a pure rule engine without function symbols, this this wont be implementable by itself.
<sandro> jos: you'll need function symbols. the use of RIF lists implies a whole bunch of triples....
<sandro> jos: ie can't be embedded in rif core.
<sandro> csma: maybe use extension for rif core, 1-1 for BLD?
<sandro> jos: No, that's an invisibile extension.
<sandro> STRAWPOLL: mapping of rdf:list to rif:lists, as per Jos' email: -1 == extension , +1 == one-to-one
<ChrisW> +extension
<josb> -1
<csma> +1
<sandro> +0.75 users would want it, but it is kind of challeneing to implement.
MichaelKifer:-1
<josb> Dave: -1 (email)
<ChrisW> hassan: 0
<mdean> 0
<AdrianP> 0 (don't knwo)
<csma> Hassan: 0
<AxelPolleres> 0 (not yet sure still)
<Harold> -1
<csma> I meant: -1 (extension)
sandro: any implementation will rely on native platform support for lists
<sandro> basically, you treat rdf:first and rdf:rest as builtins. no problem.
<sandro> (not exactly, of course.)
sandro: I might object to extensions, since most people who voted probably didn't think how to implement extensions.
<sandro> sandro: maybe we should do one-to-one "at risk", to see how hard it turns out to be implement.
jos to finalize the list embedding doc by next week with 1-1 marked at risk.
<sandro> please draft with "extension", with the "one-to-one" bit, at risk.
sandro to decide whether to object to list-as-extensions by next week.
Next week will resolve in favor of 1-1 or extensions.
<johnhall> Sorry - still having phone problems - bye
<josb> ACTION: josb to extend SWC with lists, with 1-to-1 and extensions as alternatives [recorded in http://www.w3.org/2009/04/28-rif-minutes.html#action03]
<trackbot> Created ACTION-799 - Extend SWC with lists, with 1-to-1 and extensions as alternatives [on Jos de Bruijn - due 2009-05-05].
<csma> next item
<csma> http://www.w3.org/2005/rules/wiki/LastCallPlan
<ChrisW> close action-735
<trackbot> ACTION-735 Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary in DTB closed
<ChrisW> close action-737
<trackbot> ACTION-737 Include all the builtins for xs:boolean per F&O closed
<ChrisW> close action-739
<trackbot> ACTION-739 Add xs:float to numeric builtins closed
<ChrisW> ACTION: csma to add PRD conformance clause [recorded in http://www.w3.org/2009/04/28-rif-minutes.html#action04]
<trackbot> Created ACTION-800 - Add PRD conformance clause [on Christian de Sainte Marie - due 2009-05-05].
<ChrisW> ACTION: adrian to update PRD presentatoin syntax [recorded in http://www.w3.org/2009/04/28-rif-minutes.html#action05]
<trackbot> Created ACTION-801 - Update PRD presentatoin syntax [on Adrian Paschke - due 2009-05-05].
<StellaMtchell> yes
<ChrisW> ACTION: harold to update the xml syntax for generalized quanitifiers by may 7 [recorded in http://www.w3.org/2009/04/28-rif-minutes.html#action06]
<trackbot> Created ACTION-802 - Update the xml syntax for generalized quanitifiers by may 7 [on Harold Boley - due 2009-05-05].
<csma> PROPOSED: The negation operator, in PRD, will be called: Not, which will also be the tag of the corresponding XML element in the concrete syntax
csma: PRD task force about the name for inflationary negation.
<ChrisW> classical negation is usually called NOT
Adrian suggested to use Not
sandro: Not is unclear and politically charged. This is why we decided to use naf and neg.
<sandro> sandro: it seems to me that each community uses "Not" internally, and the choice of "neg" and "naf" is a sort of settlement, to avoid fighting over who gets "not". So for PRD to use it seems wrong.
<sandro> jos: in some sense PRD's 'not' is the same as naf and neg.
jos: it doesn't matter what to use, since PRD's negation is always tested in one model.
Hassan concurs w/jos
<AdrianP> the semantics of not (negation) is specified by the semantics of the dialect
<josb> actually, I think PRD should just pick Neg or Naf. It doesn't really matter which one
<sandro> Michael_Kifer: it's not correct to say that PRD's "not" being in one model makes the kind of "not" not matter. Because you *always* look at one model for negation.
<sandro> +1 going for five more minutes
<csma> PROPOSED: The negation operator, in PRD, will be called: Not, which will also be the tag of the corresponding XML element in the concrete syntax
<ChrisW> -1
<josb> how about changing Not to Naf in the proposal? I think it could pass then
MichaelKifer:0
<sandro> -1 at least until I'm convincing that this "not" is far more intuitive than the meaning of NAF or NEG.
<josb> -0.5
<Harold> 0
<mdean> 0
<AdrianP> +1
<csma> Hassan: +1
MichaelKifer:How about iNot (provided Apple won't sue us)?
<AxelPolleres> 0 (don't care)
<sandro> if_fail
<ChrisW> possibilities: p-not, s-not, k-not
<AdrianP> it is also common in production rules
<ChrisW> yes, yNot
<sandro> ynot ynot?
<josb> Not-#436
<ChrisW> gordian-not
<AxelPolleres> better-not?
<ChrisW> op-not
<sandro> yeap, opnot.
<sandro> if set_false(....)