A little followup to this old thread. Suppose we accept that computed
facets are a good thing as data manipulation (you say "I consider
computed facets something Exhibit does in the data input stage") then
perhaps the place to define the computed facets is as _computed
properties_ in the _json file_, rather than as something in the html
file. This is appealing because, for example, we could use arbitrary
javascript code to compute the facets, and it would feel fine since it
is already a js file. We might also want a simpler facet-computation
language like sparql, of course. But keeping it in the data file would
make clear that we consider it data manipulation rather than view
manipulation. On the downside, I've seen plenty of exhibits using
multiple data files, and we might want the computation to apply to the
merged data. So if we stuck in in the js, we would need a way to merge
the data files as data instead of in an html exhibit. Some kind of
wrapper.js that refs the js files we want to include.
Johan Sundström wrote:
> 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 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.
>
>
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
