Announcing Exhibit 3.0

[mackenzie]

I'm delighted to announce the launch of a new "Exhibit 3.0" project: a
collaboration of the original Simile project team including the MIT
Libraries, MIT CSAIL, and Zepheira, with funding and support from the
U.S. Library of Congress.

Exhibit 3.0 will build on the success of the current Exhibit tool but
redesign it to be far more scalable, flexible and modular. You can
read more about it at http://www.simile-widgets.org/exhibit3 and we
welcome your feedback and participation as we ramp the project up in
the coming months.

Thanks to all of you for making Exhibit such a great tool and for
using it so creatively. We hope that Exhibit 3.0 will be even more
valuable and look to you to help us make it so.

Happy New Year!

MacKenzie Smith, MIT Libraries

[mleden]

Hi MacKenzie,

That really sounds great. I love the overall direction and with all
of the extremely smart and dedicated folks involved, I am sure that
Exhibit will continue to be a smashing success.

Just my two cents on reading through the SIMILE Tools Workshop
Summary*:
1. Although I admire the goal of backward compatibility, I personally
don't view that as a gating item for a new release of Exhibit, given
the significantly broader scope of the new version.
2. I love the idea of a remote/local hosting option for the SIMILE
resources. Could I suggest that you even explore having an Exhibit
end-user option (cookie perhaps?) to govern that?

* Am I missing something? It seems that most (all?) of the references
to "Exhibit 2.0" should be "Exhibit 3.0" in the SIMILE Tools Workshop
Summary.

Many thanks for the team's continued efforts on this truly excellent
tool.

-Mark

On Jan 14, 3:07 pm, mackenzie <ken...@mit.edu> wrote:
> I'm delighted to announce the launch of a new "Exhibit 3.0" project: a
> collaboration of the original Simile project team including the MIT
> Libraries, MIT CSAIL, and Zepheira, with funding and support from the
> U.S. Library of Congress.
>
> Exhibit 3.0 will build on the success of the current Exhibit tool but
> redesign it to be far more scalable, flexible and modular. You can

> read more about it athttp://www.simile-widgets.org/exhibit3and we

[Arithmeticus]

This is wonderful news!

I would encourage the 3.0 team to think about and support a more
robust, complex querying language. I quickly outstripped the limited
range of . and ! in the current version (at least the range attested
in the documentation), and set my project aside, frustrated. I wanted,
for example, to display the content of property B of a class of Y
objects, selecting only those Ys where the first four characters Y's
property A (think instring function) correspond to a property C of a
preselected object X.

It would be nice, too, to have greater support of GREP.

I'm happy to put limited time into testing and helping with
documentation.

jk

On Jan 14, 6:07 pm, mackenzie <ken...@mit.edu> wrote:
> I'm delighted to announce the launch of a new "Exhibit 3.0" project: a
> collaboration of the original Simile project team including the MIT
> Libraries, MIT CSAIL, and Zepheira, with funding and support from the
> U.S. Library of Congress.
>
> Exhibit 3.0 will build on the success of the current Exhibit tool but
> redesign it to be far more scalable, flexible and modular. You can

> read more about it athttp://www.simile-widgets.org/exhibit3and we

[Jonno B]

Hi MacKenzie, all the best for the project! It sounds extremely
promising, and I can't wait to put it in to use :)

On another note, I think it is time to restrict Simile Wiki edits to
registered accounts only - there has been a large increase in
anonymous spam bot edits. My 2cents.

Good Luck!
Jon Bogacki

[jbs]

Awesome!

Maybe using Solr as a backend?
HDFS -> Solr ->Exhibit would be nice :).

Good Luck!

[eric miller]

On Jan 14, 2011, at 7:29 PM, mleden wrote:

> Hi MacKenzie,
>
> That really sounds great. I love the overall direction and with all
> of the extremely smart and dedicated folks involved, I am sure that
> Exhibit will continue to be a smashing success.
>
> Just my two cents on reading through the SIMILE Tools Workshop
> Summary*:
> 1. Although I admire the goal of backward compatibility, I personally
> don't view that as a gating item for a new release of Exhibit, given
> the significantly broader scope of the new version.

Thanks for this kind of feedback. Thats very helpful. The intention is to start with this goal, and if we have to deviate from this path, to document accordingly.

> 2. I love the idea of a remote/local hosting option for the SIMILE
> resources. Could I suggest that you even explore having an Exhibit
> end-user option (cookie perhaps?) to govern that?

The current thoughts wrt to this sort of functionality are more to do with the content producers of exhibits than the consumers. But your suggestion is an interesting one; could you elaborate a bit on this? We hope to start using the wiki to capture community suggestions for shaping curret design / future consideration so any details you can provide would be helpful.

>
> * Am I missing something? It seems that most (all?) of the references
> to "Exhibit 2.0" should be "Exhibit 3.0" in the SIMILE Tools Workshop
> Summary.

Good catch ;) We changed the name to Exhibit 3.0 after this workshop as not to confuse folks (even more) with the release of Exhibit 2.0 back in 2007. Hopefully, we'll do the job right, and eventually this will all just be known as Exhibit in the (near) future ;) Until then, I suspect any name will have some confusion associated with it - Exhibit 3.0 hopefully less than others.

--e

>
> Many thanks for the team's continued efforts on this truly excellent
> tool.
>
> -Mark
>
>
> On Jan 14, 3:07 pm, mackenzie <ken...@mit.edu> wrote:
>> I'm delighted to announce the launch of a new "Exhibit 3.0" project: a
>> collaboration of the original Simile project team including the MIT
>> Libraries, MIT CSAIL, and Zepheira, with funding and support from the
>> U.S. Library of Congress.
>>
>> Exhibit 3.0 will build on the success of the current Exhibit tool but
>> redesign it to be far more scalable, flexible and modular. You can
>> read more about it athttp://www.simile-widgets.org/exhibit3and we
>> welcome your feedback and participation as we ramp the project up in
>> the coming months.
>>
>> Thanks to all of you for making Exhibit such a great tool and for
>> using it so creatively. We hope that Exhibit 3.0 will be even more
>> valuable and look to you to help us make it so.
>>
>> Happy New Year!
>>
>> MacKenzie Smith, MIT Libraries
>

> --
> You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group.
> To post to this group, send email to simile-...@googlegroups.com.
> To unsubscribe from this group, send email to simile-widget...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en.
>
> .

[eric miller]

On Jan 16, 2011, at 4:26 PM, Jonno B wrote:

> Hi MacKenzie, all the best for the project! It sounds extremely
> promising, and I can't wait to put it in to use :)
>
> On another note, I think it is time to restrict Simile Wiki edits to
> registered accounts only - there has been a large increase in
> anonymous spam bot edits. My 2cents.

Good suggestion Jon. No one likes their contributions to be updated by spam bots :( The wiki has been configured to now only allow registered users to edit.

--e

[eric miller]

On Jan 16, 2011, at 8:41 AM, Arithmeticus wrote:

> This is wonderful news!
>
> I would encourage the 3.0 team to think about and support a more
> robust, complex querying language. I quickly outstripped the limited
> range of . and ! in the current version (at least the range attested
> in the documentation), and set my project aside, frustrated. I wanted,
> for example, to display the content of property B of a class of Y
> objects, selecting only those Ys where the first four characters Y's
> property A (think instring function) correspond to a property C of a
> preselected object X.
>
> It would be nice, too, to have greater support of GREP.

Is there a specific query language your thinking of here (i.e. google refine's regex language)? As you know there's a trade off between query complexity and performance; striking that balance will be critical. At this point we're focusing really on just getting this project off the ground and providing something for folks to react to. As this evolves however, getting specific about these requirements will be critical. As I mentioned in a previous email, we hope to start using the wiki to capture community suggestions for shaping curret design / future consideration so any details to the ones above you can provide would be helpful.

> I'm happy to put limited time into testing and helping with
> documentation.

Excellent! thanks for the offer. No good suggestion goes unpunished around here ;)

--e

>
> jk
>
> On Jan 14, 6:07 pm, mackenzie <ken...@mit.edu> wrote:
>> I'm delighted to announce the launch of a new "Exhibit 3.0" project: a
>> collaboration of the original Simile project team including the MIT
>> Libraries, MIT CSAIL, and Zepheira, with funding and support from the
>> U.S. Library of Congress.
>>
>> Exhibit 3.0 will build on the success of the current Exhibit tool but
>> redesign it to be far more scalable, flexible and modular. You can
>> read more about it athttp://www.simile-widgets.org/exhibit3and we
>> welcome your feedback and participation as we ramp the project up in
>> the coming months.
>>
>> Thanks to all of you for making Exhibit such a great tool and for
>> using it so creatively. We hope that Exhibit 3.0 will be even more
>> valuable and look to you to help us make it so.
>>
>> Happy New Year!
>>
>> MacKenzie Smith, MIT Libraries
>

[Contemplative]

After having read the workshop summary, I am very encouraged!

I think the scope is right on.

I wonder if the "Exhibit Builder" tool(s) might be something that the community at large

is more suited to as the early adopter stage comes about?  I can imagine that there are

numerous ideas and a wide range of platform/architecture possibilities.  As a stable framework

makes itself evident through the Exhibit 3.0 development process, the community at large

would likely come up with many creative choices for non or semi-programmer end users.

Encouraging this would also provide an alternative avenue of engagement by the community.

Exhibit 3.0 is very cool news!

Wes Wieland

[mackenzie]

Hi Wes,

by 'the Exhibit Builder tool' being something the community-at-large
might be more suited to, do you mean provide requirements for it or
implement it? You're right that this small project can't cover every
scenario and we intend to focus on one or two common ones. We'd
welcome wider involvement from the community on that, so maybe we
should create a space on the website for folks to register their
interest and ideas?

MacKenzie

[Contemplative]

Hi MacKenzie,

I see the 'builder tool' as a community effort at implementation more so than at requirements.  

The requirements would be dictated by Exhibit 3.0 workings and basic configuration model

for each of the widgets within Exhibit.  The community at large is likely to come up with

numerous implementations, some of which are likely to be successful.  Basically, I see the

'builder tool' as a Darwinian effort as compared to the more carefully planned effort for 

Exhibit itself.  Additionally, community based projects like this are likely to keep the core

Exhibit team on track as far a the documentation effort goes.  As Exhibit reaches the stage 

where a wider community(early adopters) have access, the broader the community, the more

likely that issues regarding documentation clarity will become apparent, better enabling those

charged with documentation to address those issues.  

I think it would be an excellent idea to create a space on the website for folks to register their 

interests and ideas! The wiki has been helpful to me already in this manner, allowing me to 

leverage other folks' ideas in my own projects.  A place to follow along and discuss the Exhibit 3.0

progress and simply discuss it would be beneficial to the community and the project core team I would think.

I will offer myself up as an example at the risk of giving you way more than you want.. :-)

I would like the documentation to be somewhat W3C like, where a user can actually modify a sample css

and see the results.  That may be way too much, but discussion about it by the community would either

generate some interest of kill the idea off as exactly that; too much.  Having a place to discuss it would'

be great!  As a further example, I have been working on some Perl modules which dynamically generate

exhibits based on a template system.  It would be great to have a place to discuss such peripheral projects.

Thanks for asking.

Wes

[Contemplative]

One thing that I have noticed is that there seems to be a difference
between the time plot widget and the time line widget in the way they
handle time. The time plot widget seems to adjust display times based
on local time whereas the time line does not.

If I have a start time of "2010-10-01T01:01:01Z" in my JSON data, the
time line will plot it correctly, but the time plot will adjust it by
(my time zone) -6 hrs.

I have addressed this by providing two differently formatted times,
one for the time line and one for the time plot:

timeline = "2010-10-01T01:01:01Z"
timeplot = "2010-10-01 01:01:01"

Perhaps there is a better way, but the fact that the two widgets don't
work consistently with the same format should be addressed in exhibit
3.0 in my opinion.

Thanks

wjw

[mackenzie]

Hi wjw,

Unfortunately, changing current Exhibit display widgets is outside the
scope of the Exhibit3 project since we have to focus on the stuff we
promised the funder. That said, I'm sure if the opportunity presents
itself we'll take a look at this, and hopefully other developers on
this list will take an interest even sooner if its a problem for
everyone.

Thanks for pointing it out,

MacKenzie

On Feb 21, 12:36 pm, Contemplative <wjwiel...@gmail.com> wrote:
> One thing that I have noticed is that there seems to be a difference
> between the time plot widget and the time line widget in the way they
> handle time.  The time plot widget seems to adjust display times based
> on local time whereas the time line does not.
>
> If I have a start time of "2010-10-01T01:01:01Z" in my JSON data, the
> time line will plot it correctly, but the time plot will adjust it by
> (my time zone) -6 hrs.
>
> I have addressed this by providing two differently formatted times,
> one for the time line and one for the time plot:
>
> timeline = "2010-10-01T01:01:01Z"
> timeplot = "2010-10-01 01:01:01"
>
> Perhaps there is a better way, but the fact that the two widgets don't
> work consistently with the same format should be addressed in exhibit
> 3.0 in my opinion.
>
> Thanks
>
> wjw
>
> mackenzie wrote:
> > I'm delighted to announce the launch of a new "Exhibit 3.0" project: a
> > collaboration of the original Simile project team including the MIT
> > Libraries, MIT CSAIL, and Zepheira, with funding and support from the
> > U.S. Library of Congress.
>
> > Exhibit 3.0 will build on the success of the current Exhibit tool but
> > redesign it to be far more scalable, flexible and modular. You can

> > read more about it athttp://www.simile-widgets.org/exhibit3and we

[mwra]

On Feb 22, 3:09 am, mackenzie <ken...@mit.edu> wrote:
> Hi wjw,
>
> Unfortunately, changing current Exhibit display widgets is outside the
> scope of the Exhibit3 project since we have to focus on the stuff we
> promised the funder.

Do I read that correctly as to mean Timeline is not being updated as
part of Exhibit 3? I'm looking into another Timeline-based project and
just wondered if it was about to chnge (no big deal either way). I do
recall seeing reference to an HTML5-based re-write.

Regards

Mark Anderson

[mackenzie]

Yep, you are correct -- Timeline (i.e. the standalone widget) is not
included in the Exhibit 3 project. But the timeline view inside
Exhibit will be updated to work with the new Exhibit framework...

MacKenzie

[John Callahan]

Thanks for keeping Exhibit going.  At my university, we use it quite a lot.  (The latest site I know of is at: http://www.udel.edu/udbooks/)   It's good to see a path forward for the project. 

From my experience, and form talking with others around here putting up Exhibits, the primary requested new features/enhancements in 3.0 would be:

- Scalable to a larger number of records.  100K would satisfy most uses I know of (which I'm sure will change once it's available.)
- Keeping state, either through a URL or by clicking away from the Exhibit and then coming back.  (this is probably the most often complaint I get from users)
- Documentation for non-trivial functions.  It's common to want to process the data before it gets displayed in a facet, lens, or view, which I've accomplished creating simple mapping functions inside the Exhibit framework.  Documentation on adding custom mapping functions and how to use existing expressions and functions is needed.
- Editing would be useful, as long as the changes are propagated back to the data source (Google Spreadsheet, json doc.)

I also agree with many of the other suggestions from previous posters. 

For the Exhibit server (staged mode), would the Data Services support relational databases as a data source, such as Postgres, MySQL, sqlite, maybe Oracle?  Even if server side scripts would need to be modified, the ability to expose a table (or more) as an Exhibit would be great.

Also, I just viewed a presentation on a project of the Library of Congress called Recollection, http://recollection.zepheira.com/.  Recollection has a very nice GUI Exhibit Builder, with the ability for them to host your own exhibits, and more features to come.  Since Exhibit 3.0 project is partially supported by LOC with a partnerships with Zepheria, is there any co-development going on between these two projects?    The code for recollection will also be released as open source. 


- John

***********************************
John Callahan, Research Scientist
Delaware Geological Survey
University of Delaware
URL: http://www.dgs.udel.edu
*******************************

[eric miller]

(catching back up on this thread)

On Apr 19, 2011, at 4:07 PM, John Callahan wrote:

> Thanks for keeping Exhibit going. At my university, we use it quite a lot. (The latest site I know of is at: http://www.udel.edu/udbooks/) It's good to see a path forward for the project.

Nice exhibit! ;)

> From my experience, and form talking with others around here putting up Exhibits, the primary requested new features/enhancements in 3.0 would be:
>
> - Scalable to a larger number of records. 100K would satisfy most uses I know of (which I'm sure will change once it's available.)
> - Keeping state, either through a URL or by clicking away from the Exhibit and then coming back. (this is probably the most often complaint I get from users)
> - Documentation for non-trivial functions. It's common to want to process the data before it gets displayed in a facet, lens, or view, which I've accomplished creating simple mapping functions inside the Exhibit framework. Documentation on adding custom mapping functions and how to use existing expressions and functions is needed.

John, thanks for the independent confirmation regarding new features/enhancements in Exhibit3. It's good to hear from many perspectives we seem to be on the right path.

> - Editing would be useful, as long as the changes are propagated back to the data source (Google Spreadsheet, json doc.)

Yeah... it's that last 'propagation' bit thats tricky. ;)

> I also agree with many of the other suggestions from previous posters.
>
> For the Exhibit server (staged mode), would the Data Services support relational databases as a data source, such as Postgres, MySQL, sqlite, maybe Oracle? Even if server side scripts would need to be modified, the ability to expose a table (or more) as an Exhibit would be great.

Bingo ;) Building these interfaces to the specific end points you mentioned is out of scope for this phase of work, but thats exactly the direction we're headed.

> Also, I just viewed a presentation on a project of the Library of Congress called Recollection, http://recollection.zepheira.com/. Recollection has a very nice GUI Exhibit Builder, with the ability for them to host your own exhibits, and more features to come. Since Exhibit 3.0 project is partially supported by LOC with a partnerships with Zepheria, is there any co-development going on between these two projects?

Recollection provides one example of a GUI exhibit building, event notification, exhibit embedding, data transformation and augmentation services (via akara http://akara.info) etc. Exhibit 3 will provide increased scalability for larger data sets and views, etc.. As you've suggested, these are indeed designed to be complementary projects. From an architecture perspective, they (Recollection, Akara, Exhibit3) are being built to play off each others strengths while maintaining independent code-bases and stand alone utility.

> The code for recollection will also be released as open source.

Yep.

--
Eric Miller
President, Zepheira "The Art of Data"
http://zepheira.com/ tel:+1.617.395.0229

[David Karger]

On 5/10/2011 7:34 AM, eric miller wrote:
> On Apr 19, 2011, at 4:07 PM, John Callahan wrote:
>
>> From my experience, and form talking with others around here putting up Exhibits, the primary requested new features/enhancements in 3.0 would be:
>>

>> - Documentation for non-trivial functions. It's common to want to process the data before it gets displayed in a facet, lens, or view, which I've accomplished creating simple mapping functions inside the Exhibit framework. Documentation on adding custom mapping functions and how to use existing expressions and functions is needed.

It doesn't meet the needs of advanced users, but if you just want to
introduce a newcomer to exhibit, a fantastically detailed tutorial is
available from some users at the Ensemble project, which holds workshops
teaching people how to use exhibit:
http://simile-widgets.org/docs/CAL_Ensemble_Booklet.pdf

>> - Editing would be useful, as long as the changes are propagated back to the data source (Google Spreadsheet, json doc.)
> Yeah... it's that last 'propagation' bit thats tricky. ;)

You can see one example of in-place editing at
http://projects.csail.mit.edu/exhibit/Dido. It persists without
propagating----the data is stored in the html doc, which you save locally.

I am working on separating out an editing extension. It probably won't
include propagation, but will include a hook where you can put your own
special purpose propagation code.

I wish I could implement writebacks to google spreadsheets, the most
obviously adoptable persistence mechanism, but so far I haven't found a
way to make the protocols work from the client site---you need help from
a server that can handle authentication to google. I'm hoping this
might change with the evolution of the CORS protocol.

[John Callahan]

On Wed, May 11, 2011 at 1:36 AM, David Karger <kar...@mit.edu> wrote:

I wish I could implement writebacks to google spreadsheets, the most obviously adoptable persistence mechanism, but so far I haven't found a way to make the protocols work from the client site---you need help from a server that can handle authentication to google.  I'm hoping this might change with the evolution of the CORS protocol.

Would it be any different with Google Fusion tables?  I haven't played around with them yet but they seem to have potential in this case.  Could be the same problem with authentication though...

- John