<DanC_> I hope we can send some sort of record to public-cwm-talk
<DanC_> PAW meeting last week
<DanC_> let's see... which of the actions from last week's PAW ftf should go here?
<timbl> Meeting invitation
<timbl> Meeting invitation has Call-in details. Conferce code SWCWM
<DanC_> I offer to scribe if I can send the record to public-cwm-talk
<timbl> CWM talk archives
<timbl> DanC, we have to get everyone on the call on board for public minutes.
<DanC_> right
<DanC_> wish... a Zakim release that just does harmless stuff like queue management. (agenda tracking writes to the web, doesn't it?)
<timbl> Dan and Vlad join from mindlab
TBL: meeting goal: tasks for cwm/pychinko integration, perhaps rdflib integration
Vlad: I expect YK can make this time regularly
RESOLUTION: to send minutes to public-cwm-talk
<scribe> Scribe: DanC
<scribe> ACTION: TimBL to organize work on cwm (e.g. finish --why and check.py and pychinko integration of some sort) with danc, yarden, yosi, vlad, daniel. [DONE]
<scribe> ACTION: YK to schedule a meeting with TimBL and Bijan to discuss n3 semantics [CONTINUES]
without discussion
TBL: yosi's availability is going down as school starts...
DK: thought about why rdflib bnodes are the way they are. I'll write mail, but it's about persistence. They're long-lived. [?!]
<vlad> (i was away for the last week, have nothing to report)
TBL: persistence/naming of bnodes is an interesting issue... haystack folks [did something... missed]
<timbl> The semantics might change
DK: I also looked into Zope
interfaces.
... looks promisiong
[Zope interface in the sense of Java interfaces, not WSDL interfaces]
scribe:
YS: found a fix for pychinko bug;
see public-cwm-talk ...
... also experimented with closer cwm/pychinko integration.
seems to be working [did I hear that right?]
<DanC_> (ammendment to my 1-minute update: I spent some time noodling on N3 semantics w.r.t. ACL2, and Provability logic)
<DanC_> Provability logic
<DanC_> ACL2
YS: performance investigation indicates pretty-printing is where a lot of time goes
<DanC_> the slow part of my calendar sync:
<DanC_> plan.i3: plan.rdf $(PALMAGENT)/danger.n3 $(PALMAGENT)/danger2ical.n3
<DanC_> $(PYTHON) $(CWM) --chatty=$(CHATTY) plan.rdf $(PALMAGENT)/danger.n3 --think=$(PALMAGENT)/danger2ical.n3 --n3 --with 'http://majo@calendar.sidekick.dngr.com/event?id=' >$@
<DanC_> PALMAGENT=$(HOME)/devcvs/2001/palmagent
TimBL: we_should += speed up
pretty-printer
... so you're using cwm's indexes to feed the rete?
YS: yes... there's some duplicate indexing, but not too much..
TimBL: then there's a question of how to get it back out of the rete and print it...
YS: I still have an
IndexedFormula interface...
... this is much like existing cwm --think
TimBL: are there pychinko tests that you use as a matter of course?
Vlad: dunno yet, but I'm willing to take an ACTION to investigate. I'm just learning
TimBL: looked in $swap/test/perf
?
... er $swap/test/perform , yes
... color-oz.n3 [?] is a classic coloring problem... perhaps
not particularly relevant here...
... so there's the home for performance challenges
... so if you find some, stick them in
DanC: write access for... say... vlad?
TimBL: want commit access?
Vlad: sure
DK: [missed]
TimBL: I'm happy for everybody on these calls to have cvs write access
(of those here, on TimBL and DanC can make that happen, and my TODO list is way oversubscribed this week)
<timbl> ACTION: Tim to get Vlad cwm CVS access
DanC: we have an existing RFE to upgrade test harness from text diff to graph diff, where appropriate
<timbl> We should split tests up into inference tests which have a conaonicaling diff (cant.py)
<DanC_> RFE: evaluate test results by graph match rather than text diff
<DanC_> raised 2004-08-27T20:42:07Z
[... lots of cant.py and c14n discussion... missed...]
TimBL: any pychinko tests with nested formulae?
VK: dunno. gotta talk to Jordan
TimBL: soo...
YS: this pychinko integration has the same interface as query.py: you give it 3 formulas.
TBL: very nice.
...
TimBL: there was another idea from the whiteboard... last week...
YS: rete does 3ples... probably could do 4ples straightforwardly
TimBL: a file with log:includes
at the top level [?] can be done with quads, which can be done
completely with the rete
... given importance of nested stuff in PAW and TAMI...
DanC: we have a pretty concrete target now, right? the Rein run. [esp. the girl scout scenario from last week]
TimBL: yes, so vlad, that might be a good way for you to get into this... [?]
[... some stuff about unification and compound terms that's over the scribe's head...]
TimBL: step 1. make math:sum work
<timbl> 0. make math: negation work.
<timbl> 1- Make math:sum work
<timbl> 2. Make something with variable in it like list:in work
<vlad> TimBL, just to clarify: is this the extension work that you suggested for me to do
<DanC_> (hmm... when do we get serious about n-ary relations, I wonder?)
<DanC_> (the ArgList idiom could last for a dangerously long time ;-)
YS: the built-ins that pychinko can handle are relational operators, like math:lessThan, not functions
<timbl> Architecture A uses pychinko at the top level formula only, and uses built-0ins to access compound terms.
<timbl> Architecture B uses pytchink o recursively on the builtins
<timbl> Architecture C uses quads in pychjinko to be able to hanlde top level plus an log:included stuff
Vlad: so it's these math functions that you want me to do?
TimBL: well, all the ones that are...
<yosi___> term.py
-> http://www.w3.org/2000/10/swap/term.html term.py pydoc
YS: yes, list:in is a http://www.w3.org/2000/10/swap/term.html#MultipleReverseFunction
<DanC_> (the fact that built-in is a subclass of Term is something I object to, fyi)
TimBL explains swap.term.Function and ReverseFunction
-> http://www.w3.org/2000/10/swap/term.html#Function swap.term.Function
TimBL: and it can inherit both if
it can go either way
... there's also LightBuiltIn vs HeavyBuiltIn
<timbl> cwm_math
<timbl> cwm_math.py
<DanC_> hmm... move these interfaces from term.py to operator.py ? hmm... that reminds me of something I want to study in the ACL2 semantics... about function definitions
TimBL: see class BI_product(LightBuiltIn, Function):
<timbl> BI_product
<DanC_> (this BI_ prefix smells funny. I can't remember why it's there.)
<timbl> class BI_product(LightBuiltIn, Function):
<timbl> def evaluateObject(self, subj_py):
<timbl> t = 1
<timbl> for x in subj_py: t *= numeric(x)
<timbl> return t
TimBL: evaluateObject works on python objects; evaluateObj works on term
YS: evaluateObj has more args...
<timbl> class BI_first(RDFBuiltIn, Function):
<timbl> def evalObj(self, subj, queue, bindings, proof, query):
<timbl> if not isinstance(subj, NonEmptyList): return None
<timbl> return subj.first
<yosi___> cwm_list.py
<DanC_> "# Done explicitly in llyn" -- http://www.w3.org/2000/10/swap/cwm_list.py
<DanC_> v 1.12 2005/08/22 21:12:53
<DanC_> class BI_first(RDFBuiltIn, Function):
<DanC_> def evalObj(self, subj, queue, bindings, proof, query):
TimBL: queue is the set of... I wonder if that's used...
<scribe> ACTION: Yosi to see if the queue, bindings, proof, query args are needed in the evalObj interface
<DanC_> (I haven't checked my calendar for next week... we seem agreed to meet at this time weekly, though I didn't minute it yet)
<DanC_> (default due date for actions is the next meeting, is why I mention it)
YS: ... generates a circular reason...
TBL: fails that test. ;-) [what test? hello?]
TimBL: cwm --why with log:conclusion
YS: particular file is in test/includes/ somewhere
<timbl> swap/test/reason/detailed.tests
TimBL: documented in swap/test/reason/detailed.tests
<timbl> In my version has that test so we don't lose it
<scribe> ACTION: Vlad to stick calls to evalObj, with queue, bindings, etc. set to None, at the right places in pychinko ... at which point the math tests should pass
<timbl> and evalSubj and eval
<timbl> and note that eval; calls evaluate etc
<timbl> 1. test smath functions
<timbl> 2. test list function
<timbl> 3, test formula functions
<timbl> Look at regression.n3 for the set of basic tests
<timbl> and then test/*/detailed.tests
all the tests are enumerated in Cwm release 1.1rc1 build log
-> http://lists.w3.org/Archives/Public/www-archive/2005Aug/0004.html Cwm release 1.1rc1 build log
<timbl> in swap/test, run make
TimBL: build log does make prerelease, which runs everything, several ways. plain make just runs the normal tests
YS: yes, I'm using pychinko in my PYTHONPATH...
TimBL: how many files? an easy new subdirectory?
<DanC_> (does http://www.mindswap.org/~katz/pychinko/ let us browse the code?)
vlad: about 20 files
YS: but I'm not using main.py nor many of the others
<DanC_> (yes, we can browse... http://svn.mindswap.org/pychinko/ )
<timbl> http://svn.mindswap.org/pychinko/pychinko/
YS: afon.py isn't used any
more...
... dunno what formula.py is... don't think it's used...
... generator.py is only used for tests...
... using nodes.py prooftrace.py
... not using pychinkafon.py
... testing stuff: simplequery.py run_tests.py queries/
... uripath.py is copied out of swap
... dunno about # validation.py
TimBL: move stuff to $swap? integrate from svn when building the tarball? use redimport?
DC: redimport is too cool; let's
not go there until we've reached a project milestone
... there's a ZeroInstall CD...
DK: I saw that www-archive+breadcrumbs note, DanC. nifty.
:)
TimBL: keep as is?
DC: is how to test pychinko code documented?
YS: run_tests.py seems to work
DC: that's a little below the bar that I'd like us to work at.
<vlad> pychinko 0.1 README
TBL: tests are good things to share... are there manifests?
YS: much of the pychinko test data is machine-generated
ah... indeed... "Running the tests" http://www.mindswap.org/~katz/pychinko/downloads/README-0.1.html
<DanC_> pychinko home
TBL: timecheck... 90min? 30min more?
yes
YS: pychinko run_tests.py runs
pythinko and cwm and checks that they agree and reports the
time
...
DK: a high priority for me is separating interfaces from implementations
<DanC_> yes, interface files with doctest tests, please!
DK: as I said above, Zope
interface stuff is nice for this
... it may make it into python 2.5
<eikeon_> http://www.zope.org/Products/ZopeInterface
<scribe> ACTION: DK to send notes on Zope Interfaces to public-cwm-talk
DC: seems similar to modula-3 interfaces, which I really like (and like Java interfaces)
<eikeon_> http://svn.rdflib.net/branches/interfaces/
<timbl> Like C, C++, Objective-C too
TBL: we were going to do this anyway, no? ... what does Zope interfaces give?
<DanC_> well, in Java and M3, the compiler knows the difference between a class and an interface. Not so in C (I forget for C++). So in that way, yes, this is like C/C++
<eikeon_> http://svn.rdflib.net/branches/interfaces/rdflib/Graph.py
<eikeon_> Here's a better example: http://svn.rdflib.net/branches/interfaces/t.py
DC: I think there's a sweet-spot to do this for interfaces that we want to document/support
[e.g. myStore and each/any as used in toIcal.py]
TimBL: so shall we go over classes and strip down to bare minimum?
<scribe> ACTION: DanC to work with timbl to separate operators from term.py, look at other class organization
<timbl> - Simple term interface
<timbl> - Simple RDF store API
<DanC_> (term... abstract syntax...)
DanC: can we talk about throwing
away notation3.py in favor of grammar-based stuff? we have all
this cool data-driven grammar stuff, but we're not using it...
we don't run it against the tests as a matter of course.
... we're still using the crufty notation3.py
TBL: every week? every 2 weeks?
Vlad: every 2 weeks.
so... 14Sep at 14:30ET?
<DanC_> I have a standing 1-1 with somebody that I'd need to move or something, but that's manageable
RESOLUTION: to hold paw/cwm dev meetings 14Sep at 14:30ET and every other Weds thereafter until further notice.
<scribe> ACTION: DanC to copy http://inferenceweb.stanford.edu/registry/IE/CWM.owl to w3.org/swap space [CONTINUES]
DanC: does anybody have the ball on cwm --why for rein?
TimBL: well, I had the ball previuosly... hmm... whom to work with...
<scribe> ACTION: TimBL to work on --why toward log:includes, log:conclusion for rein
DanC: I wonder how to manage that cwm/pml action we assigned to dlm
<scribe> ACTION: dlm to get cwm generating PML that can be seen in iwbrowser, with timbl [CONTINUES]
ADJOURN.
<timbl> Thank you DanC for scribing.
sure.