[08:32:01 CDT(-0500)] <colinclark> jessm: Hey
[08:32:10 CDT(-0500)] <colinclark> I'm on the "Common Terms Registry" meeting at the moment
[08:32:23 CDT(-0500)] <jessm> colinclark: cool
[08:32:25 CDT(-0500)] <colinclark> and there's a lot of talk about actually building it
[08:33:12 CDT(-0500)] <colinclark> This is another one of these things that is somewhat on the periphery of our Floe/PGA work, but there's pressure to make happen
[08:33:27 CDT(-0500)] <colinclark> and I really don't want developers to be writing code for this thing without at least a basic design
[08:34:21 CDT(-0500)] <jessm> colinclark: ah ha
[08:34:33 CDT(-0500)] <jessm> seems like i should make a list...
[08:34:42 CDT(-0500)] <jessm> we have a growing list of design activities
[08:34:49 CDT(-0500)] <colinclark> Yeah, that's what I was thinking
[08:35:02 CDT(-0500)] <colinclark> I'm happy to help chat about priorities for all these things
[08:35:10 CDT(-0500)] <colinclark> as well as doing my best to explain what they actually are 
[08:35:39 CDT(-0500)] <jessm> colinclark: yes and YES to that
[08:35:48 CDT(-0500)] <jessm> esp. since there have been some big changes lately
[08:35:52 CDT(-0500)] <jessm> to the CTR
[08:36:05 CDT(-0500)] <danaayotte> colinclark jessm I'm happy to do some designing
[08:36:50 CDT(-0500)] <colinclark> wicked
[08:37:01 CDT(-0500)] <colinclark> jessm: Fortunately, the big changes to the CTR are good ones
[08:37:06 CDT(-0500)] <colinclark> massive simplification
[08:37:21 CDT(-0500)] <jessm> roger that
[08:37:39 CDT(-0500)] <jessm> colinclark: should we have another designerly chat and actually let you talk this time? 
[08:37:45 CDT(-0500)] <colinclark> lol
[08:37:51 CDT(-0500)] <colinclark> Be careful what you wish for
[08:37:57 CDT(-0500)] <colinclark> but I'd be happy to
[08:38:06 CDT(-0500)] <jessm> well, talk, within reason
[08:38:27 CDT(-0500)] <jessm> tomorrow we have PMT/PCP in the a.m.
[08:38:31 CDT(-0500)] <jessm> should we chit chat after?
[08:38:36 CDT(-0500)] <jessm> 10 ish?
[08:38:54 CDT(-0500)] <colinclark> ok, sounds good
[08:38:57 CDT(-0500)] <colinclark> it's in my calendar
[08:39:18 CDT(-0500)] <jessm> danaayotte: that work for you?
[08:39:35 CDT(-0500)] <danaayotte> yes
[08:46:13 CDT(-0500)] <jessm> danaayotte: can you double-check that i got all the "blanks" pages from the wiki with CMHR stuff on 'em?
[08:46:51 CDT(-0500)] <danaayotte> jessm: looks good, thanks
[09:11:05 CDT(-0500)] <heidiv> fyi Justin_o i've started a jira for investigating carousel widget options here: http://issues.fluidproject.org/browse/FLUID-4972
[09:11:14 CDT(-0500)] <Justin_o> heidiv: thanks
[09:11:59 CDT(-0500)] <colinclark> heidiv: Am I right in thinking that you'll need jvass to answer a few of the interaction questions on this JIRA?
[09:12:09 CDT(-0500)] <colinclark> Such as specifying the scrolling behaviour, etc.?
[09:12:19 CDT(-0500)] <heidiv> colinclark she's started a wiki page that i reference in the jira
[09:12:36 CDT(-0500)] <colinclark> ah, great
[10:02:07 CDT(-0500)] <michelled> anastasiac, arashs, cindyli, heidiv, Justin_o: can we have a quick meeting to estimate some of the work that we talked about on Friday?
[10:02:22 CDT(-0500)] <cindyli> sure, michelled
[10:02:23 CDT(-0500)] <arashs> sure
[10:02:28 CDT(-0500)] <anastasiac> in the collar room, michelled?
[10:02:46 CDT(-0500)] <heidiv> sure, skype me?
[10:03:11 CDT(-0500)] <michelled> collab room is busy - let's meet near the kitchen. yes, heidiv, Justin_o will Skype you and cindyli in
[10:03:30 CDT(-0500)] <heidiv> 
[10:37:31 CDT(-0500)] <supungs> Hi
[10:42:42 CDT(-0500)] <system64> Morning colinclark!
[10:43:19 CDT(-0500)] <colinclark> Hey system64, how's it going?
[10:45:11 CDT(-0500)] <system64> colinclark: Doing great! Checked out Flocking this weekend
[10:45:41 CDT(-0500)] <system64> colinclark: Its simply awesome!
[10:46:41 CDT(-0500)] <colinclark> Oh wow
[10:46:44 CDT(-0500)] <colinclark> thanks for saying that
[10:46:54 CDT(-0500)] <colinclark> There's still a lot of work to do, but it's coming along nicely
[10:48:07 CDT(-0500)] <colinclark> system64: Have you been thinking any more about the two projects you were interested in?
[10:50:40 CDT(-0500)] <system64> Yeah! I think the Music Development Environment is going to be a huge thing. But I don't have experience with DSP and digital audio.
[10:52:09 CDT(-0500)] <colinclark> I think a willingness to learn is the key
[10:52:29 CDT(-0500)] <colinclark> If you feel like you can learn as you go, you can probably describe how you'll do that in your project proposal
[10:52:48 CDT(-0500)] <colinclark> and the more specific you are--e.g. sources you'll refer to etc., the better it will probably be
[10:55:46 CDT(-0500)] <system64> colinclark: I'm still not clear about the project though, are we going to build something like 'JAM with Chrome'?
[11:12:00 CDT(-0500)] <system64> colinclark: I've been looking into Web Audio for sometime now, it was actually the Web Audio API that got my interest into Digital Audio. I'd like to admit I still don't understand most things. But I'm certainly up for the learning curve!
[11:28:01 CDT(-0500)] <colinclark> sounds great, system64
[11:28:08 CDT(-0500)] <colinclark> I think the idea of the project is still somewhat open-ended
[11:28:40 CDT(-0500)] <colinclark> but the idea is to create an environment where musicians can create instruments with Flocking's declarative JSON format, and then wire those synths up to different types of controls
[11:31:12 CDT(-0500)] <system64> colinclark: Are we going to create instruments with flocking?
[11:32:00 CDT(-0500)] <colinclark> Yes, I think that would probably make sense
[11:35:16 CDT(-0500)] <system64> I'm not able to try it now, but I think 'JAM with Chrome' was something similar. Have you tried it?
[11:49:34 CDT(-0500)] <colinclark> I haven't, no
[12:15:21 CDT(-0500)] <anastasiac> michelled, the video player WordPress plugin is ready for another review: https://github.com/inclusive-design/infusion-videoPlayer-wp-plugin/pull/5
[12:15:30 CDT(-0500)] <michelled> thanks anastasiac
[12:25:59 CDT(-0500)] <colinclark> anastasiac: Great post to the a11y-metadata list!
[12:26:20 CDT(-0500)] <anastasiac> thanks, colinclark
[12:27:27 CDT(-0500)] <michelled> colinclark: Justin_o and I were just talking about our criteria for getting his branch in master
[12:27:58 CDT(-0500)] <michelled> I'm proposing that we get the branch to a state where we are happy to see it in master, but we still expect to do some more work on it.
[12:28:26 CDT(-0500)] <colinclark> Seems reasonable, as long as there are clear to dos and JIRAs filed for them
[12:28:26 CDT(-0500)] <michelled> for example, the IE tests are currently failing in master
[12:28:54 CDT(-0500)] <michelled> I'm suggesting that instead of spending the estimated 4 days to fix them now, we get the new branch in first and then fix them
[12:29:38 CDT(-0500)] <colinclark> Yeah, I think that's fine
[12:29:44 CDT(-0500)] <Justin_o> colinclark, michelled: those aren't specific to our repo, the master has failing IE tests
[12:29:46 CDT(-0500)] <colinclark> again, clear JIRAs are the key
[12:30:09 CDT(-0500)] <michelled> cool
[12:31:08 CDT(-0500)] <michelled> as I was saying to Justin_o, it would be really nice to get my master back
[12:31:17 CDT(-0500)] <colinclark> no kidding!
[12:31:18 CDT(-0500)] <michelled> I read my sticky note every day and freak out a little
[12:31:56 CDT(-0500)] <colinclark>
[12:38:19 CDT(-0500)] <Justin_o> bosmon, colinclark, michelled: would one of you like to review my new pull request https://github.com/fluid-project/infusion/pull/310
[14:06:27 CDT(-0500)] <colinclark> Bosmon: Your friend Alex wrote a blog post about the Blink fork. I though his comments near the end about it being related to "dependencies and reducing abstractions" was quite interesting: http://infrequently.org/2013/04/probably-wrong/
[14:06:37 CDT(-0500)] <colinclark> It is written with his typical rhetorical style as well
[14:13:23 CDT(-0500)] <Bosmon> "My friend" Alex has exactly the argumentative stance as Microsoft apologists like Raymond Chen
[14:15:24 CDT(-0500)] <Bosmon> It's no surprise that his "citation" for his final comment is himself
[14:16:12 CDT(-0500)] <Bosmon> Which contains a half-baked farrago of poorly understood History of Science : P
[14:16:48 CDT(-0500)] <Bosmon> In fact his statement is equivalent to the well-known fallacy known as "Politician's Logic": "Something must be done! This is something - therefore we must do it"
[14:22:36 CDT(-0500)] <Bosmon> Hi Justin_o - I had a look at your issue, but I can't reproduce it
[14:22:46 CDT(-0500)] <Bosmon> Can you tell me exactly what happens, and on what platform?
[14:23:57 CDT(-0500)] <Justin_o> Bosmon: you're talking about the one for my pull request right
[14:24:02 CDT(-0500)] <Bosmon> Justin_o - yes
[14:24:15 CDT(-0500)] <Justin_o> Bosmon: i ran into that with the FLUID-4927 branch
[14:24:19 CDT(-0500)] <Bosmon> What did you observe that made you file FLUID-4973?
[14:25:52 CDT(-0500)] <Justin_o> we would get radom failures in IE8 and which would try to call your console logs… when it would hit the applyHostFunction and try to trigger the Function.prototype.bind you would then get a browser error
[14:26:11 CDT(-0500)] <Justin_o> note that the test wasn't initially failing because of this, just an additional issue to go along with it
[14:26:39 CDT(-0500)] <Bosmon> Justin_o - that should be impossible because typeof (console.log) === "function" always returns false on IE8
[14:26:50 CDT(-0500)] <Bosmon> Do you have something in your branch that can demonstrate the problem?
[14:28:07 CDT(-0500)] <Justin_o> Bosmon: um.. i'll have to take a look.. i was trying something out at the time that i reverted
[14:28:49 CDT(-0500)] <Bosmon> Justin_o - Either way, we need a test case to demonstrate that this fix is needed
[14:30:34 CDT(-0500)] <Justin_o> Bosmon: okay.. although i like your suggestion better of just getting rid of applyHostFunction
[14:31:06 CDT(-0500)] <Bosmon> We only put it there in the first place because of a very similar situation
[14:31:13 CDT(-0500)] <Bosmon> We got a report of a failure from Harris that none of us could reproduce
[14:31:24 CDT(-0500)] <Justin_o> Bosmon: oh 
[14:31:34 CDT(-0500)] <Justin_o> Bosmon: would you like me to make you a test case then..
[14:31:39 CDT(-0500)] <Justin_o> for my issue
[14:32:05 CDT(-0500)] <Bosmon> Justin_o - yes, we need to have at least some idea how to demonstrate the failure
[14:32:18 CDT(-0500)] <Bosmon> Right now I don't have any problems running our fluid.log in IE8 either with or without the console
[14:32:25 CDT(-0500)] <Bosmon> I think we would have noticed a failure so blatant
[14:33:13 CDT(-0500)] <Justin_o> Bosmon: yes, you'd think
[14:33:30 CDT(-0500)] <Justin_o> could be some other interaction.. i'll try to write up a test case to go along with my pull request
[14:33:38 CDT(-0500)] <Bosmon> Thanks, Justin_o
[14:33:56 CDT(-0500)] <Justin_o> Bosmon: also, did you have a chance to read the chat logs about the FLUID-4927 pull request
[14:34:13 CDT(-0500)] <Bosmon> Justin_o - which day should I look at?
[14:35:22 CDT(-0500)] <Justin_o> Bosmon: today
[14:35:25 CDT(-0500)] <Justin_o> just shortly after you left
[14:39:17 CDT(-0500)] <Bosmon> Justin_o - it seems that michelled was suggesting less stringent criteria for approving our branch?
[14:39:46 CDT(-0500)] <Bosmon> Rather than "it needs to be good enough to ship", we are thinking of something more like "It runs without obvious problems on all platforms"?
[14:40:12 CDT(-0500)] <Bosmon> colinclark - I think this one is a far more honest summary of the meaning of "Blink" : P http://prng.net/blink-faq.html
[14:40:29 CDT(-0500)] <colinclark> Yes, I read that one after Alex's
[14:42:28 CDT(-0500)] <Bosmon> colinclark - and this one is more than slightly reminiscent of an argument of Ray's during the Sakai years: "If there is wisdom in the Chrome team, it is that these projects are not only recognized as important, but the very best engineers volunteer to take them on."
[14:43:11 CDT(-0500)] <Bosmon> "Smart developers are easily bored, so we need to produce shiny but possibly spurious modernity on a regular basis to keep them entertained"
[14:43:48 CDT(-0500)] <colinclark> I just read something about Oracle, of all companies, preparing a WebKit-based browser with their own JavaScript engine
[14:43:49 CDT(-0500)] <colinclark> http://en.wikipedia.org/wiki/Nashorn_%28JavaScript_engine%29
[14:44:10 CDT(-0500)] <colinclark> bizarre
[14:44:14 CDT(-0500)] <Bosmon> Interesting that that is still rumbling on
[14:45:02 CDT(-0500)] <Bosmon> Although the fact they released it to OpenJDK suggests, unfortunately, that Oracle may no longer consider it strategic
[14:45:18 CDT(-0500)] <Bosmon> They are not the kind of company who perceives intrinsic value in open sourcing their products
[14:45:35 CDT(-0500)] <colinclark> indeed
[14:45:58 CDT(-0500)] <colinclark> This is one of the reasons why I'm increasingly concerned about the preponderance of Java-based code in Cloud4all
[14:46:22 CDT(-0500)] <colinclark> I have no confidence at all that Java will be much more than a language one uses for building Android apps in, say, five years
[14:46:31 CDT(-0500)] <colinclark> But perhaps I'm being optimisitc
[14:46:32 CDT(-0500)] <michelled> Bosmon: my other criteria is that we don't make anything worse than what's in master. meaning, the code should be at least the same quality as what's in there and tests that are passing should still be passing.
[14:47:07 CDT(-0500)] <Bosmon> michelled - that seems reasonable
[14:47:32 CDT(-0500)] <Bosmon> This implies that what we commit will have to have SOME kind of version of "options mapping code" even if it only extends to the old panel configurations
[14:47:37 CDT(-0500)] <Bosmon> colinclark - "Java won't curl up and die like Cobol, insists Oracle" : P
[14:47:44 CDT(-0500)] <Bosmon> http://www.theregister.co.uk/2012/03/07/oracle_java_9_10_roadmap/
[14:47:55 CDT(-0500)] <colinclark> What a great headline
[14:48:11 CDT(-0500)] <Bosmon> Amazingly "Java is becoming the new Cobol" dates from 2007 ......
[14:48:49 CDT(-0500)] <Bosmon> Just 6 months before we came to that conclusion ourselves : P
[14:49:04 CDT(-0500)] <colinclark> I imagine, outside of deeply-entrenched enterprises, that the vast majority of new Java projects are, in fact, Android applications
[14:49:30 CDT(-0500)] <colinclark> and I guess the legal case makes it clear that Oracle has absolutely none of the old Sun-style "Java certified" control over it
[14:50:04 CDT(-0500)] <Bosmon> My feeling is that "Java 8" and further will have something like the dusty status of such modern products as "Fortran 90" : P
[14:50:34 CDT(-0500)] <Bosmon> "We felt we had to modernise this thing but overlooked the fact that all of our remaining users are still here only because they need something that doesn't change"
[14:50:59 CDT(-0500)] <colinclark> lol
[15:16:19 CDT(-0500)] <Justin_o> Bosmon: i was looking into FLUID-4973 to try to write you a test case, but haven't been able to yet and have to run now. However, I've found a rather obscure way to reproduce it in the FLUID-4927 branch
[15:16:28 CDT(-0500)] <Bosmon> Justin_o - excellent
[15:16:38 CDT(-0500)] <Justin_o> Bosmon: to reproduce, you have to run the Settings Panels Tests
[15:16:44 CDT(-0500)] <Bosmon> Although hopefully this doesn't amount to replacing "console.log" with a function of your own devising
[15:17:04 CDT(-0500)] <Justin_o> Bosmon: open the IE8 debugger, make sure it is using the proper IE8 modes for everything and then start debugging
[15:17:16 CDT(-0500)] <Justin_o> periodically it will hit the error, but not every time
[15:17:27 CDT(-0500)] <Bosmon> Justin_o: !!!!
[15:17:29 CDT(-0500)] <Justin_o> haha, no i didn't do that
[15:17:52 CDT(-0500)] <Bosmon> PERIODICALLY IT WILL HIT THE ERROR BUT NOT EVERY TIME!!?
[15:18:48 CDT(-0500)] <Bosmon> Justin_o - should I use your FLUID-4927 branch, or FLUID-4927-b, or some other one?
[15:19:56 CDT(-0500)] <Justin_o> Bosmon: FLUID-4927-b
[15:20:08 CDT(-0500)] <Justin_o> i suppose you could also use cindy's from the pull request
[15:21:11 CDT(-0500)] <Bosmon> Justin_o - I tried it and it seemed to work fine
[15:21:27 CDT(-0500)] <Bosmon> What does "make sure it is using the proper IE8 modes for everything" involve?
[15:22:32 CDT(-0500)] <Justin_o> Bosmon: when you open the IE debugger, there is a set of menus at the top. (like any windows app)
[15:22:56 CDT(-0500)] <Justin_o> the two to the right Browser Mode: and Document Mode should be set to IE8 and IE8 Standards respectively
[15:23:00 CDT(-0500)] <Bosmon> Yes
[15:23:02 CDT(-0500)] <Bosmon> Those are set
[15:23:11 CDT(-0500)] <Bosmon> But I don't see any failure with the logging
[15:23:15 CDT(-0500)] <Justin_o> Bosmon: good.. did you click the "Start Debugging" button
[15:23:24 CDT(-0500)] <Bosmon> Ah no
[15:23:28 CDT(-0500)] <Bosmon> Ok, I've done that now
[15:23:34 CDT(-0500)] <Justin_o> now refresh the page..
[15:23:44 CDT(-0500)] <Bosmon> It still worked
[15:23:46 CDT(-0500)] <Justin_o> it only happens periodically so you might have to try a few times
[15:24:23 CDT(-0500)] <Bosmon> got it
[15:24:31 CDT(-0500)] <Bosmon> On my 8th refresh : P
[15:24:34 CDT(-0500)] <Bosmon> Sodding sod
[15:24:38 CDT(-0500)] <Justin_o> that's better than me
[15:24:50 CDT(-0500)] <Justin_o> i wonder if it's just a debugger bug now that we've stepped through it like this
[15:25:16 CDT(-0500)] <Bosmon> Justin_o - so, the reason is actually that it is trying to operate a fluid.fail
[15:25:27 CDT(-0500)] <Bosmon> We actually have a synchronization problem in the testing framework
[15:25:43 CDT(-0500)] <Bosmon> The message it is trying to display is "Sequence error: attempt to use test environment which has already been destroyed"
[15:25:49 CDT(-0500)] <Justin_o> Bosmon: oh.. i think these test use the new framework too
[15:26:11 CDT(-0500)] <Bosmon> And the source of the error is actually the raw call to fluid.applyHostFunction on line 105 of fluid.logActivity
[15:26:18 CDT(-0500)] <Bosmon> Rather than a direct call to fluid.log
[15:27:00 CDT(-0500)] <Justin_o> Bosmon: ah.. so it is a bug, just not really the one i thought it was
[15:27:11 CDT(-0500)] <Bosmon> Justin_o - it is in fact two bugs
[15:27:28 CDT(-0500)] <Bosmon> Firstly the bug in the testing framework which causes the failure, and secondly the bug in fluid.logActivity which prevents it being logged
[15:28:50 CDT(-0500)] <colinclark> Bosmon: Is there anything in particular you did to deduce this?
[15:28:55 CDT(-0500)] <Justin_o> Bosmon: bugs are always traveling in groups eh… glad you were able to see it in action, i doubt i would have been able to track it down to the root cause
[15:29:08 CDT(-0500)] <Bosmon> colinclark - I just looked at the stack trace when I could reproduce the failure in IE8
[15:29:14 CDT(-0500)] <Justin_o> Bosmon: i have to run, but thanks for following up with this
[15:29:24 CDT(-0500)] <colinclark> Can you paste a copy of the stack trace you see, Bosmon?
[15:29:30 CDT(-0500)] <Bosmon> colinclark - I can't
[15:29:36 CDT(-0500)] <colinclark> I'm curious to take a look and don't have my IE VM running
[15:29:37 CDT(-0500)] <colinclark> ok
[15:29:42 CDT(-0500)] <Bosmon> Since every element of it says "JScript anonymous function"
[15:29:46 CDT(-0500)] <Bosmon> Actually every element except one
[15:29:49 CDT(-0500)] <Bosmon> Which says "fireToListeners"
[15:30:00 CDT(-0500)] <Bosmon> There's no alternative but going through each one by hand to see what it is................
[15:30:03 CDT(-0500)] <colinclark> But it gives you line numbers?
[15:30:07 CDT(-0500)] <colinclark> or you can click to see?
[15:30:11 CDT(-0500)] <Bosmon> colinclark - click to see
[15:30:17 CDT(-0500)] <Bosmon> No info in the GUI whatever
[15:30:26 CDT(-0500)] <colinclark> IE8 is still terrible
[15:30:27 CDT(-0500)] <colinclark> oh well
[15:30:37 CDT(-0500)] <Bosmon> IE8, like FORTRAN 77, will forever be what it is
[15:30:47 CDT(-0500)] <Bosmon> All we can hope is some day to be able to disuse it.......
[15:31:54 CDT(-0500)] <Bosmon> Probably the simplest test case for the fix would be to add a "fluid.logActivity" call somewhere in our testing suite
[15:32:17 CDT(-0500)] <Bosmon> This is actually incredibly recent code and was only introduced about the time of San Diego
[15:32:50 CDT(-0500)] <Bosmon> These are the functions that will assist sgithens in producing visualization tools
[15:33:47 CDT(-0500)] <colinclark> ah, yes
[15:33:48 CDT(-0500)] <colinclark> great
[16:04:00 CDT(-0500)] <colinclark> kasper: you still conscious?
[16:04:09 CDT(-0500)] <kasper> colinclark: more or less
[16:04:31 CDT(-0500)] <colinclark> Quick question?
[16:04:33 CDT(-0500)] <kasper> I'm debating whether to cook dinner, or just give up on eating
[16:04:33 CDT(-0500)] <kasper> sure
[16:04:38 CDT(-0500)] <Bosmon> colinclark - I just passed on the note about the duplicate MouseTrails
[16:04:50 CDT(-0500)] <colinclark> SECRETLY!
[16:05:22 CDT(-0500)] <kasper> colinclark, Bosmon: should be fixed now
[16:05:31 CDT(-0500)] <colinclark> I was wondering whether the Flatness Zombies will eat our brains for this hierarchy: https://github.com/kaspermarkus/universal/blob/pilots/testData/preferences/os_gnome.json
[16:05:42 CDT(-0500)] <Bosmon> "hierarchy? I see no hierarchy!"
[16:06:08 CDT(-0500)] <kasper> I agree with Le Bass
[16:06:12 CDT(-0500)] <colinclark> I guess we have three distinctions, but I find myself constantly confused
[16:06:17 CDT(-0500)] <colinclark> 1. Common terms
[16:06:25 CDT(-0500)] <colinclark> 2. Application-unique terms
[16:06:26 CDT(-0500)] <colinclark> and
[16:06:29 CDT(-0500)] <colinclark> 3. Just some settings
[16:06:39 CDT(-0500)] <colinclark> #1 and #2 are always pretty well flat
[16:06:54 CDT(-0500)] <colinclark> or at least, as flats as their definition allows them to be
[16:07:04 CDT(-0500)] <colinclark> whereas #3 is, well, "just some settings"
[16:07:13 CDT(-0500)] <colinclark> which I guess is what is in these sets of preferecnes
[16:07:35 CDT(-0500)] <kasper> so you want something crazy like: "http://registry.gpii.org/applications/org\\.gnome\\.desktop\\.a11y\\.magnifier.screen-position"?
[16:08:09 CDT(-0500)] <kasper> colinclark: Does our framework even support that?
[16:08:23 CDT(-0500)] <colinclark> Well, honestly, this looks like a quite sensible representation for application-specific settings as far as I'm concerned
[16:08:50 CDT(-0500)] <colinclark> though others, I suspect, will quite vehemently disagree
[16:09:39 CDT(-0500)] <colinclark> As for whether we support it, I guess I don't know
[16:09:47 CDT(-0500)] <colinclark> I'd have to get my head around what it actually means
[16:09:49 CDT(-0500)] <kasper> I guess there is a valid argument about not being able to describe contexts/sources/whatever of the individual settings in the way my NP sets are written
[16:09:50 CDT(-0500)] <colinclark> or even how it does it now
[16:10:15 CDT(-0500)] <kasper> well, the thing is right now, basically from the moment we read the preferences, they're ontologized
[16:10:48 CDT(-0500)] <kasper> (even the application specific terms - to the extend that one can ontologize these, meaning just an app-id block with settings in them)
[16:10:59 CDT(-0500)] <colinclark> right
[16:11:29 CDT(-0500)] <colinclark> presumably the "ontologization" would actually choose to gather up groups of app-specific preferences together into a single coherent block if it chose to?
[16:11:50 CDT(-0500)] <kasper> colinclark: I suggest we call a truce with the zombies until post-pilots (or post pilot-rush anyway) and then start having some serious meetings about the matchmaker framework, ontologies, transformations, contexts, NP formatting, etc
[16:12:12 CDT(-0500)] <kasper> yeah - that would make sense to me
[16:12:18 CDT(-0500)] <colinclark> I guess I was just hoping to understand how things actually work, why they work that way, and how we imagine they should work
[16:12:36 CDT(-0500)] <colinclark> but it is late
[16:12:47 CDT(-0500)] <kasper> "hoping to understand how things actually work" – I've given up on that a looooong time ago 
[16:13:06 CDT(-0500)] <Bosmon> DAMN YOU, KASPARNET
[16:13:14 CDT(-0500)] <colinclark> actually, this is interesting, kasper
[16:13:20 CDT(-0500)] <colinclark> Let me find a link to an email I just discovered
[16:13:33 CDT(-0500)] <colinclark> where some frustration was raised about preferences that look just like this
[16:13:48 CDT(-0500)] <colinclark> you will be, I guess, unimpressed with my response
[16:14:01 CDT(-0500)] <colinclark> Are there archives for the SP3 mailing list?
[16:14:14 CDT(-0500)] <colinclark> I assume that would be far to useful a feature to have provided
[16:14:35 CDT(-0500)] <colinclark> Short form of the email:
[16:14:42 CDT(-0500)] <kasper> colinclark: afc there arent archives for those
[16:14:47 CDT(-0500)] <kasper> ofc*
[16:15:17 CDT(-0500)] <colinclark> Christophe: "So we can't write something like: http://wiki.gpii.net/index.php/SmartHouses_Preference_Sets#Flat_Preference_Set_for_Nitesh , we'll need to rewrite it?"
[16:15:24 CDT(-0500)] <colinclark> Me: "No, that's not the case. You do not need to rewrite your preferences sets. The preferences set for Nitesh should work just fine."
[16:16:04 CDT(-0500)] <kasper> hahaha
[16:16:17 CDT(-0500)] <colinclark> February 20 (or 21st in your timezone), 2013 from me to Christophe, in case you want to find it yourself
[16:16:26 CDT(-0500)] <kasper> well - I guess he might be able to tell us whether it actually works then
[16:16:56 CDT(-0500)] <colinclark> Here's the mistaken assumption I made
[16:17:09 CDT(-0500)] <colinclark> Me: "Again, there is no need to change anything on your part. Presumably, at this point, you've had lots of time to test your Matchmaker implementation and test profiles with the 0.1 system and it's working nicely, which is great."
[16:17:32 CDT(-0500)] <colinclark> Which, given the fact that you're desperately trying to make the RBMM work only now, was clearly not the case at the time
[16:17:59 CDT(-0500)] <colinclark> But this is what worries me a bit about seeing these preferences sets… are they consistent with what the Statistical MM is expecting?
[16:18:02 CDT(-0500)] <colinclark> I suspect not?
[16:18:42 CDT(-0500)] <colinclark> I'm trying to think through how ontologization fits into all of this
[16:19:01 CDT(-0500)] <kasper> I think that I at some point told Andy that he should use the format that I have in my example NPs, but not sure
[16:19:13 CDT(-0500)] <colinclark> Presumably you need to do an initial transformation of app-specific to common prior to ontologization...
[16:19:33 CDT(-0500)] <kasper> well, we have a general problem with ontologization
[16:19:37 CDT(-0500)] <colinclark> And as part of that conversion, presumably we should also be "repackaging" the application-specific preferences that remain after the transformation
[16:19:47 CDT(-0500)] <kasper> in that it doesn't allow us to pass around important info like context and source
[16:20:03 CDT(-0500)] <colinclark> We don't support context or source currently, do we?
[16:20:20 CDT(-0500)] <kasper> no - but it's impossible to do with the current ontologized format
[16:20:54 CDT(-0500)] <colinclark> Right but, well, so what?
[16:20:54 CDT(-0500)] <colinclark>
[16:21:18 CDT(-0500)] <kasper> haha, ok point taken
[16:21:27 CDT(-0500)] <colinclark> I guess the key point with "ontologization" is that it represents what I think is a critical step in the process of "understanding a preferences set"
[16:21:33 CDT(-0500)] <colinclark> I don't know why I'm randomly using quotations marks
[16:21:41 CDT(-0500)] <colinclark> So, I'll try to back up
[16:21:43 CDT(-0500)] <colinclark> feel free to nod off
[16:21:45 CDT(-0500)] <colinclark> or go cook
[16:22:08 CDT(-0500)] <kasper> I've already turned on the oven so I can through a pizza in there (like any other proud computer nerd)
[16:22:23 CDT(-0500)] <colinclark> In an ideal world, perhaps, preferences could actually be represented in the preferences set in a variety of "ontological formats"
[16:22:43 CDT(-0500)] <colinclark> Perhaps that's a dangerous assumption, but I think it's one we debated a lot during those phone calls with yzen and Bosmon
[16:22:57 CDT(-0500)] <colinclark> Which I am now acutely regretting having not summarized properly
[16:23:21 CDT(-0500)] <colinclark> Meaning, we can imagine that the user's sets can mix up preferences from different ontologies
[16:23:24 CDT(-0500)] <colinclark> but anyway, regardless of that
[16:23:30 CDT(-0500)] <colinclark> simplifying for a second
[16:24:11 CDT(-0500)] <colinclark> in the way that the Flatists love, but I think is rather problematic, we can imagine that all settings are really just term name/value pairs
[16:24:15 CDT(-0500)] <colinclark> i.e. they're flat
[16:24:27 CDT(-0500)] <colinclark> they have some unique identifier that identifies them as "some term"
[16:24:50 CDT(-0500)] <colinclark> i.e. in the format Christophe has written out for Nitesh
[16:25:10 CDT(-0500)] <colinclark> We will assume that the Common Terms Registry defines some set of conventions for how terms are "named"
[16:25:13 CDT(-0500)] <Bosmon> Yes
[16:25:19 CDT(-0500)] <colinclark> like 'em or not, I think this is pragmatic:
[16:25:33 CDT(-0500)] <Bosmon> In the ultimately iterated form of this insanity, these "names" will simply consist of a bunch of hex digits forming a GUID : P
[16:25:40 CDT(-0500)] <colinclark>
[16:25:53 CDT(-0500)] <Bosmon> Since clearly we will in the end one day run out of distinct and unique "terms" to form the left hand side
[16:26:20 CDT(-0500)] <colinclark> 1. There is a root that represents "the registry in which these are housed" (while many imagine that there is only "One CTR to rule them all", we may as well architect for many)
[16:27:08 CDT(-0500)] <colinclark> 2. There is a namespace distinguishing the "domain to which the term belongs" (i.e. "common" or "<insert your application id here>")
[16:27:38 CDT(-0500)] <colinclark> 3. The term has a name that actually means something
[16:28:04 CDT(-0500)] <colinclark> I've intentionally omitted one practically from our current "term URIs"
[16:28:26 CDT(-0500)] <colinclark> the portion of the hierarchy that distinguishes between common and application-specific terms
[16:28:46 CDT(-0500)] <colinclark> only because I need to think through what the consequences are of promoting a term from app-specific to common
[16:29:34 CDT(-0500)] <colinclark> If it were as simple as "this term is now designated common," we presumably wouldn't want to have to change the term's URI just for this case
[16:29:39 CDT(-0500)] <colinclark> anyway
[16:29:49 CDT(-0500)] <colinclark> term id, value
[16:30:11 CDT(-0500)] <colinclark> So then what's the meaning of the ontologization process?
[16:30:25 CDT(-0500)] <Bosmon> colinclark - which process in particular?
[16:30:31 CDT(-0500)] <Bosmon> Or rather - whose, and when?
[16:30:47 CDT(-0500)] <colinclark> I was thinking in general, to begin with
[16:31:09 CDT(-0500)] <colinclark> Despite Kasper's protestations, I think we've come to the point where we agree that even flatness is a kind of ontology
[16:31:16 CDT(-0500)] <Bosmon> It is
[16:31:39 CDT(-0500)] <colinclark> But still, there is a process of "translating" or "reconstituting" a preferences set
[16:31:43 CDT(-0500)] <colinclark> from one ontology to another
[16:31:54 CDT(-0500)] <Bosmon> Yes, there always is
[16:32:04 CDT(-0500)] <colinclark> and we more or less assume that matchmakers will lean on a PARTICULAR ontology in order to do its work effectively
[16:32:13 CDT(-0500)] <Bosmon> Yes
[16:32:34 CDT(-0500)] <colinclark> So, then, it's somewhat implicit...
[16:32:37 CDT(-0500)] <colinclark> in our minds
[16:32:41 CDT(-0500)] <colinclark> but it should not be
[16:32:44 CDT(-0500)] <Bosmon> ok
[16:32:45 CDT(-0500)] <colinclark> and it certainly isn't in our code
[16:32:54 CDT(-0500)] <Bosmon> But what, particularly, was the thing you were asking what the meaning of was?
[16:33:00 CDT(-0500)] <colinclark> that it is a Matchmaker's responsibility to specify a preferred ontology
[16:33:03 CDT(-0500)] <Bosmon> Ah
[16:33:06 CDT(-0500)] <colinclark> this process
[16:33:11 CDT(-0500)] <colinclark> I'm just thinking aloud
[16:33:14 CDT(-0500)] <colinclark> it must be incredibly annoying
[16:33:23 CDT(-0500)] <colinclark> kasper: Is that correct, in your mind?
[16:33:28 CDT(-0500)] <Bosmon> I guess you could say that it's its responsibility
[16:33:36 CDT(-0500)] <colinclark> First, that there are multiple ontologies in our ecosystem
[16:33:38 CDT(-0500)] <Bosmon> But it is only because of its requirement for its own convenience : P
[16:33:39 CDT(-0500)] <kasper> yeah - I agree
[16:33:47 CDT(-0500)] <colinclark> Second, that a Matchmaker will likely bind to a particular ontology
[16:33:56 CDT(-0500)] <kasper> yes, I very much agree
[16:34:09 CDT(-0500)] <colinclark> Third, a Matchmaker should declare to the system, in configuration, which ontology it is bound to
[16:34:16 CDT(-0500)] <colinclark> I have leaped ahead somewhat with this third point
[16:34:16 CDT(-0500)] <Bosmon> colinclark - as per the "ecosystem" presentation, the matchmaker may be able to go about its business without necessarily requiring a common ontology
[16:34:36 CDT(-0500)] <kasper> colinclark: I'm not sure about the third point
[16:34:36 CDT(-0500)] <Bosmon> It seems implausible, given the kinds of matchmakers which have been proposed so far
[16:34:38 CDT(-0500)] <colinclark> yzen: We are delightfully rehashing our ontology conversations here, in case you are curious to read the logs
[16:34:50 CDT(-0500)] <colinclark> Bosmon: Can you elaborate on that last point
[16:34:54 CDT(-0500)] <yzen> colinclark: will take a look
[16:34:57 CDT(-0500)] <colinclark> and then, kasper, we'll cycle around to mine
[16:35:05 CDT(-0500)] <Bosmon> But I tried to distil in my presentation the things that "an ontology might be good for", at least from the point of view of the "canopy matchmaker" which was the only non-trivial one we had at that point
[16:35:22 CDT(-0500)] <Bosmon> What that matchmaker really wanted was a METRIC, not really an ONTOLOGY
[16:35:22 CDT(-0500)] <colinclark> So, this is worth summarizing...
[16:35:30 CDT(-0500)] <Bosmon> But we were using the ontology as a convenient way of inducing a metric
[16:35:51 CDT(-0500)] <Bosmon> So far I don't see that anyone has picked up this idea and run with it
[16:36:06 CDT(-0500)] <Bosmon> Either from the point of view of declaring it desirable, or undesirable
[16:36:26 CDT(-0500)] <colinclark> Ridiculously generally, and too vaguely: "An Ontology provides a means by which a Matchmaker may better understand a user's needs and the solutions available, in order to more accurately make a match in ambiguous situations"
[16:36:30 CDT(-0500)] <colinclark> Am I in the ballpark?
[16:36:43 CDT(-0500)] <Bosmon> colinclark - something like that, yes
[16:36:53 CDT(-0500)] <colinclark> ok
[16:36:59 CDT(-0500)] <Bosmon> You might want to say something like "understand the relationship between the solutions available"
[16:37:07 CDT(-0500)] <Bosmon> But this is most likely implicit in your original statement
[16:37:51 CDT(-0500)] <colinclark> An Ontology provides a means by which a Matchmaker may better understand a user's needs and the relationship between the available solutions, in order to more accurately make a match."
[16:37:52 CDT(-0500)] <Bosmon> And you could also say "An ontology is ONE means by which etc. " : P
[16:38:06 CDT(-0500)] <colinclark> kasper, yzen: Can you get behind this summary of the purpose of an ontology?
[16:38:08 CDT(-0500)] <colinclark> Bosmon: yes, good point
[16:39:13 CDT(-0500)] <colinclark> I guess the next question, while I'm waiting is, "What is an ontology specifically in the architecture?"
[16:39:14 CDT(-0500)] <kasper> colinclark: yeah, that sounds very reasonable to me
[16:39:26 CDT(-0500)] <colinclark> And I guess that addresses your point about "a metric"
[16:39:43 CDT(-0500)] <colinclark> An ontology, today, is specifically a "categorization scheme" for a set of "terms"
[16:40:12 CDT(-0500)] <colinclark> Where a "categorization scheme" is, more specifically, a particular JSON hierarchy
[16:40:20 CDT(-0500)] <colinclark> Is that even vaguely correct?
[16:41:42 CDT(-0500)] <colinclark> silence means yes?
[16:42:05 CDT(-0500)] <kasper> colinclark: yeah, I think that's correct.. I'm not sure if it might be more than that (ie. some implicitly stated relation between different categories, not experessed in the JSON hierarchY)
[16:42:46 CDT(-0500)] <kasper> ok, that sounded less nonsensical in my head
[16:43:02 CDT(-0500)] <colinclark> yeah, I think Bosmon's point about the canopy matchmaker's need for a "proximity metric" suggests that there's more to it than just an explicit categorization scheme
[16:43:25 CDT(-0500)] <colinclark> I guess the thing is that we can't do much to formalize any kind of implicit relationships
[16:43:50 CDT(-0500)] <colinclark> anyway
[16:43:55 CDT(-0500)] <Bosmon> Yes
[16:44:04 CDT(-0500)] <colinclark> I guess we should unpack this assumption at some point...
[16:44:31 CDT(-0500)] <colinclark> but is anyone particularly troubled by the notion that an Ontology is essentially a particular "schema" for representing preferences?
[16:44:41 CDT(-0500)] <Bosmon> I believe the underlying points are something like, "i) we shouldn't regard any one categorization scheme as primary, and ii) we shouldn't attempt to constrain what the purpose of the categorization scheme actually is"
[16:45:07 CDT(-0500)] <colinclark> That's a very good summary, yes!
[16:45:16 CDT(-0500)] <Bosmon> colinclark - I'm troubled by the term "schema"
[16:45:23 CDT(-0500)] <Bosmon> Which implies that it actually is a schema : P
[16:45:55 CDT(-0500)] <colinclark> Those are our goals, in terms of why we introduced a formal notion of ontology into the system
[16:45:57 CDT(-0500)] <colinclark> yes, okay
[16:46:03 CDT(-0500)] <colinclark> so why is that troubling?
[16:46:06 CDT(-0500)] <Bosmon> In theory we have a "schema" already
[16:46:11 CDT(-0500)] <colinclark> what is it?
[16:46:19 CDT(-0500)] <Bosmon> That is, we could say that all ontologies we support conform to the same "schema"
[16:46:26 CDT(-0500)] <Bosmon> But I'm not entirely sure what it is
[16:46:29 CDT(-0500)] <Bosmon> Since we have not written it yet
[16:46:40 CDT(-0500)] <colinclark> what would this schema entail?
[16:46:52 CDT(-0500)] <colinclark> I mean, what would distinguish it, as a schema, from any ontology?
[16:47:18 CDT(-0500)] <Bosmon> But now I am thinking through the point that "an ontology can be anything within reach of the model transformations system" I am starting to see what you meant when you said that "an ontology is a schema"
[16:47:37 CDT(-0500)] <Bosmon> But I think it is more than just A schema......
[16:47:50 CDT(-0500)] <Bosmon> That is, you could say, every ontology induces a schema
[16:47:53 CDT(-0500)] <Bosmon> But not vice versa
[16:48:06 CDT(-0500)] <colinclark> curious
[16:48:22 CDT(-0500)] <colinclark> I guess you lead us naturally into the next point
[16:48:27 CDT(-0500)] <Bosmon> There's the core point that we can't say what any individual ontology actually IS until we have drawn up a model transformation document connecting it to another ontology
[16:48:39 CDT(-0500)] <Bosmon> only at THAT point does it actually become an ontology
[16:48:46 CDT(-0500)] <colinclark> lol
[16:48:49 CDT(-0500)] <Bosmon> So in that sense it isn't entirely "schema-like"
[16:48:58 CDT(-0500)] <Bosmon> Since you can write schemas for ANYTHING, whether they mean anything or not : P
[16:49:04 CDT(-0500)] <colinclark> Reminds me a bit of Wittgenstein's comments on the impossibility of a "private language"
[16:49:10 CDT(-0500)] <Bosmon> AND, you can write schemas for many things which are not ontologies
[16:49:12 CDT(-0500)] <colinclark> which I am only just puzzling over now
[16:50:19 CDT(-0500)] <colinclark> So, this moves us to the next point, which I think you're arguing is essential to the notion of "being an Ontology"
[16:50:25 CDT(-0500)] <colinclark> which is that an Ontology:
[16:50:40 CDT(-0500)] <colinclark> 1. Is a particular structure or categorization scheme for terms in a preferences set
[16:50:49 CDT(-0500)] <kasper> wittgenstein and strange loops.. this is turning into a hairy 12am discussion
[16:51:04 CDT(-0500)] <colinclark> 2. Is accompanied by a set of rules to transform it into some other ontology
[16:51:19 CDT(-0500)] <Bosmon> colinclark - I think we might need to elaborate 1. a bit
[16:51:33 CDT(-0500)] <colinclark> Do you care to do that now?
[16:51:37 CDT(-0500)] <Bosmon> Since I think we saw from our use of the "A4A ontology" that it does more than just categorizing the TERMS
[16:51:42 CDT(-0500)] <colinclark> how so?
[16:51:52 CDT(-0500)] <Bosmon> It actually constrains the form of entire documents which use the terms in a preferences set
[16:52:14 CDT(-0500)] <Bosmon> At least, our particular use of the A4A ontology did this
[16:52:41 CDT(-0500)] <colinclark> I don't fully understand
[16:52:46 CDT(-0500)] <colinclark> kasper: I'm sorry to drag you through this so late
[16:53:19 CDT(-0500)] <kasper> hehe, no problem
[16:53:24 CDT(-0500)] <Bosmon> If an ontology just did 1. as written there, we would be able to just say, "a preferences set consists of a set of key/value pairs, where keys are taken from the ontology's terms, and values take an ontology-specific form dependent on the "type" of the key"
[16:53:36 CDT(-0500)] <colinclark> This'll be hugely helpful for our writing this week anyway
[16:53:56 CDT(-0500)] <Bosmon> Whereas this isn't enough to define how prefs documents from the "A4A ontology" actually work(ed)
[16:54:12 CDT(-0500)] <Bosmon> That ontology allowed us to use what you could call "deep keys"
[16:54:12 CDT(-0500)] <colinclark> How os?
[16:54:28 CDT(-0500)] <kasper> colinclark: yeah, definitely! And it's something that will be useful to have discussed pre our upcoming discussions on model transformations, matchmaker flows, etc
[16:54:33 CDT(-0500)] <Bosmon> And you could argue that having abolished these, we should have gone some way to appeasing the "flat-earthers"
[16:54:44 CDT(-0500)] <colinclark> What's a deep key?
[16:55:00 CDT(-0500)] <Bosmon> A key whose segments are embedded into the JSON document forming the pref set itself
[16:55:10 CDT(-0500)] <Bosmon> Rather than one which is flattened into a single string appearing as a JSON key
[16:55:31 CDT(-0500)] <colinclark> Why am I confused?
[16:55:55 CDT(-0500)] <Bosmon> Well, you may be confused because I am completely wrong, and describing something which never existed
[16:56:02 CDT(-0500)] <Bosmon> Let me see if I can find one of these documents....
[16:56:04 CDT(-0500)] <colinclark> yes
[16:56:28 CDT(-0500)] <colinclark> https://github.com/GPII/universal/blob/master/testData/preferences/carla_24751.json
[16:56:44 CDT(-0500)] <colinclark> Carla may well be our only remaining 24751-based persona
[16:56:52 CDT(-0500)] <Bosmon> Ah yes
[16:56:53 CDT(-0500)] <Bosmon> There we go
[16:57:00 CDT(-0500)] <Bosmon> We have "display" as one key segment
[16:57:12 CDT(-0500)] <Bosmon> And then "screenEnhancement" as the next one
[16:57:13 CDT(-0500)] <Bosmon> etc.
[16:57:17 CDT(-0500)] <colinclark> Mikel Vargas represents a flat alternative: https://github.com/GPII/universal/blob/master/testData/preferences/MikelVargas.json
[16:57:32 CDT(-0500)] <Bosmon> So it's clear that there is more to the "A4A ontology" that simply talking about what keys there are, and how they are organised
[16:57:45 CDT(-0500)] <Bosmon> It also talks about the actual structure of preferences sets expressed relative to it
[16:57:50 CDT(-0500)] <Bosmon> that -> than
[16:58:05 CDT(-0500)] <colinclark> isn't the point that "display" and "screenEnhancement" represents a categorization of preferences?
[16:58:13 CDT(-0500)] <Bosmon> colinclark - yes, they do
[16:58:49 CDT(-0500)] <Bosmon> But there's no reason why they mightn't have represented that categorisation, but that the prefs set consisted of "flat keys" of the form "display.screenEnhancement": { ........
[16:59:07 CDT(-0500)] <colinclark> ah yes
[16:59:22 CDT(-0500)] <colinclark> so, let's clarify this distinction
[16:59:33 CDT(-0500)] <Bosmon> So in this case the "ontology" does more than just talking about the "structure or categorization scheme for terms"
[16:59:45 CDT(-0500)] <Bosmon> It does indeed induce a particular "schema" onto the prefs documents
[17:00:05 CDT(-0500)] <colinclark> So then would you allow me to broaden my definition?
[17:00:08 CDT(-0500)] <Bosmon> yes
[17:00:30 CDT(-0500)] <Bosmon> To be honest, I'm not sure that this ontology even IS within the reach of the model transformations system - at least in terms of the expanders we've written so far : P
[17:00:38 CDT(-0500)] <colinclark> And simply say that an #1 for an Ontology is that "An Ontology is a particular schema for terms in a preferences set"?
[17:01:01 CDT(-0500)] <Bosmon> I think that's the kind of broadening I'm suspicious of
[17:01:17 CDT(-0500)] <colinclark> And yet it appears to be, at least sometimes, the case, no?
[17:01:27 CDT(-0500)] <Bosmon> Yes, it is
[17:01:28 CDT(-0500)] <colinclark> my comma usage is out of control
[17:01:33 CDT(-0500)] <Bosmon> But I think that it can't replace the #1 which you wrote already
[17:01:50 CDT(-0500)] <kasper> colinclark: lol
[17:01:55 CDT(-0500)] <Bosmon> My preferred broadening would be to leave your #1 as written
[17:02:01 CDT(-0500)] <colinclark> with no changes/additions?
[17:02:14 CDT(-0500)] <Bosmon> And add a completely separate point, "#1a - An ontology also induces a particular schema on preferences documents expressed relative to the ontology"
[17:03:00 CDT(-0500)] <colinclark> kasper, yzen: Does that seem like a reasonable description of an Ontology, at least in our current conception of it?
[17:03:13 CDT(-0500)] <colinclark> that is: 1, 1a, and 2
[17:04:00 CDT(-0500)] <colinclark> i.e.
[17:04:02 CDT(-0500)] <colinclark> An Ontology is:
[17:04:15 CDT(-0500)] <colinclark> 1. A particular structure or categorization scheme for terms in a preferences set
[17:04:34 CDT(-0500)] <colinclark> 1a. Something that also induces a particular schema on preferences documents expressed relative to the ontology
[17:04:46 CDT(-0500)] <colinclark> 2. Accompanied by a set of rules to transform it into some other ontology
[17:05:15 CDT(-0500)] <colinclark> Assuming this is at least vaguely what we're thinking, then the next question becomes the nature of #2...
[17:05:48 CDT(-0500)] <kasper> colinclark: yeah, I think that sounds pretty reasonable
[17:06:03 CDT(-0500)] <colinclark> I imagine that it should be the responsibility of an ontology to fully translate itself into another ontology's representation
[17:06:05 CDT(-0500)] <yzen> colinclark: looks good
[17:06:44 CDT(-0500)] <kasper> colinclark: and another ontology could potentially be something as simple as the flat preferences?!
[17:06:51 CDT(-0500)] <colinclark> yes
[17:06:53 CDT(-0500)] <colinclark> exactly
[17:06:55 CDT(-0500)] <kasper> ok
[17:07:11 CDT(-0500)] <colinclark> So, Carla probably represents the closest example of what we think of as ISO 24751's "native tongue"
[17:07:42 CDT(-0500)] <colinclark> meaning, it consists of blocks of named categories into which certain common terms can be placed
[17:07:55 CDT(-0500)] <colinclark> as well as essentially arbitrarily-located "applications" blocks
[17:08:12 CDT(-0500)] <Bosmon> colinclark - it's hard to say that it is the responsibility of the ontology itself
[17:08:17 CDT(-0500)] <colinclark> yes
[17:08:21 CDT(-0500)] <colinclark> SOMEONE has to do it, though?
[17:08:24 CDT(-0500)] <colinclark> yes?
[17:08:26 CDT(-0500)] <Bosmon> With a slight abuse of meaning, it might be better to say that it is the responsibility "of the community managing the ontology"
[17:08:30 CDT(-0500)] <colinclark> sure, yes
[17:08:37 CDT(-0500)] <colinclark> I think that is a fine distinction to make
[17:08:46 CDT(-0500)] <colinclark> ok.
[17:08:49 CDT(-0500)] <Bosmon> That is, the community managing a set of ontologies has overall responsibiliy for ensuring there are "good enough" connections between them
[17:08:56 CDT(-0500)] <colinclark> Right
[17:08:57 CDT(-0500)] <colinclark> that makes sense
[17:09:02 CDT(-0500)] <Bosmon> We are building roads after all
[17:09:09 CDT(-0500)] <Bosmon> We need to make sure that there are "enough roads to get places"......
[17:09:22 CDT(-0500)] <colinclark> So if this represents an example of "the old ISO 24751ontology": https://github.com/GPII/universal/blob/master/testData/preferences/carla_24751.json
[17:09:41 CDT(-0500)] <kasper> colinclark, Bosmon: might be premature to bring this up now, but I think we're gonna hit some relatively tall walls when introducing sources and contexts to this whole thing... For example the common term "http://blabla/tracking", might be ontologized differently based on whether the context is a screen reader or magnifier
[17:10:02 CDT(-0500)] <Bosmon> kasper - naturally
[17:10:07 CDT(-0500)] <colinclark> Then Christophe's Nitesh is probably the best example of "the new flat ISO 24751 ontology": http://wiki.gpii.net/index.php/SmartHouses_Preference_Sets#Flat_Preference_Set_for_Nitesh
[17:10:12 CDT(-0500)] <Bosmon> Noone said that the rules translating between ontologies have to be lossless
[17:10:25 CDT(-0500)] <Bosmon> But this plays into the issue of "quality of invertibility" that we have been gradually kicking around
[17:10:26 CDT(-0500)] <colinclark> yep, you're right kasper
[17:10:34 CDT(-0500)] <colinclark> which is why I made the point about "we don't support it"
[17:10:39 CDT(-0500)] <Bosmon> And it also feeds into the question of "how many roads to build"
[17:10:46 CDT(-0500)] <colinclark> in that we haven't deeply considered the design for these features yet
[17:10:59 CDT(-0500)] <Bosmon> Where there are enough ontologies, and enough roads between them, some of the roads may be less lossless than others
[17:11:41 CDT(-0500)] <Bosmon> And if "some people" have persisted in designing ontologies that can't be reached by very many lossless roads, "some other people" may end up voting with their feet, and disusing their ontologies : P
[17:12:04 CDT(-0500)] <colinclark> kasper: Do you agree that Carla represents "the old 24751 ontology" well enough, and that Nitesh represents "the new 24751 flat ontology" well enough?
[17:13:21 CDT(-0500)] <kasper> colinclark: well enough?
[17:13:43 CDT(-0500)] <kasper> yeah, I do
[17:13:48 CDT(-0500)] <colinclark> Well, do you think they're accurate and good, these two preferences sets?
[17:13:53 CDT(-0500)] <colinclark> Okay, so
[17:13:55 CDT(-0500)] <colinclark>
[17:14:15 CDT(-0500)] <colinclark> I guess the problem we have now is "how do we translate from Nitesh's ontology into Carla's ontology?
[17:14:29 CDT(-0500)] <colinclark> Since the flat Matchmaker, for whatever reason, currently depends on it?
[17:15:09 CDT(-0500)] <colinclark> My sense is that we're converging on the idea that the Flat Matchmaker, given its context of use, probably shouldn't require it...
[17:15:28 CDT(-0500)] <kasper> colinclark: just to figure out whether I should jump out the window or not – are we talking pre pilot testing here, or?
[17:15:30 CDT(-0500)] <colinclark> which brings us to the point you made a while ago about what ontology the "capabilitiesTransformation" blocks should be expressed in
[17:15:36 CDT(-0500)] <colinclark> kasper: I dunno yet
[17:15:47 CDT(-0500)] <colinclark> I still don't even know what we're talking about, exactly
[17:16:00 CDT(-0500)] <kasper> haha - I'm glad I'm not the only one
[17:16:09 CDT(-0500)] <colinclark> The point being, I have no idea how to explain the issue to others or decide on the priority of a fix until I know the nature of the problem
[17:16:35 CDT(-0500)] <colinclark> All I know is that you've just created a whole pile of preferences sets that I think Christophe might get a bit upset by
[17:16:51 CDT(-0500)] <colinclark> And I figure we can easily say "this is what we need to do for the pilots"
[17:17:06 CDT(-0500)] <colinclark> if we can clearly articulate what exactly "this" is, why it's like this, and what it will be like after the pilots
[17:17:45 CDT(-0500)] <colinclark> I'm not looking at the code, but I'm assuming that there's nothing in the Flat Matchmaker that is actually "old ISO 24751 ontology"-specific
[17:18:14 CDT(-0500)] <colinclark> And that it's only the transformation stage that requires it, since our "capabilitiesTransformation" blocks have all been expressed in this ontology
[17:18:21 CDT(-0500)] <kasper> nope, to the best of my knowledge there isn't
[17:18:27 CDT(-0500)] <colinclark> ok
[17:18:29 CDT(-0500)] <colinclark> Anyway
[17:19:10 CDT(-0500)] <colinclark> What stops you from simply transforming a preferences set like Nitesh's into the old ISO 24751 format with your ad-hoc, pre-transformation phase of the RB MM?
[17:19:47 CDT(-0500)] <kasper> colinclark: not enough hours in the day
[17:19:52 CDT(-0500)] <colinclark> Ok
[17:19:54 CDT(-0500)] <colinclark> is that the only reason?
[17:20:26 CDT(-0500)] <kasper> colinclark: hehe, well no.. I think this would be more suitable to put in the Ontologizer®
[17:21:04 CDT(-0500)] <colinclark> I guess that's the point I'm trying to get at
[17:21:08 CDT(-0500)] <colinclark> Why do you think that?
[17:21:42 CDT(-0500)] <colinclark> It seems to me that there are three things, still, at play here:
[17:21:50 CDT(-0500)] <colinclark> 1. "New 24751" ontologized common terms
[17:22:15 CDT(-0500)] <colinclark> 2. "New 24751" ontologized app-specific terms
[17:22:24 CDT(-0500)] <colinclark> 3. Blocks of "just some stuff" settings
[17:22:57 CDT(-0500)] <colinclark> The Flat->Old 24751 ontology transformation takes care of #1
[17:23:03 CDT(-0500)] <kasper> and my NP sets are #3?
[17:23:21 CDT(-0500)] <colinclark> At the moment, nothing takes care of #2 except your ad-hoc process
[17:23:28 CDT(-0500)] <colinclark> And #3 should always just work
[17:23:47 CDT(-0500)] <colinclark> since nothing should ever be done with #3 except to "pass them on"
[17:24:05 CDT(-0500)] <kasper> colinclark: and what's the format of #3?
[17:24:15 CDT(-0500)] <colinclark> In fact, I believe the Flat->Old 24751 ontology transformation takes care of #3 already
[17:24:20 CDT(-0500)] <colinclark> The format that your terms are in
[17:24:27 CDT(-0500)] <kasper> ok
[17:24:30 CDT(-0500)] <colinclark> <app id>: <block of stuff>
[17:24:48 CDT(-0500)] <colinclark> So #1 is handled
[17:24:54 CDT(-0500)] <colinclark> #3, I belive, is handled
[17:24:59 CDT(-0500)] <colinclark> It's only #2 that needs to be handled
[17:25:03 CDT(-0500)] <kasper> yes
[17:25:16 CDT(-0500)] <Bosmon> What does #2 look like?
[17:25:28 CDT(-0500)] <kasper> Bosmon: very much like #3
[17:25:46 CDT(-0500)] <Bosmon> How very much like
[17:25:47 CDT(-0500)] <kasper> though in our current system, #3 are treated as a sort of alternative format of #2
[17:25:53 CDT(-0500)] <colinclark> #3 occurs by applying "inverse capabilitiesTransformations"
[17:26:26 CDT(-0500)] <kasper> Bosmon: like the com.aisquared.zoomtext line in christophes nitesh doc
[17:26:31 CDT(-0500)] <colinclark> kasper: I'm assuming you did it this way because your transformation from app-specific to common happens AFTER ontologization?
[17:26:51 CDT(-0500)] <kasper> "http://registry.gpii.org/applications/<APP_ID>.<SETTING>": [ ],
[17:26:53 CDT(-0500)] <colinclark> So, here's a question that would help my understand a lot
[17:26:59 CDT(-0500)] <colinclark> If I wrote a preference like this in my set:
[17:27:07 CDT(-0500)] <colinclark>
[17:27:21 CDT(-0500)] <colinclark> What would happen to it, were I to run it through the Ontologization process?
[17:27:30 CDT(-0500)] <kasper> it would just pass straight through, I believe
[17:27:37 CDT(-0500)] <colinclark> ok
[17:27:56 CDT(-0500)] <colinclark> so what technical reason was there to use #3 style preferences?
[17:27:59 CDT(-0500)] <colinclark> Instead of Nitesh-style?
[17:28:22 CDT(-0500)] <colinclark> I was imagining that the "foreign" term "farm" would just get stripped away
[17:28:30 CDT(-0500)] <colinclark> and thus you were working around that particular issue
[17:28:36 CDT(-0500)] <kasper> I think the problem with the ontologizer® right now is that it'll intepret: <APP_ID>.<SETTING> as the application id
[17:28:48 CDT(-0500)] <kasper> instead of an app_id/setting pair
[17:28:53 CDT(-0500)] <colinclark> I love the trademark registration
[17:29:11 CDT(-0500)] <colinclark> Can you give me an example?
[17:29:15 CDT(-0500)] <kasper> The reason for using #3, is because they in my mind represented non-registered terms
[17:29:48 CDT(-0500)] <colinclark> yes
[17:29:50 CDT(-0500)] <kasper> but I guess that's not necessarily the case
[17:30:10 CDT(-0500)] <kasper> colinclark: example:
[17:30:14 CDT(-0500)] <colinclark> Honestly, I think preferences like #2 are going to be rarer in practice than we imagine
[17:30:19 CDT(-0500)] <kasper> "http://registry.gpii.org/applications/com.aisquared.zoomtext.applicationPriority": [ ],
[17:30:32 CDT(-0500)] <colinclark> since I still don't see what incentive a vendor has to bother registering their terms
[17:30:50 CDT(-0500)] <kasper> would currently be understood as a block of settings for the application: "com.aisquared.zoomtext.applicationPriority"
[17:30:57 CDT(-0500)] <colinclark> ahhhh
[17:30:58 CDT(-0500)] <kasper> and the settings would be: 0
[17:31:07 CDT(-0500)] <colinclark> ok
[17:31:11 CDT(-0500)] <colinclark> let me have a look at the code to verify
[17:31:15 CDT(-0500)] <colinclark> since I saw that yzen slipped away
[17:31:18 CDT(-0500)] <kasper> prob. a relatively simple fix
[17:31:24 CDT(-0500)] <kasper> yeah, that sneaky russian
[17:31:26 CDT(-0500)] <colinclark> he wrote a specific expander for this, right?
[17:31:32 CDT(-0500)] <kasper> yeah
[17:32:01 CDT(-0500)] <colinclark> I think this is it: https://github.com/GPII/universal/blob/master/gpii/node_modules/ontologyServer/src/ontologyServerUtilities.js#L51-L67
[17:32:21 CDT(-0500)] <colinclark> How would we fix it?
[17:32:42 CDT(-0500)] <colinclark> Pretty hard to know when a dot represents the name of an app vs. the name of a term
[17:33:08 CDT(-0500)] <colinclark> I guess this might lead us back to my original enumeration
[17:33:15 CDT(-0500)] <kasper> yeah - I dont think it's fixable without changing the naming convention of #2 and #3
[17:33:18 CDT(-0500)] <colinclark> of "conventions for namespacing terms"
[17:33:22 CDT(-0500)] <colinclark> yes
[17:33:36 CDT(-0500)] <kasper> "http://registry.gpii.org/applications/com\\.aisquared\\.zoomtext.applicationPriority": [ ]
[17:33:38 CDT(-0500)] <kasper> would do it
[17:33:51 CDT(-0500)] <colinclark> Why would it?
[17:33:55 CDT(-0500)] <colinclark> escaped dots?
[17:33:58 CDT(-0500)] <colinclark> eek
[17:34:04 CDT(-0500)] <kasper> or "http://registry.gpii.org/applications/com.aisquared.zoomtext/applicationPriority": [ ]
[17:34:08 CDT(-0500)] <colinclark> yeah
[17:34:11 CDT(-0500)] <kasper> that's probably nicer
[17:34:12 CDT(-0500)] <kasper>
[17:34:27 CDT(-0500)] <colinclark> So we'd advocate, in the Registry working group, a "term namespacing schema"
[17:34:57 CDT(-0500)] <colinclark> <registry URL/<term type>/<optional intermediate identifier>/<term name>
[17:35:39 CDT(-0500)] <colinclark> where that awkward "optional intermediate identifier" was only there in the case of application-unique terms
[17:35:40 CDT(-0500)] <colinclark> and represented the application ID
[17:36:05 CDT(-0500)] <Bosmon> That's perfectly reasonable
[17:36:05 CDT(-0500)] <colinclark> And this would in fact represent the "flattened equivalent" to #3
[17:36:25 CDT(-0500)] <colinclark> ok
[17:36:40 CDT(-0500)] <colinclark> So it sounds like the next steps are:
[17:36:46 CDT(-0500)] <kasper> colinclark: makes sense to me
[17:36:51 CDT(-0500)] <colinclark> 1. Check in with the pilots folks and see what their preferences sets actually look like right now
[17:37:02 CDT(-0500)] <colinclark> 2. Check in with Andreas and find out what format his Matchmaker supports
[17:37:09 CDT(-0500)] <colinclark> if #1 and #2 are consistent with yours, we're all set, kasper
[17:37:20 CDT(-0500)] <colinclark> If not, we either need to convince everyone to switch to your format
[17:37:37 CDT(-0500)] <colinclark> or we need to fix the issue by having everyone tweak their format to include the extra slash, plus fix that expander
[17:37:39 CDT(-0500)] <colinclark> is that correct?
[17:37:51 CDT(-0500)] <kasper> yeah
[17:37:58 CDT(-0500)] <kasper> I can check in with andy tomorrow
[17:38:17 CDT(-0500)] <colinclark> ok
[17:38:18 CDT(-0500)] <kasper> dont think pilot folks have any problems with the switch
[17:38:34 CDT(-0500)] <colinclark> I guess michelled and yzen will have to update their NP Editing tool
[17:38:48 CDT(-0500)] <kasper> haha, yzen is gonna love that
[17:38:51 CDT(-0500)] <colinclark>
[17:39:04 CDT(-0500)] <colinclark> Okay, this is good
[17:39:12 CDT(-0500)] <colinclark> So, I will try to write up a summary of this conversation tomorrow
[17:39:24 CDT(-0500)] <kasper> that'd be awesome
[17:39:27 CDT(-0500)] <colinclark> I think we're going to have to prepare ourselves to broach the subject of the Registry URL Convention
[17:39:38 CDT(-0500)] <colinclark> which will of course be quite political, I assume
[17:40:04 CDT(-0500)] <colinclark> People might have, well, "concerns."
[17:40:35 CDT(-0500)] <colinclark> I guess, Bosmon, there is still a longer term question about the nature of an Ontology
[17:40:44 CDT(-0500)] <colinclark> I think this is already quite a radical notion...
[17:40:54 CDT(-0500)] <Bosmon> colinclark - a specific question?
[17:40:56 CDT(-0500)] <colinclark> that an Ontology simply consists of a particular data structure
[17:40:58 CDT(-0500)] <Bosmon> Or just questions about its acceptance
[17:41:08 CDT(-0500)] <colinclark> and the rules of its translation to other data structures
[17:41:22 CDT(-0500)] <colinclark> I can imagine that, for example, the Semantic Framework considers itself an "API"
[17:41:27 CDT(-0500)] <colinclark> a kind of "query API"
[17:41:28 CDT(-0500)] <Bosmon> colinclark - it already consists of more than the nature of a "schema"
[17:41:33 CDT(-0500)] <Bosmon> And people seem to find those unproblematic enough
[17:42:28 CDT(-0500)] <colinclark> Okay, let me approach this from another angle...
[17:42:31 CDT(-0500)] <colinclark> I'm a matchmaker
[17:42:56 CDT(-0500)] <colinclark> and I imagine that what I want is, given a preference set, for the ontology to tell me "what category of AT this preference most appropriately belongs to"
[17:43:24 CDT(-0500)] <colinclark> I imagine that I'd make some API call to some "ontology" somewhere, and it would tell me, for voice speed, "TEXT_TO_SPEECH_ENGINE"
[17:43:25 CDT(-0500)] <colinclark> or whatever
[17:44:01 CDT(-0500)] <colinclark> I guess these kinds of decisions belong within the realm of what we are calling the Matchmaker, still
[17:44:56 CDT(-0500)] <colinclark> I'm not sure I'm making any sense
[17:45:23 CDT(-0500)] <Bosmon> colinclark - some - but I guess the point is that the string "TEXT_TO_SPEECH_ENGINE" itself could only have meaning within some ontology or other
[17:45:39 CDT(-0500)] <colinclark> yes
[17:46:41 CDT(-0500)] <colinclark> So I guess my question is sort of "what do I DO with an ontology?"
[17:47:34 CDT(-0500)] <colinclark> and the answer currently is "you use an ontology's transformation to convert a user's preferences into a form that is meaningful in the ontology's 'worldview'"
[17:47:39 CDT(-0500)] <colinclark> now i'm nesting quotation marks
[17:47:48 CDT(-0500)] <colinclark> and then you do whatever you want to with it
[17:48:23 CDT(-0500)] <colinclark> So the other question would be, "why would I bother to write an ontology transformation and do all this work? Why wouldn't I just write some code that processed the preferences set however I wanted it to be, and then operate it on directly?"
[17:49:02 CDT(-0500)] <kasper> colinclark: I dont think it's unrealistic that some matchmakers would do that
[17:49:12 CDT(-0500)] <Bosmon> colinclark - wouldn't the answer "because it might not be expressed in the ontology you are expecting" be good enough?
[17:49:14 CDT(-0500)] <kasper> colinclark: simply take the preferences, perhaps prefiltered by us
[17:49:20 CDT(-0500)] <Bosmon> kasper - I think it is wholly unrealistic
[17:49:26 CDT(-0500)] <Bosmon> Even with the very small set of ontologies we have now
[17:49:52 CDT(-0500)] <colinclark> I guess part of the question with that, kasper, is "What ontology are THESE preferences in?"
[17:50:18 CDT(-0500)] <kasper> well - I think that's the original (and perhaps still standing) plan of the rulebased matchmaker was to grab the preferences from us
[17:50:28 CDT(-0500)] <kasper> apply rules, etc., based on their ontology
[17:50:37 CDT(-0500)] <kasper> and then hand us back a set of applications and settings
[17:50:39 CDT(-0500)] <colinclark> I think you're implicitly assuming that there will never be any preferences that aren't in the #1 or #2 form?
[17:51:11 CDT(-0500)] <colinclark> In the case you're describing, kasper, the RB MM is coded to a particular ontology, right?
[17:51:16 CDT(-0500)] <colinclark> "Common flat terms"
[17:51:23 CDT(-0500)] <kasper> colinclark: yes - any settings that the RB MM will be able to handle would then have to be in the flat format
[17:51:25 CDT(-0500)] <colinclark> presumably that's the way it could understand anything
[17:51:49 CDT(-0500)] <kasper> like our flat and canopy matchmaker only works for iso24751 preferences
[17:51:55 CDT(-0500)] <colinclark> and then that's also the "terminology" it would use for communication with the Semantic Framework or whatever it does
[17:52:06 CDT(-0500)] <kasper> colinclark: yes
[17:52:33 CDT(-0500)] <colinclark> well, i guess you proved Bosmon's point
[17:52:45 CDT(-0500)] <colinclark> since we essentially already have some kind of heterogeneity of preference sets
[17:52:50 CDT(-0500)] <colinclark> #1, #2, and #3
[17:52:59 CDT(-0500)] <colinclark> and the RB MM is really only equipped to contend with #1
[17:53:25 CDT(-0500)] <colinclark> and thus it needs to have the preferences set not only "ontologized" in the basic sense, but also "commonized"
[17:53:29 CDT(-0500)] <colinclark> everything-ized
[17:54:09 CDT(-0500)] <colinclark> In other words, the RB MM needs this process to happen because the preferences set "might not be expressed in the ontology [it is] expecting"
[17:54:55 CDT(-0500)] <kasper> Commonization process?
[17:55:01 CDT(-0500)] <colinclark> the thing you do for it
[17:55:10 CDT(-0500)] <colinclark> that you have been slaving over and working late to implement
[17:55:24 CDT(-0500)] <colinclark> and that you just emailed the list about, which caused me to launch into this whole discussion
[17:55:29 CDT(-0500)] <colinclark> rather than letting you eat in peace
[17:55:30 CDT(-0500)] <colinclark>
[17:55:39 CDT(-0500)] <kasper> well yes, but that in my mind is slightly different from ontologization
[17:55:44 CDT(-0500)] <kasper> and I know they're related
[17:55:55 CDT(-0500)] <kasper> but this is a matter of application specific vs. common terms
[17:55:59 CDT(-0500)] <colinclark> It certainly is, from a workflow perspective
[17:56:08 CDT(-0500)] <colinclark> though interestingly it's done using the exact same technical artifacts
[17:56:38 CDT(-0500)] <colinclark> I think they might be different, but with my eyes squinted it seems like just a more extreme case of ontologization
[17:56:43 CDT(-0500)] <kasper> yeah, I guess
[17:57:50 CDT(-0500)] <colinclark> I guess my point is that there is clearly a process whereby a preferences set gets converted (or not converted) into a "usable form"
[17:58:47 CDT(-0500)] <colinclark> From there, the Matchmaker is free to do what it will with the preferences set in order to produce a workable match for the user
[17:58:59 CDT(-0500)] <colinclark> including, say, consulting the Semantic Framework
[17:59:06 CDT(-0500)] <colinclark> or just whatever
[17:59:22 CDT(-0500)] <kasper> well - how about when I come along with my branch new fusion powered MatchMakerMax 2000 that understands #1 #2 and #3
[18:00:09 CDT(-0500)] <kasper> would that still require any ontologization before hand
[18:00:29 CDT(-0500)] <colinclark> I guess it depends if any "foreign formats" can ever get into the system
[18:00:31 CDT(-0500)] <kasper> or in other words, is it legal to have preferences stored in some ontologized manner that isn't #1 #2 or #3
[18:00:38 CDT(-0500)] <colinclark> yes, exactly
[18:00:50 CDT(-0500)] <colinclark> I think it's easy for Standards Types to simply say "absolutely not"
[18:00:59 CDT(-0500)] <kasper> cool
[18:01:01 CDT(-0500)] <colinclark> "Follow our rules or you can't play in the GPII sandbox"
[18:01:15 CDT(-0500)] <kasper> yay - we're king of the world
[18:01:16 CDT(-0500)] <colinclark> And I think Gregg and Gottfried and Liddy in particular would agree with that approach
[18:01:24 CDT(-0500)] <colinclark> But before you celebrate
[18:01:30 CDT(-0500)] <kasper> goddammit colin
[18:01:34 CDT(-0500)] <colinclark> I'm not sure it's necessarily the best solution
[18:01:38 CDT(-0500)] <colinclark> I mean, it's possible
[18:01:44 CDT(-0500)] <colinclark> and it's certainly a lot easier
[18:02:07 CDT(-0500)] <colinclark> But what if wanted to, say, provide interoperability with some existing preferences data store?
[18:02:14 CDT(-0500)] <colinclark> that used some other structure or format
[18:02:49 CDT(-0500)] <kasper> well - ok, so I agree we should be interoperable with other data stores, etc
[18:02:49 CDT(-0500)] <colinclark> What I think we've got with this "Ontology as translation" idiom is the ability to be more adaptable to diversity
[18:03:03 CDT(-0500)] <kasper> but at some point we need to have a known format to process in the system
[18:03:11 CDT(-0500)] <colinclark> You could equally well argue, I guess, that this is over engineering or YAGNI or something
[18:03:36 CDT(-0500)] <colinclark> Says the guy who added an extra format to the pilot process :PO
[18:04:11 CDT(-0500)] <colinclark> I mean, I guess this issue of ontology pushes on the notion of a "known format"
[18:04:31 CDT(-0500)] <colinclark> Clearly the definition of a "known format" is "we have a workable set of transformation rules for it"
[18:04:46 CDT(-0500)] <colinclark> in the case of the ontology server
[18:05:09 CDT(-0500)] <colinclark> It's slightly scary, but I think quite flexible and worthwhile
[18:05:30 CDT(-0500)] <colinclark> and leverages the basic infrastructure we already have
[18:05:41 CDT(-0500)] <kasper> so I think we pretty much agree - but perhaps differ in how integral part of the system the Ontologizer® is
[18:05:52 CDT(-0500)] <colinclark> how so?
[18:06:18 CDT(-0500)] <kasper> at least, once we hit the lifecycle manager - we need the datastructure passed to be in a certain format
[18:06:33 CDT(-0500)] <Bosmon> kasper - and what is that certain format?
[18:06:49 CDT(-0500)] <colinclark> yes, that's right
[18:06:58 CDT(-0500)] <colinclark> which, interestingly, is more or less "whatever format the application needs"
[18:07:14 CDT(-0500)] <kasper> Bosmon: basically the same as a solution registry entry, but with an added: "preferences" or "settings" block
[18:08:04 CDT(-0500)] <kasper> colinclark, Bosmon: damn, you're clever questions and observations are short-circuiting my brain
[18:08:16 CDT(-0500)] <colinclark> it's even late for me
[18:08:23 CDT(-0500)] <colinclark> we should call it quits
[18:08:37 CDT(-0500)] <colinclark> I guess the point isn't that ontologization is somehow "integral" in any hard-coded way
[18:08:37 CDT(-0500)] <kasper> I guess my point is, that if we decide on a specific format (or 3 variations of the format)
[18:08:56 CDT(-0500)] <kasper> we'll be able to provide a bunch of utility functions, services, etc., to handle them
[18:09:04 CDT(-0500)] <colinclark> Sure
[18:09:06 CDT(-0500)] <kasper> (prefs, that is)
[18:09:36 CDT(-0500)] <colinclark> But it doesn't prevent part of the system from wanting to have them in a very different format
[18:09:44 CDT(-0500)] <colinclark> and us wanting to accommodate that
[18:10:27 CDT(-0500)] <colinclark> The question, really, is if you want to offer those utility functions in a permanent form
[18:10:30 CDT(-0500)] <kasper> what part of the system would that be? matchmakers, or something else as well?
[18:10:51 CDT(-0500)] <colinclark> or whether you want someone else to be able to viably extend the system after you've retired to sail around the world
[18:11:11 CDT(-0500)] <colinclark> Matchmakers or "sources of preferences," primarily
[18:11:27 CDT(-0500)] <kasper> colinclark: we'll when I'm in my boat in the middle of the ocean, I no longer worry about these things
[18:11:36 CDT(-0500)] <colinclark> In other words, the stuff that we anticipate is most likely to be quite diverse
[18:11:58 CDT(-0500)] <colinclark> kasper: Cool, so you agree then
[18:12:07 CDT(-0500)] <colinclark> Anyway, it's late
[18:12:12 CDT(-0500)] <colinclark> I think this was extremely helpful
[18:12:16 CDT(-0500)] <kasper> ugh - yeah, I probably do agree
[18:12:59 CDT(-0500)] <colinclark> Let me know what Andy ays
[18:13:02 CDT(-0500)] <colinclark> says
[18:13:06 CDT(-0500)] <kasper> I guess my worry is that we're making life extraordinarily complicated for ourselves trying to accomodate everything .. but with an Ontologizer® in a suitable place, we're probably good
[18:13:16 CDT(-0500)] <kasper> and yeah, will do
[18:13:17 CDT(-0500)] <colinclark> Are we trying to accommodate everything?
[18:13:21 CDT(-0500)] <colinclark> I hope not
[18:13:35 CDT(-0500)] <colinclark> I hope we're just trying to make a system that can economically grow in the future
[18:13:38 CDT(-0500)] <kasper> hehe, no
[18:13:43 CDT(-0500)] <kasper> yeah, I agree
[18:13:48 CDT(-0500)] <colinclark> and one that is open enough that people can plug new shit into it
[18:13:57 CDT(-0500)] <colinclark> without us constantly having to be involved in the process
[18:14:19 CDT(-0500)] <kasper> yeah, you're right
[18:14:22 CDT(-0500)] <colinclark> More complicated now so it can be simpler later
[18:14:32 CDT(-0500)] <colinclark> My stupid money analogy...
[18:14:34 CDT(-0500)] <Bosmon> kasper - recall, as Gregg has recently advised us, "what we are building is forever" : P
[18:14:46 CDT(-0500)] <colinclark>
[18:14:49 CDT(-0500)] <colinclark> it's like saving up cash versus a credit card
[18:14:55 CDT(-0500)] <colinclark> takes a lot longer to save up the cash
[18:15:02 CDT(-0500)] <colinclark> but you pay interest every month on the credit card
[18:15:11 CDT(-0500)] <colinclark> or something stupid like that
[18:15:31 CDT(-0500)] <colinclark> Remind me never to use financial metaphors again
[18:15:36 CDT(-0500)] <Bosmon> We don't have the option, as Mozilla and Google do, to throw away their entire codebase every 8 years
[18:15:57 CDT(-0500)] <colinclark> If only we had a billion dollars to spend on GPII
[18:16:18 CDT(-0500)] <colinclark> Eventually, we'll have some TIGER TEAMS!
[18:16:19 CDT(-0500)] <kasper> hehe, my relationship with money and credit cards is to screwed so the analogy isn't saying much for me
[18:16:26 CDT(-0500)] <Bosmon> We'll have some WHAT?
[18:16:30 CDT(-0500)] <colinclark>
[18:16:34 CDT(-0500)] <Bosmon> Are those anything like TIGER MOMS? : P
[18:16:37 CDT(-0500)] <colinclark> I don't know
[18:16:39 CDT(-0500)] <kasper> yes, more TIGERs
[18:16:40 CDT(-0500)] <colinclark> what's a tiger mom?
[18:17:14 CDT(-0500)] <kasper> woman tiger with cubs?
[18:17:29 CDT(-0500)] <kasper>
[18:18:17 CDT(-0500)] <Bosmon> I believe they are some Asian thing
[18:18:28 CDT(-0500)] <colinclark> http://en.wikipedia.org/wiki/Battle_Hymn_of_the_Tiger_Mother
[18:19:22 CDT(-0500)] <thealphanerd> colinclark: hows it going
[18:19:38 CDT(-0500)] <colinclark> thealphanerd: Better now that you are here to break up our long and nerdy conversation
[18:19:47 CDT(-0500)] <thealphanerd> haha
[18:19:49 CDT(-0500)] <colinclark> kasper: Thanks again for staying up insanely late to talk this through with me
[18:20:00 CDT(-0500)] <colinclark> I'll write up a summary; you check with everyone about formats, and we should be cool
[18:20:15 CDT(-0500)] <kasper> colinclark: my pleasure.. it was a good conversation
[18:20:16 CDT(-0500)] <colinclark> thealphanerd: How's it going with you? How was your show this weekend?
[18:20:21 CDT(-0500)] <thealphanerd> it went great
[18:20:36 CDT(-0500)] <thealphanerd> I made a 10 channel mix for the second night
[18:20:42 CDT(-0500)] <thealphanerd> and did a bunch of funky spatialization
[18:20:44 CDT(-0500)] <colinclark> nice!
[18:21:01 CDT(-0500)] <colinclark> did you use some particular software? Or things you wrote yourself?
[18:21:04 CDT(-0500)] <colinclark> What did the music sound like?
[18:21:07 CDT(-0500)] <colinclark> beats?
[18:21:17 CDT(-0500)] <thealphanerd> beats + ambiance
[18:21:30 CDT(-0500)] <thealphanerd> do you remember the performance I did in december or so
[18:21:31 CDT(-0500)] <thealphanerd> ?
[18:21:34 CDT(-0500)] <thealphanerd> it is a revisiting
[18:21:38 CDT(-0500)] <kasper> colinclark, thealphanerd: going from one realm of nerdy conversation to another
[18:21:41 CDT(-0500)] <colinclark> lol
[18:21:49 CDT(-0500)] <colinclark> kasper: I know you like beats
[18:21:58 CDT(-0500)] <colinclark> did you go to that festival?
[18:22:00 CDT(-0500)] <colinclark> or is that later?
[18:22:07 CDT(-0500)] <colinclark> With Gui Borrato in it?
[18:22:24 CDT(-0500)] <kasper> I did - but being geneva it was expensive as hell, so only went out for one night
[18:23:09 CDT(-0500)] <kasper> and bailed to the reggae/dub scene once the techno music got out of hand
[18:23:21 CDT(-0500)] <kasper> it was alright though
[18:23:44 CDT(-0500)] <kasper> anyway, I'm gonna shut down for the night
[18:23:44 CDT(-0500)] <thealphanerd> techno step!
[18:23:51 CDT(-0500)] <colinclark> g'night, kasper
[18:24:03 CDT(-0500)] <kasper> night everyone
[18:24:21 CDT(-0500)] <colinclark> Did you use Live with your Monome to play the music, thealphanerd?
[18:24:22 CDT(-0500)] <thealphanerd> colinclark: any interest in trying to put something togetehr for dafx?
[18:24:31 CDT(-0500)] <thealphanerd> live + max4live + monome
[18:25:32 CDT(-0500)] <colinclark> This, thealphanerd? http://www.dafx.de/
[18:25:41 CDT(-0500)] <thealphanerd> yeah
[18:25:49 CDT(-0500)] <colinclark> Where is it in 2013?
[18:25:51 CDT(-0500)] <colinclark> and when?
[18:25:52 CDT(-0500)] <thealphanerd> Aparantly it is a fairly big deal conference for the people here
[18:25:54 CDT(-0500)] <thealphanerd> september
[18:25:57 CDT(-0500)] <thealphanerd> in ireland I think
[18:26:13 CDT(-0500)] <colinclark> ah, cool
[18:26:18 CDT(-0500)] <colinclark> I'll be in Portugal in September
[18:26:28 CDT(-0500)] <colinclark> so it might work to stay on that side of the atlantic for a few weeks
[18:26:36 CDT(-0500)] <colinclark> I'd be happy to do something. What did you have in mind?
[18:26:41 CDT(-0500)] <colinclark> Coauthor a paper?
[18:26:41 CDT(-0500)] <Bosmon> colinclark - if your CATT will tolerate it!
[18:26:42 CDT(-0500)] <thealphanerd> not 100%
[18:26:48 CDT(-0500)] <colinclark> yes
[18:26:53 CDT(-0500)] <thealphanerd> but I think the deadline is in a week?
[18:26:55 CDT(-0500)] <thealphanerd> CATT?
[18:27:00 CDT(-0500)] <colinclark> A lot of catless travel this summer
[18:27:05 CDT(-0500)] <colinclark> Three weeks in Boulder
[18:27:05 CDT(-0500)] <Bosmon> CATTLES
[18:27:16 CDT(-0500)] <colinclark> Another week in Ireland in July
[18:27:21 CDT(-0500)] <colinclark> Portugal in Sept
[18:27:23 CDT(-0500)] <colinclark> eek
[18:27:26 CDT(-0500)] <Bosmon> I'd forgotten about Ireland
[18:27:30 CDT(-0500)] <thealphanerd> oh like meow
[18:27:38 CDT(-0500)] <colinclark>
[18:27:38 CDT(-0500)] <thealphanerd> since it was all caps I figured it was an acronym
[18:27:49 CDT(-0500)] <thealphanerd> figured it was visa related
[18:27:56 CDT(-0500)] <thealphanerd> http://dafx13.nuim.ie/authors.html
[18:27:56 CDT(-0500)] <colinclark> Bosmon: I need to get that abstract written
[18:28:08 CDT(-0500)] <thealphanerd> 2 - 6 of September
[18:28:22 CDT(-0500)] <colinclark> When is AAATE? I can't remember
[18:28:50 CDT(-0500)] <colinclark> I wouldn't normally bother with something like this, but it's not often that you find conferences that are specifically calling for papers about "software for creating inclusive instruments"
[18:29:14 CDT(-0500)] <colinclark> AAATE is 19-22
[18:29:19 CDT(-0500)] <colinclark> so probably it wouldn't work to do both
[18:29:25 CDT(-0500)] <thealphanerd> colinclark: Computer music and languages for music signal processing
[18:29:33 CDT(-0500)] <thealphanerd> is something they are particularlly interested in
[18:29:36 CDT(-0500)] <colinclark> Cool
[18:29:38 CDT(-0500)] <thealphanerd> this year
[18:29:39 CDT(-0500)] <colinclark> Well, I tell you what
[18:29:43 CDT(-0500)] <colinclark> I'd be happy to coauthor something with
[18:29:53 CDT(-0500)] <colinclark> and if you want to attend, that'd be cool
[18:30:03 CDT(-0500)] <thealphanerd> which one is AAATE?
[18:30:29 CDT(-0500)] <thealphanerd> just googled
[18:30:29 CDT(-0500)] <thealphanerd> neat
[18:30:55 CDT(-0500)] <colinclark> Wow, they want a full paper by this weekend
[18:31:01 CDT(-0500)] <colinclark> intense
[18:31:06 CDT(-0500)] <thealphanerd> yeah I know
[18:31:11 CDT(-0500)] <thealphanerd> just found out about it from some people
[18:31:14 CDT(-0500)] <thealphanerd> might be a little bit tight
[18:31:19 CDT(-0500)] <thealphanerd> this is one Julius like to go top
[18:31:25 CDT(-0500)] <colinclark> no wonder
[18:31:35 CDT(-0500)] <colinclark> He's probably like a rockstar at a conference like this
[18:31:56 CDT(-0500)] <colinclark> Ah, it's Victor Lazzarini organizing it
[18:32:17 CDT(-0500)] <colinclark> I swear by his chapter in The Audio Programming Book
[18:32:50 CDT(-0500)] <colinclark> he's a CSound guy
[18:33:00 CDT(-0500)] <thealphanerd> ahhh neat
[18:33:34 CDT(-0500)] <thealphanerd> would you be interested in trying to do a poster ?
[18:34:07 CDT(-0500)] <thealphanerd> I guess what would be a good topic… an introduction to Flocking?
[18:34:30 CDT(-0500)] <thealphanerd> also I'm going to be working this quarter on a faust -> flocking ugen architecture file
[18:35:00 CDT(-0500)] <colinclark> Oh great!
[18:35:04 CDT(-0500)] <colinclark> I was just looking into that this weekend
[18:35:22 CDT(-0500)] <colinclark> it looks like it should be quite straightforward, if I was reading the other architecture files correctly
[18:35:37 CDT(-0500)] <colinclark> I guess the UI stuff will be a little bit more complex, but probably still doable
[18:36:22 CDT(-0500)] <colinclark> My impression is that Faust emits a function containing the source code of your dap algorithm...
[18:36:25 CDT(-0500)] <colinclark> dsp
[18:36:41 CDT(-0500)] <colinclark> and then you write a "template" with some special <<instructions>> on where it should emit this code
[18:36:50 CDT(-0500)] <colinclark> Is that vaguely correct?
[18:39:07 CDT(-0500)] <thealphanerd> I'm not 100%
[18:39:16 CDT(-0500)] <thealphanerd> have not yet had a chance to look at it in depth
[18:39:24 CDT(-0500)] <thealphanerd> julius is doing another faust workshop tomorrow
[18:39:32 CDT(-0500)] <thealphanerd> hopefully I'll get a chance to meet with him some time soon
[18:40:33 CDT(-0500)] <thealphanerd> so colinclark do you think it is unreasonable to try and get something together for DAFX this weekend?
[18:40:52 CDT(-0500)] <colinclark> kasper misses us
[18:41:02 CDT(-0500)] <colinclark> I could probably write a bit for a paper if you needed it
[18:41:06 CDT(-0500)] <colinclark> or help with a poster
[18:41:24 CDT(-0500)] <thealphanerd> they said a 4 page paper for poster submissions
[18:41:29 CDT(-0500)] <thealphanerd> I think that is what it said
[18:41:37 CDT(-0500)] <colinclark> I do have three papers due next Monday, but I could write something
[18:41:43 CDT(-0500)] <thealphanerd> maybe you could come up with some talking points
[18:41:46 CDT(-0500)] <thealphanerd> and I could fluff it up
[18:41:47 CDT(-0500)] <thealphanerd> ?
[18:41:50 CDT(-0500)] <colinclark> yup, that's fine
[18:42:03 CDT(-0500)] <colinclark> if you can refine a topic, I'll draft some stuff
[18:42:32 CDT(-0500)] <thealphanerd> Well I guess the first idea would be "what about flocking is novel and worth discussing
[18:42:33 CDT(-0500)] <thealphanerd> "
[18:43:08 CDT(-0500)] <colinclark>
[18:43:43 CDT(-0500)] <thealphanerd> smiley face… got it
[18:43:57 CDT(-0500)] <thealphanerd> So the fact it is in the browser is something
[18:44:10 CDT(-0500)] <thealphanerd> the way in which synth defs are made is another
[18:44:20 CDT(-0500)] <colinclark> Yup
[18:44:28 CDT(-0500)] <thealphanerd> it running on node.js
[18:44:33 CDT(-0500)] <thealphanerd> so that it is both a server / client
[18:44:41 CDT(-0500)] <colinclark> In-browser, cross-browser, and Node.js are all good points
[18:45:01 CDT(-0500)] <thealphanerd> So maybe "An Introduction to the Flocking synthesis language" ?
[18:45:25 CDT(-0500)] <colinclark> "framework" or "environment" may be a better term
[18:45:33 CDT(-0500)] <thealphanerd> ahhh
[18:45:33 CDT(-0500)] <colinclark> since Flocking isn't quite a language yet
[18:45:35 CDT(-0500)] <thealphanerd> cool beans
[18:45:38 CDT(-0500)] <thealphanerd> framework
[18:45:39 CDT(-0500)] <thealphanerd>
[18:45:54 CDT(-0500)] <colinclark> seems cool to me
[18:46:42 CDT(-0500)] <colinclark> Declarative synth defs, which mean that it is intended to bridge the gap between the dataflow-oriented, graphical environments like Max and text-oriented environments like SuperCollider
[18:47:23 CDT(-0500)] <thealphanerd> We could talk about challenges
[18:47:28 CDT(-0500)] <colinclark> And then of course, the web-based angle, which means that it has access to all of the skill sets of web developers
[18:47:33 CDT(-0500)] <thealphanerd> such as how to write a sample accurate scheduler with js
[18:47:34 CDT(-0500)] <colinclark> Super easy to build UIs
[18:47:44 CDT(-0500)] <colinclark> easy to embed and connect with other code, web services, etc.
[18:47:51 CDT(-0500)] <colinclark> yes, challenges
[18:48:01 CDT(-0500)] <colinclark> "realtime-ready code in JavaScript is hard"
[18:48:13 CDT(-0500)] <thealphanerd> we could talk about how using js / web technologies makes for an interesting development path
[18:48:19 CDT(-0500)] <colinclark> The specs are still shifting underneath us
[18:48:29 CDT(-0500)] <colinclark> I think that's probably the really exciting part of flocking right now
[18:48:33 CDT(-0500)] <thealphanerd> many things that an environment needs to develop is already available
[18:48:39 CDT(-0500)] <colinclark> yes, exactly
[18:48:41 CDT(-0500)] <thealphanerd> such as the thing with osc
[18:48:57 CDT(-0500)] <thealphanerd> so rather than implementing osc we think of higher level abstractions to the implementation process
[18:49:07 CDT(-0500)] <colinclark> rather than a dedicated DSP language such as SuperCollider or ChucK, there's a really robust, professional-level set of tools available
[18:49:23 CDT(-0500)] <colinclark> libraries, frameworks, debugging tools
[18:49:28 CDT(-0500)] <colinclark> etc.
[18:49:35 CDT(-0500)] <colinclark> It's easy to build UIs alongside it
[18:49:48 CDT(-0500)] <thealphanerd> seems like we have enough for a paper
[18:49:49 CDT(-0500)] <thealphanerd> hehe
[18:49:56 CDT(-0500)] <thealphanerd> I have time this week to work on it
[18:49:56 CDT(-0500)] <colinclark> JavaScript is extremely portable, as shown by the fact that we ported it to Node.js in a matter of a few days
[18:49:57 CDT(-0500)] <colinclark> etc.
[18:49:58 CDT(-0500)] <colinclark> ypu
[18:49:59 CDT(-0500)] <colinclark> okay
[18:50:05 CDT(-0500)] <thealphanerd> if you can give me a good framwork to start with
[18:50:14 CDT(-0500)] <thealphanerd> so that I frame it the way you would like it framed
[18:50:17 CDT(-0500)] <colinclark> Do you want to draft an outline?
[18:50:23 CDT(-0500)] <colinclark> And then I can provide some shape and key points?
[18:50:25 CDT(-0500)] <Bosmon> thealphanerd - there is nothing
[18:50:28 CDT(-0500)] <Bosmon> "add a chart"
[18:50:43 CDT(-0500)] <Bosmon> Some people are doing tinkerings in stuff like D3 at the moment
[18:50:57 CDT(-0500)] <thealphanerd> there is nothing?
[18:51:03 CDT(-0500)] <thealphanerd> I love me some D3
[18:51:04 CDT(-0500)] <Bosmon> No frameworks
[18:51:11 CDT(-0500)] <thealphanerd> frameworks for?
[18:51:12 CDT(-0500)] <colinclark> for visualization, Bosmon?
[18:51:16 CDT(-0500)] <Bosmon> yes
[18:51:19 CDT(-0500)] <thealphanerd> Bosmon: you so crazy
[18:51:22 CDT(-0500)] <colinclark> ah, yes
[18:51:34 CDT(-0500)] <thealphanerd> where did that come from?
[18:52:45 CDT(-0500)] <colinclark> thealphanerd: If you're cool with it, take a stab at an outline
[18:52:52 CDT(-0500)] <colinclark> based on a few of these ideas
[18:52:57 CDT(-0500)] <colinclark> I can take a look at it whenever
[18:53:13 CDT(-0500)] <thealphanerd> sure thing
[18:53:16 CDT(-0500)] <Bosmon> thealphanerd - I guess it came from colinclark's recent readings in Critical Theory
[18:53:19 CDT(-0500)] <thealphanerd> I'll try and get to something today / tomorrow
[18:53:25 CDT(-0500)] <thealphanerd> ahhh Critical theory
[18:53:26 CDT(-0500)] <colinclark> awesome
[18:53:27 CDT(-0500)] <thealphanerd> I use to do that
[18:53:29 CDT(-0500)] <thealphanerd> and enjoy it
[18:53:34 CDT(-0500)] <thealphanerd> now I think about math / music all the time
[18:53:47 CDT(-0500)] <colinclark> Was your Cecchetto class a critical theory class?
[18:53:56 CDT(-0500)] <thealphanerd> post humanism
[18:54:00 CDT(-0500)] <thealphanerd> Critical theoryish
[18:54:00 CDT(-0500)] <colinclark> ah, yes
[18:54:06 CDT(-0500)] <colinclark> yes
[18:54:12 CDT(-0500)] <Bosmon> Since it is argued that "there is no art that is not good art", we may similarly argue that "there are no frameworks"
[18:54:19 CDT(-0500)] <colinclark> aha
[18:54:23 CDT(-0500)] <colinclark> now I get it
[18:54:30 CDT(-0500)] <colinclark> thealphanerd: I was reading Adorno the other day
[18:54:38 CDT(-0500)] <colinclark> who is quite pleasantly extreme in his definition of art
[18:54:44 CDT(-0500)] <colinclark> though not quite extreme enough for my tastes
[18:54:51 CDT(-0500)] <colinclark> He argued that there simply was no "bad art"
[18:54:55 CDT(-0500)] <colinclark> if it wasn't good, it wasn't art
[18:55:06 CDT(-0500)] <thealphanerd> lul
[18:55:09 CDT(-0500)] <thealphanerd> hence no frameworks
[18:55:35 CDT(-0500)] <colinclark> we'll get some eventually
[18:55:46 CDT(-0500)] <Bosmon> Yes
[18:55:55 CDT(-0500)] <Bosmon> Eventually, lemon-soaked paper napkins will arise
[18:56:32 CDT(-0500)] <thealphanerd> Bosmon: now you have lost me again
[18:56:38 CDT(-0500)] <thealphanerd> but that sounds like it would smell great
[18:57:12 CDT(-0500)] <Bosmon> thealphanerd: http://www.clivebanks.co.uk/THHGTTG/THHGTTGradio12.htm
[18:57:27 CDT(-0500)] <Bosmon> "The statistical likelihood is that other civilisations will arise. There will one day be lemon-soaked paper napkins. ‘Till then, there will be a short delay. Please return to your seats."
[18:57:37 CDT(-0500)] <thealphanerd> I love me some hitch hikers guide
[19:01:00 CDT(-0500)] <thealphanerd> colinclark: tons of school work this week?
[19:01:17 CDT(-0500)] <colinclark> it's a combination of work work and school work
[19:01:34 CDT(-0500)] <colinclark> Plus the weather's getting good and my mind is drifting to the boat and getting it ready
[19:01:35 CDT(-0500)] <thealphanerd> grosssss
[19:01:51 CDT(-0500)] <colinclark> It should all be reasonably fun work
[19:02:03 CDT(-0500)] <colinclark> A report on the GPII architecture
[19:02:10 CDT(-0500)] <colinclark> another similar report for a similar grant
[19:02:10 CDT(-0500)] <thealphanerd> Henke is showing right now how to utilize a cycle object like a wave table
[19:02:16 CDT(-0500)] <thealphanerd> and drive it by its phase response
[19:02:19 CDT(-0500)] <colinclark> and a paper about Wittgenstein and Jonas Mekas
[19:02:25 CDT(-0500)] <thealphanerd> rather than giving it a value for frequency
[19:02:25 CDT(-0500)] <colinclark> ah, yes
[19:02:42 CDT(-0500)] <colinclark> Is he doing this in Live?
[19:02:46 CDT(-0500)] <thealphanerd> max
[19:03:52 CDT(-0500)] <colinclark> Is he using phasor~?
[19:04:17 CDT(-0500)] <thealphanerd> nope
[19:04:19 CDT(-0500)] <thealphanerd> cycle~
[19:04:27 CDT(-0500)] <thealphanerd> he just made a bass drum with it
[19:04:30 CDT(-0500)] <thealphanerd> using fm
[19:04:35 CDT(-0500)] <thealphanerd> actually my bad
[19:04:36 CDT(-0500)] <thealphanerd> AM
[19:04:37 CDT(-0500)] <colinclark> but what is modulating the phase?
[19:04:45 CDT(-0500)] <thealphanerd> a line object
[19:04:49 CDT(-0500)] <colinclark> ah, just a line
[19:05:09 CDT(-0500)] <thealphanerd> I'll get all his stuff your way once we get materials
[19:05:10 CDT(-0500)] <thealphanerd> if you want
[19:05:20 CDT(-0500)] <colinclark> sure, I'd love to see it
[19:05:30 CDT(-0500)] <colinclark> So what's he got in the cycle~ table?
[19:05:33 CDT(-0500)] <colinclark> to make the drum?
[19:07:16 CDT(-0500)] <thealphanerd> taking a pic for you
[19:09:59 CDT(-0500)] <colinclark> thanks!
[19:15:48 CDT(-0500)] <thealphanerd> http://cl.ly/image/361W2v2A2G1b