High Performance Faceted Interfaces Using S2S Eric Rozell, Tetherless World Constellation

Outline Motivation Demos Architecture S2S-Compatible Web Services Deploying S2S S2S UI Development S2S: The Next Generation Questions

Motivation Reusable user interfaces Supporting heterogeneous data Leveraging legacy web services Customizable search interfaces

Overview

Demos BCO-DMO MapService IOGDS version 1.2

Architecture

S2S-Compatible Web Services Real world example: –IOGDS Step (1): identify your “Parameters” –Countries, catalogs, agencies, categories, keywords, (languages?)…

S2S-Compatible Web Services Step (2): create metadata for your “Parameters” –At this time, figure out which “Parameters” should be “dynamic”, i.e., vary as other parameters are constrained.

S2S-Compatible Web Services Step (3): create QueryInterface-s for each “dynamic Parameter” –A separate asynchronous request is made for each Parameter and the results. –You will need to identify the expected output of the QueryInterface, as well as the Parameter it returns values for.

S2S-Compatible Web Services Step (4): create a QueryInterface for your results. –Sometimes, it’s easiest to use a plain HTML response. (There’s already a QueryInterface for that!)

S2S-Compatible Web Services Step (5): code your service! –This is entirely up to you. You’re free to use any programming language, so long as you can describe your web service using OpenSearch (for now). –Some programming languages people have used include: PHP, Python, Go, and node.js

S2S-Compatible Web Services Step (6): describe your service… –using OpenSearch. –This is where all those URIs come in…

S2S-Compatible Web Services

Step (7): create metadata for your service. –This will inform S2S where to find things like your OpenSearch description document.

S2S-Compatible Web Services Step (8): host the metadata. –Currently, S2S requires you to “register” the metadata (load it into the S2S triple store). –Coming Soon: Linked Data support…* * More on this later

S2S-Compatible Web Services [Optional] Step (9): create a default configuration file –This file will inform S2S of the order for parameters, and the UI widgets to use by default.

S2S-Compatible Web Services

Step (10): Deploy! –Don’t worry, this one’s easy…

Deploying S2S Can be deployed in a number of ways: –As a standalone application –Embedded in a CMS (e.g., Drupal) –Embedded in a custom application Examples follow…

Stand-Alone S2S S2S offers a core function that allows you to automatically render an interface based on HTML tag “id” attributes. –init(“

Stand-Alone S2S

S2S in CMS Embedding in a CMS is just as easy as the stand-alone browser… Just embed the same HTML and JavaScript into a page Be wary of Drupal, we have had issues where Drupal’s page rendering mechanism has caused browsers to crash (i.e., IE … heh)

S2S in Application X This core “init” function requires that you specify the result widget you want in your “default configuration” (we’ll get into that in a bit…). You may instead want to feed results to a separate application…

S2S in Application X

S2S allows you to override the “ResultsPanel”, i.e., the thing that gets updated every time a facet is changed. Rather than pushing the updated results to a “ResultWidget”, the results can be pushed to the external application.

S2S in Application X

S2S UI Development Real world example: –In IOGDS, there is a “Country” facet. –In truth, the labels for the “Country” facet are a hack… Labels are created by removing the namespace and underscores from the country URI. –We can make the UI responsible for getting country labels. While we’re at it… –Why not add a flag thumbnail?

Creating the Metadata Step (1), create widget metadata. –Choose URI for your widget –Choose type of widget In this case, it’s a s2s:ParameterWidget –Add label/comment to your widget –If necessary, constrain your widget to a specific parameter In this case, the “Country” parameter for IOGDS –If necessary, specify the expected results In this case, a simple JSON array containing URIs

Creating the Metadata Step (1) continued. –Specify the function names used by S2S This includes a function for generating a frame for the widget and a function for rendering query results –Specify the JavaScript files needed for your widget (including libraries!) Except jQuery… please don’t include jQuery, but feel free to use jQuery functions (S2S core already uses it!) –If necessary, include the CSS files needed for your widget Unless you’re lazy and encode the CSS in your JavaScript…

Creating the Metadata

Coding the Widget Step (2), code the widget. –There are two mandatory functions (or hooks) needed by S2S widgets: generator function (to build widget frame) callback function (to populate widget) –Be careful when choosing function names and assigning variables at the window level. widgetGenerator edu.rpi.tw.logd.s2s.widgetGenerator

The Generator Function

The Callback Function

Other Functions

Host the Metadata Step (3): Host the metadata. –Currently, S2S requires you to “register” the metadata (load it into the S2S triple store). –Coming Soon: Linked Data support…

S2S: The Next Generation S2S Server 2.0 –Service, widget, parameter metadata as linked data (via Ripple)Ripple –S2S metadata caching –Deployable/configurable server (via Servlets) S2S Search Interface 2.1 –“Linked data widgets” –Modular means of embedding widgets –Compound search widgets (e.g., date range) S2S Search Interface 2.x –Support for dynamic facet sets

Questions? Comments? Concerns? Critiques? …

Links BCO-DMO MapService IOGDS version 1.2