Templating JSON records, Thoughts from ISSUE 513

[Thad Guidry]

A Related question to this issue http://code.google.com/p/google-refine/issues/detail?id=513 does make me think however...

Why do I have to use Fill Down on each row afterwards in order to retain the record information on each author, such as "Storm, Peter A." ?  If I import using my steps above, ignore the error, and then go directly to Export, Templating... I notice that even though I am in records mode, the underlying cell structure is retained and if I scroll down in the Templating preview window, I see that fields are null for "Storm, Peter A." and no linkage occurs for him to his parent record details.  I am forced to use Fill Down on all columns in order to push that information over.  Is that intended ? Why ?

--
-Thad
http://www.freebase.com/view/en/thad_guidry

[David Huynh]

It's not "intended or not intended". The record interaction paradigm has simply been incomplete. By paradigm I mean how all the features are designed to work together in conjunction with the record model. It was not entirely obvious to me how to handle hierarchical records through a tabular interface, so I decided to expose a few features related to the record model and see how they get used. So far, they can unblock a few tricky cases, but they can be bewildering. We'll need to rethink how they should work conceptually.

David

[Thad Guidry]

Ah, OK, David.

So, perhaps one concept I thought about is the idea of Record stacks, rather than a breadcrumb approach, and a bit more visually appealing and where CSS styling can be applied or removed for greater effects.

An expandable, stack header (which might have an optional vertical slider widget or simple click arrows to expand or collapse deeper and deeper header fields, just as you have expand all and collapse available for columns) It might be a better way to present Records and organize a bit better ?  Optional drop down sub-menus could be built upon each Record fields parent stack, I suppose as well.  Later on, Pivoting could be incorporated more fully into it with the existing Columnize Key:Value functions.  Something to think about... anyway attached is an example screenshot of the idea of a stack header.

Add this one to the 3.0 milestone feature discussion as "Record stack headers" suggested by Thad :)

--
-Thad
http://www.freebase.com/view/en/thad_guidry

[Tom Morris]

The column/record model that Thad's visual implies would help us with issue 137 as well.  Currently we assume that any column group has a "key" column where the cell is always populated.  That assumption turns out to not always be true for certain classes of XML files (and perhaps JSON files as well).

Tom