Johan, your issue of computed facets is one that we talk about a lot here, because it highlights a tension between what one might call the programmable and pure-data sharing of information. Basically, you can do a lot more with programming, but anytime you do so, it hides some aspect of your data behind a necessarily opaque (because of Turing undecidability) blob of code. I have a similar issue to yours on one of my exhibits, where I wanted to be able to modify the presentation based on whether a particular item had any address information---eg, whether there were any values for the optional city, state, or country properties. In the end, I implemented this by adding a "hasVenue" property to the exhibit. This was annoying in the sense that I have to keep it up to date myself, but from the perspective of data sharing, it is valuable because it forced me to make explicit another property of the data that I consider important. If we moved to a world of computed facets (related to what they call "views" in the db community) then we would be headed back down the unfortunate path of mashups: after doing all the work of getting the data out of some data-opaque web site by scraping the presentation, we go and create new data that is only visible through the execution of some data-opaque program.
Of course, I'd like to have both. I'd like some nice wysiwyg curatorial tools that let me describe a given property as some function of other properties, but then be able to save the results as an exhibit file so that these derived properties become data just like all the other properties. I believe a similar issue arises as we try to make exhibit presentations more powerful by adding things like case statements. At a certain point, if we continue to add complexity, we will have recreated javascript with a different, <> based syntax. That defeats a lot of the purpose of exhibit---the idea that you don't have to understand programs in order to create fancy presentations. It's interesting to try to balance this against the desire for more power. It seemed obvious to me, for example, that we need an if-then construct. It also seems obvious to me that we need a construct for creating "default values" for missing properties. On the flip side, it seems obvious to me that exhibit should never include constructs for doing loops, or for making any kind of function calls. But I could be wrong and it will be interesting to see where things land. Johan Sundström wrote: > I have a list of my choir's public appearances which I would like to > exhibitize, and in the process of doing so, I noticed many things I > would like to do that Exhibit presently don't. The present list can be > seen on > > http://www.tomaskoren.nu/informat.htm#aktiviteter > > and it has been filtered by a "still in the future" filter since a few > years, so while the table actually holds some 42 or similar rows, only > those events that have yet to go down are seen. (So it is essentially > a distant cousin of Exhibit's, but born without the blessing of > superpowers.) The three columns list start date and time, venue and > subject (mass, concert, et cetera), for those of you unfamiliar with > Swedish. > > To the list of things I noticed I kind of wish I had in Exhibit, but don't: > > * All views: computed facets (hasBeen:bool). Very easy, and should be > easy to do for everything we've already marked up enough to be able to > put on a timeline. Other computed facets include grouping things in > ranges (<10, 10-20, 20-30, >30, for instance, or 1970s, 1980s, 1990s, > 2000s, or a-e, e-j, j-o, o-t, u-z, and so on). hasBeen is actually > just the range < now(), after all. > > * tileView: the sort order "label" shows up in the list of options for > sorting, though I have not listed it as a legal sort criterion. I'd > like to be able to forbid that, where it doesn't make any sense (like > my testing rig for this, which has the three columns "When", "Where" > and "What", with a hidden label property I copied from the When > column, just because Exhibit wouldn't run without one. > > * tabularView: allow preset facet filters, just like my original page > ("is in the future" facet filter here on by default). I have a vague > feeling this might already be supported, but haven't dug into the code > to verify. > > * timelineView: I would want legends grouped together, grouping up a > few locations as "outside of Sweden". I have a slightly stronger > feeling this, too, is possible, via some other tables mapping some > locations to an "is foreign" property. I don't have my thinking had on > me at the time nor recall seeing any good examples of how to set it > up,able generated > looked a bit more like this: > > <table> > <colgroup class="Col1"></colgroup> > <colgroup class="Col2"></colgroup> > <colgroup class="Col3"></colgroup> > <thead><tr> > <th>Col1</th> > <th>Col2</th> > <th>Col3</th> > </tr></thead><tbody> > <tr>...</tr> > </tbody></table > > (oerhaps with some other naming for the colgroups, just somehow > including something to distinguish the column names by. This way, we > can employ .Col1 CSS styling to the first column. > > * timelineView: Where do I change width:400 height:300 of the lens popups? > > * I would like things performing sorting, comparing and reading of > floats to treat "\u221E" as "Infinity" (which i e parseFloat groks -- > including an optional +/- prefix). > > I have some thoughts and recent development about valueParsers to do > custom parsing of cells with your own javascript functions when using > loadDataFromTable, and an arity declaration similar to Google > Spreadsheets' :single, but I'll have to leave those for tomorrow, > because I'm falling asleep here. :-) > > _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
