Introduction

Ångströ is that most dreaded of software artifacts, a multi-purpose platform: infrastructure for storing, retrieving, sharing, and searching Atom entries with semi-structured contents.

• Using Ångströ as a stable, secure remote store can dramatically increase the power of user scripts and AJAX-style user interfaces.
• Using Ångströ as a notebook to collect ‘factoids’ while surfing allows easy searching — and graph-based measures for ranking relevancy.
• Using Ångströ as a notification service enables synchronization of multiple instances on occasionally-connected devices.

The central insight is that Atom entries are close to becoming a lowest-common-denominator for interchange between all of the application-layer protocols we are familiar with today; and that the REST architectural style (and its derivatives) are more appropriately used to explain how Web applications behave at a granularity finer than an HTML page.

One source of inspiration is the old world of PC database applications such as Access, FileMaker, and dBase – power users used to be capable of whipping together small applications using simple abstractions of forms, tables, and reports. We’d just like to use the World Wide Web as the database.

Scenario

A scenario I’d like to enable is the development of a so-called ‘long-tail application,’ something as seemingly frivolous as, say, a frequent-flier’s console:

1. review the status of every flight I’ve ever taken, on any carrier (“scrape feeds”)
2. allow me to print boarding passes or activate bonus offers (“invoke services”)
3. display the highest awards I am currently eligible for on each carrier – and how many miles to go until the next milestone (“calculation”)
4. and sort incoming offers for promotional mileage bonuses on routes/carriers that are likely to apply (“news ranking”)

From there, it would be fun to add all sorts of additional features like a map of where I’ve been, where I can transfer miles from credit cards to “top-up” accounts, analyses of how often I choose carriers on a citypair, get upgraded, or even integration with other applications like expense-reporting. However, the four core features above are already enough to evaluate whether an Ångströ would be helpful.

Netscrape

There are several sources of flight history information in my digital life: carrier’s FF sites, online travel agencies, emails from both, and random historical scraps such as Excel files.

The common tool I’d like to use on all of these sources is a ‘semantic highlighter’ to train a scraping bot by example. By “turning on a macro recorder” and logging into an FF-site, generating a report, and then pointing at relevant table columns for Origin / Destination / Date / Class / Flight / Reservation, I should be able to create an Atom entry with microformatted XHTML in my new ‘rohit-flight-info’ model for each paragraph, row, or email.

Microservices

Having vacuumed up the data from multiple site, I’d like to present it for myself. While atoms may have been stored by source-site and date (of acquisition, not the date-of-flight), I need to query for all ‘rohit-flight-info’ across all of them.

Turning to display, the EJAX approach for connecting data-sources to client-side templates is to simply describe the “report” format I want in HTML and indicate in passing which fields I want bound to which elements. Think of it as a very lightweight XSLT, perhaps again trained by examples.

For flights that are in the future and have valid locator-codes, it should also be possible to add HTML forms to the display that link directly to carriers’ services for printing boarding passes, changing seats/classes, etc.

Calculation

With a proper microformat, it seems reasonable to expect Ångströ to parse numbers, dates, and even units – but not to learn more-esoteric rules about bonus-miles, promotions, and fare bonuses. It should be as easy as it might be in Excel to write up all of those rules and come up with a bottom-line on how many miles I have on each carrier.

The second part of the demo is a lookup: comparing those mileage levels to each carrier’s (constantly changing) award charts. This presumes that another process is extracting a meaningful feed from the carrier’s site for each award; it would be straightforward to numerically compare the mileage levels to filter eligible awards.

A scarily-dynamic descendent of this application ought to even tap into additional feeds about my credit-card spending and loyalty-points accumulated in other programs to take advantage of WebFlyer’s conversion planning services to game out various scenarios for how much it would take to reach the next rung of awards.

Ranking

The mileage-junkie’s grail is to have the system also parse all of the promotional email I get from all these partners and recommend strategies for maximizing the portfolio. Imagine popping up an alternative flight to Dulles that instead gets double-points for going through BWI and locks up another award for $25 extra (there are lots of services that will calculate the minimum cash fare – not maximizing total value).

There are some email newsletters I’d like turned into feeds, and websites that feature these offers that could also be turned into feeds. At a minimum, I’d like to be able to filter related offers while viewing my “flight cockpit,” but at best, it could see which offers my friends are taking advantage of (collaborative filtering) or would fit my future travel plans (events evdb recommends…).

Architecture

1. Fission
2. Diffuson
3. Fusion

Microformats: Splitting Pages into Atoms

TPd: Managing a Pile of Atoms

Storage

Search

Ranking according to graphs

Notification

@@you gotta store the state if you’re going to detect deltas… but that doesn’t mean you have to archive it over the long-term.

XGI: Fusing Atoms back into Pages

… dependency-driven recalculation…

…intermediate output states of an XGI script constitute a feed of its own…

MiniML

aka MFML

Evaluation

Do all of these moving parts in concert make CRUD tables easy? Or will it be too compicated to uncover that functionality?

Alternative (motivational) scenarios

“turning the web into a real-time database”

“prioritizing the most-relevant results according to what you’re doing at the moment”

it’s a

• new kind of search engine
• a lowercase-semantic-web knowledge source
• a source for awareness tools like WoWbar

Next step: a compelling storyline/demo that shows off how all of these pieces interact

Applications

Three applications we could build on what we have so far:

• Microsearch — how could we build a “search engine” for all the microformatted data in the world?
• Automagix — how could we write Internet “agents” that react to changes in (microformatted) data, like Apple’s Automator workflow?
• LI Times — how could a newspaper driven off of one’s linkedin profile keep (proactively!) in touch with what’s up in your network?