Interesting philosophical issues.
On 1/26/07, David Karger <[EMAIL PROTECTED]> wrote:
> 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.
If we freeze perspective on fully-client-side operation, yes. (Which
arguably is the case, as long as we talk about stand-alone Exhibit
operation.) Views or computed facets might smell better server side,
as that would not exhibit (pun not intended) the data opacity problem.
On the other hand, with Exhibit's Copy menu's functionality, I'd say
we are neither at the fully opaque nor fully transparent end of the
spectrum; any DOM and javascript capable browser can render an
exportable version of the data set, and we could easily expose (I'd
venture guessing it's just documenting a call) a programmatic
interface for doing so too. (We presently don't have one, probably for
assuming it something no other software in existence could interface
to.)
I'm sort of divided on this myself, though probably not nearly as
much, and for different reasons -- I care more passionately for client
side intelligence than for delivery-mode independent data. If the data
at hand is well structured enough for me to process client side, I'm
happy. Raw data delivery mode for raw-HTTP-only clients usually has a
somewhat better smell, even to me, though I largely consider we have
already abandoned that with accepting the data sources we handle
today, not including JSON-in-an-external-file (the others, once again,
require devising data scrapers à la mashup land -- or interfacing to a
running Exhibit instance).
Should I avoid checking in things that enable Exhibit users to do this
kind of thing? I realized, just now, that the small addition of a
valueParser property for use with loadDataFromTable already exposes
this possibility to me, as it references a function that is at liberty
to return one or more item properties, given a table cell node (and
its contents).
I added the feature as I wanted Exhibit to read my "When" column,
which includes either a timestamp (>90% of all cases) or a time range
("between t1 and t2"), which is unfortunately how all but the most
computer science beread meta data samurais lay out their information.
It's similar to the XHTML vs HTML controversy, or strongly vs loosely
typed languages; tight ropes or resilience.
> 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.
Turing complete data sets (such as storing lisp expressions as data,
or to be fashionably verbose, xslt transforms) have their issues too,
though I'd agree it would be a nice thing to have, too.
Hm. Or do you rather mean what I consider it apparent that we already
have -- the Copy exporter? I consider computed facets something
Exhibit does in the data input stage, prior to building its own
internal data model and rendering its views. That mode of operation
lets Exhibit export raw data, undiscerning computed from nonderived
data.
Facets computed during rendering don't add much value, unless you want
to use Exhibit as a real-time system reacting to and remodeling itself
on phases of the moon and similar.
--
/ Johan Sundström, http://ecmanaut.blogspot.com/
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
