Data Platform Design

Introduction

This page originates from the discussion about a new "data-centric approach" to the W3C site. In particular, it is concerned with a limited JSON API that would be open to third parties, and renovated (dynamic) features to search and filter main nodes of information on the site.

Information architecture

Main entities on our DB, relations among them, and their attributes ^{[1][2][3][4][5]}.

Hierarchy of entities

• Domains.
  • Activities.
    • Groups.
      • Working groups.
      • Community groups.
      • Business groups.
      • Interest groups.
      • Coordination groups.
      • Task forces.
      • Charters.
• Organisations.
• Specs.
  • Versions.
  • Translations.
• Events.
  • Talks (might be a separate entity; not specifically an event).
• Press articles.
• News items.
• People.
• Offices.

Attributes

Domains:

Groups:

• Type (community / business; but also "WGs, IGs, CGs, BGs, Coordination Groups, TAG, and AB").
• Title (string).
• Creation date (date).
• Number of participants (integer).
• Status (current / proposed / past).

Organisations:

Specs:

People:

Design of the API

What entities should be exposed and how; what parameters are accepted.

See use cases, data and Daniel Davis URI notes.

Development of a prototype for search and filtering (web page)

There is a very basic prototype that hopefully will help in this discussion — to polish the API and to start using such API in real case scenarios.

Technical decisions

This particular prototype is being built using:

• Foundation 5.3.3 for CSS boilerplate, basic styling, UI widgets, layout and responsive behaviour.
• AngularJS 1.2.22 as a general JS framework.
• The ngResource module to handle a RESTful API returning JSON.

Assuming that we can configure them to ensure a minimum in terms of usability, performance and accessibility, this set of tools seem satisfactory for a future web page to search dynamically within W3C entities.

The only change suggested is going for Bootstrap 3.2.0 instead of Foundation — there seem to be more and more useful UI controls and states in the former, and it is widely used.

Features

This sections deals with some of the concerns raised by participant in this discussion recently. The goal is to use the prototype to check whether these are fair concerns that shou

• Architecture and performance:
  • Relying on the user's device capabilities: admissible?
  • Increase in complexity: admissible?
• Usability:
  • Permanent URIs (lack of): the prototype is using the browser history API to save every new search term as a new URL. However, the previous states are not being recovered (yet) when the user goes back in history. That is WIP, but no issues are anticipated.
  • In-page anchors: for the moment, these are used to switch between different items for search (users, specs, groups, etc). The results now are a list of items, with one line for every item, with very little metadata. Given that the user will have to click one of those items (and navigate away) after searching, do we need fragment identifiers for every individual result?
  • User confusion when a page has loaded but there's no content yet; delay between page having loaded but content not yet loaded: the prototype is disabling user input and showing a message temporarily, while searching.
  • It may not be stylable with the :target selector: check pending.
• Accessibility:
  • What about people who deactivate Javascript? What happens for them if we cannot provide server-side generated documents?: would not those people be using our regular pages, search engines, etc instead — just as they do now?

References

1. W3C Site Map
2. Community and Business Groups | A W3C Community Group
3. Current Groups | Community and Business Groups
4. Community and Business Groups
5. Current Groups | Community and Business Groups