Haystack Blog » Web Architectures

How Safari and Firefox handle HTML 5 Manifest files

Edward Benson — Sat, 26 Sep 2009 18:49:16 +0000

I was doing some experiments with Adam in the lab on Friday, and we discovered some interesting variations in the way that Firefox and Safari implement the HTML 5 Cache Manifest specification. I think this is a particularly important feature to have implemented consistently across platforms because it is the make-or-break feature of HTML5 that will permit web applications to function offline.

First, what is the manifest?

For people who haven’t heard about this feature before, the manifest is essentially a special file that lists portions of a web site that should be cached locally for offline access. This is the feature of HTML 5 that will standardize the type of “airplane mode” access that GMail users have with Google’s custom Gears plugin.

The manifest is served as a regular old file, with MIME type text/cache-manifest, and is linked from the html tag itself, as follows:

..

Once a web site is marked as being cached, then the browser will use the local cached copy of all the files specified in the manifest instead of attempting to load them from the internet. Say you’re on an airplane and type in the URL for http://my_cached_site.com. The browser will recognize it as a cached one, load it from its local storage instead, and then use a new JavaScript API to inform the web site that it is running in offline mode.

So now for the important part, how do these two browsers (Firefox and Safari) handle this file?

Firefox

Upon loading an HTML5 document with a manifest attached, Firefox firsts asks permission to cache the site offline before requesting the manifest file from the server. Here is how the toolbar looks on my browser:

And here is the server log (I’m using a Rails project to test this) to show that the manifest was not yet loaded:

If you choose to allow offline caching, the web browser then requests the cache file, as can be seen from this screen shot.

Now here’s the cool thing, I set the headers on the manifest file such that the manifest file itself should also be cached on the client side:


        headers["Expires"] = "Fri, 30 Oct 2010 14:19:41 GMT"
        headers["Cache-Control"] = "max-age=3600, must-revalidate"

And the result of this is that the subsequent load, no files at all are loaded from Firefox — it operates entirely offline. Notice the completely empty server log as I reload the site 2..n times.

Safari

Now let’s look at how Safari does it. Upon loading the web page, Safari also does not load the manifest file, as can be seen from this screen shot:

However, it also does not ask any questions about offline access. The next time I load the web page, something strange happens. Safari checks the manifest file twice and then doesn’t load the actual HTML page (because it doesn’t have to). The double-loading of the manifest file appears to be on the second page load, not split 1/1 between the page departure and subsequent reload. A little strange, if you ask me.

Furthermore, when I reload the page, despite the HTTP headers specifying that the manifest should be cached, Safari reloads the manifest file. Though, at least it only loads it once for every subsequent time:

Conclusion

I’m no spec-master, but it seems like Firefox’s implementation of this feature is what I would want to happen as a web architect, while Safari’s behavior seems a bit strange.

Firefox:

Only loads the web page once
Asks the user for permission to enter offline mode
Only downloads the manifest file once if given permission
Then obeys HTTP Cache Control headers to suppress reloading the manifest file on future loads

If Safari were to also behave like this, there are a few fixes that need to be implemented. Namely:

Ask the user if offline access should be allowed
Load the manifest when the user loads the page the first time (and approves offline mode), not the second time, when the user might be on an airplane
Stop loading the manifest file multiple times in a single page load
Start obeying the HTTP cache headers so that zero web connections are necessary if the cache says so

Safari’s Manifest handling quirks aside, both browser teams should be applauded for so aggressively implementing the HTML5 spec. It is a real treat as someone researching web platforms to get to test the in-progress spec on real browsers instead of just talking about what might eventually happen down the road.

eyebrowse | update and user reactions

Brennan Moore — Tue, 22 Sep 2009 06:48:15 +0000

Today, we rely increasingly on the Web for a multitude of everyday activities that run the gamut from simple queries to complex social interactions. As a result, our browsing patterns are starting to reflect the intricate and multi-faceted nature of our daily lives, but web browsers retain little of the nuanced richness of this information beyond simple “page histories” of previously visited sites. Analytics providers such as Google and Alexa regularly collect statistics of browsing activity, but such analytics are sitecentric and not clustered around individual end-users. Moreover, despite the social nature of web browsing, individuals have little awareness of what others are looking at and how often; while sites like del.icio.us facilitate social exploration, they focus on what people choose to share rather than on their actual habits.

When we created Eyebrowse, we sought to allow users to capture their web browsing activity to examine whether it could help them better understand how they and their friends use the web. Specifically, Eyebrowse allowed people to examine long term patterns in their web browsing activity and facilitates sharing, comparison, and increased social awareness of browsing patterns among friends. and finally, to form a public, democratized corpus of web browsing data for the research community. So, how much are people willing to share, and how does sharing impact the web browsing experiences and habits of the individual?

After three weeks, we have over 200 users sharing selected portions of their web browsing activity. We surveyed some of them and found that public web browsing was most useful to them for seeing socially derived information in context of their own web browsing activity and for viewing other users profiles for the purposes of social awareness and information discovery. Almost all users reported social- or work-related privacy concerns and their comments indicated a fear of being misrepresented by their web browsing activity. To help cope with this we are considering implementing a ‘greylist’ that would hide specific page titles, but track overall activity and multiple whitelists, such as one for home, and one for work.

We plan to continue to grow Eyebrowse into a service that supports social browsing through collaborative filtering and other crowd-sourcing techniques, promotes self-awareness among users of both the patterns in their browsing activities, and provides researchers with useful web browsing data without violating the users’ privacy sensibilities.

Thanks to all our users and supporters! We were recently featured on infosthetics !

Will the Namespace Traffic Jam Kill RDFa in HTML5?

Edward Benson — Mon, 21 Sep 2009 17:44:27 +0000

One of the most exciting aspects of the (in-progress) HTML5 specification is the number of data-centric features it contains. It’s almost as if the committee is saying a big, “OK, OK! We heard you!” to all the data-heads out there and is providing not one, not two, not three, but four different ways to access and manage structured data from within the client browser:

Data Attributes, are key-value pairs that may be added to any DOM node
Microdata provides a way to interweave objects and object-properties amidst the DOM
RDFa provides a way to interweave RDF amidst the DOM
Client-side Database Support provides a full relational data access from JavaScript (the spec says this will be SQL compliant, but in reality it will likely just be the SQLite subset of SQL).

These are all great developments, and will no doubt bring about a lot of creativity about how data can be used on the client-side, but what interests me the most is why the HTML5 working group felt the need to include Microdata alongside RDFa.

The capabilities of HTML5 Microdata and RDFa are nearly identical, albeit with slightly different terminology. Both provide a way to embed data within HTML attributes and tag contents. Both allow for both named entities and blank nodes. And both allow for a variety of more complex constructions, such as lists and HREF property values. One of the only real differences, as I can tell from glancing over the specs, is that RDFa requires URIs whereas Microdata simply uses ordinary strings to reference entities and properties. And that is what worries me: one of the biggest benefits of RDF is its use of URIs, yet URIs seem to be exactly what is preventing the adoption of RDF.

One problem is probably that URIs look funny as data model elements, even to a programmer. “A person has name” is much more natural sounding than “A http://csail.mit.edu/Contact#Person has a http://csail.mit.edu/Contact#name”. We think of our code in natural language terms, and URIs obfuscate our real world metaphors.

Far more serious a problem is the namespace traffic jam that currently exists. If I want to publish an RDF document that describes this blog, for example, best practice would have me draw class types and property types from no less than six ontologies!

The RDF ontology to describe object properties
The RDFS ontology to describe object classes and labels
The Dublin Core (DC) ontology to describe the titles, authors, and the like
The Friend of a Friend (FOAF) ontology to describe my contact information
The XSD ontology to describe literal dates, strings, and numbers
And yet another, custom, ontology to describe everything else particular to the blog

That is already 6 ontologies, and we haven’t even raised the possibility of using OWL Time, Snap, Span, and GeoOWL for things like time and space description! Even for a semantic web developer, the complexity of managing all of these ontologies, and the namespaces that go with them, becomes pretty burdensome pretty quickly.

And that is why I worry about the future of RDFa in HTML5. It appears that the Microdata specification in HTML5 is essentially the RDF graph data model with the URIs neutered out. Given essentially the same data model, no doubt most developers will pick the easier of two formats to implement.

In order to get more people on the RDF bandwagon, we need to make the RDF path just as easy to follow as the Microdata one. How can this be done? If you ask me, the best way is to get rid of this namespace traffic jam and cultivate a set of community-oriented ontologies.

Rather than trying to create base ontologies that address abstract universal concepts, why not try to have each community standardize a single ontology for their particular domain. Have WordPress and Blogger sponsor the Blog Ontology. Have Amazon.com and eBay sponsor the Marketplace Ontology. Have Facebook and MySpace sponsor the Social Ontology. Then, instead of reusing bits from other ontologies, such as dc:creator or foaf:name, have each of these community-focused ontologies be self-sufficient, covering all the concepts necessary for their domain. We can always apply mapping rules to distinguish between social:name and store:book-author-name later. With only a single ontology per domain area to worry about, the namespace traffic jam will disappear and it will be easier for people to get on board with RDF and RDFa.

All in all, it seems the good news coming out of the HTML5 spec is that we can expect rich data annotation to soon be arriving to HTML content everywhere. But what we need to work on as a community is a way to make URIs, and the Ontologies that give them meaning, easier for programmers to use so that the web won’t just be full of data with Microdata, but full of linked data with RDFa.

In Defense of a Semantic Web Wild West

David Karger — Mon, 14 Sep 2009 06:17:23 +0000

A month ago Stefano Mazzocchi published an interesting article on data reconciliation (detecting when two identifiers refer to the same item, and merging them) where he advocated a more centralized “a priori” approach (trying to keep the identifiers merged at the beginning). I posted a response arguing the value of a more anarchic “a posteriori” approach where you let anyone create whatever identifiers and relations they want, and worry about detecting linkages later. Stefano responded to that, but by then I was busy chairing the submissions for the 2009 International Semantic Web Conference. Now that that’s over (I hope you will attend what should be an interesting meeting—October 25-29 near Washington DC) I’d like to pick up the discussion again.

I argued in favor of letting individuals make their own RDF collections (using, for example, our Exhibit framework) and worry about merging them with other people’s data later. Stefano’s response accused me of using “RDF” and “structured data” interchangeably, asserting Exhibit is really just a nice UI over spreadsheet (tabular) data—that although it can export RDF, it is “not properly using RDF” because it has “lost the notion of globally unique identifiers (and in that regard, is much more similar to Excel than to Tabulator)”. Tim Berners Lee has made similar complaints to me about Exhibit not using RDF.

This argument highlights for me yet an important ambiguity about what RDF is. I occasionally have to help people understand that RDF is a model, not a syntax. That some data can be RDF even if it isn’t serialized to RDF/XML. That the key is to have items named by URIs, connected by relations named by URIs. Stefano’s argument suggests a different blurring: between the model and its intended use. Stefano’s “not properly using” phrase implies that if you don’t intend to merge your data into the global namespace, then even if you implement the model and wrote it down as RDF/XML to boot, you won’t be “properly using RDF”.

I want to address both these claims: that Exhibit is just a UI over spreadsheets, and that using RDF this way isn’t proper.

RDF and spreadsheets

Regarding the spreadsheet claim, I’ll begin by admitting that Stefano is absolutely right: Exhibit is a visualization tool for tabular (spreadsheet) data. But notice that all RDF is spreadsheet data—I can take all the RDF in the world and throw it into one spreadsheet. In fact, I only need three columns to contain the subject (tail), object (head), and predicate (link) for each RDF statement. Admittedly none of today’s spreadsheets would have enough rows, but that’s an engineering detail. So, the spreadsheet model isn’t the problem. And we also agree that Exhibit’s interface is nothing like spreadsheets’, and far better for the collection visualization tasks it is designed for.

I think instead that what Stefano is objecting to is a usage characteristic of spreadsheets versus RDF. When I open a spreadsheet, the data it shows me is right there, in a file on my own system. Global identifiers don’t matter because the data is all there (and presumably self-consistent) in the one spreadsheet. In contrast, in Stefano’s image of RDF (and in Tim’s, as one can see from the Tabulator project) the data about a particular entity is spread all over the web, and it is the globally unique identifier that lets you go out, gather all that data together, and know that it is all about the same entity.

This is certainly an appealing vision. But I want to argue that a focus on globally unique identifiers neglects two benefits of RDF that I consider equally important: data portability and schema flexibility.

Spreadsheets suffice

To illustrate this argument, I’ll hark back to a previous post where I discussed a data integration problem that should have been easy but wasn’t. I keep an Exhibit of folk dance videos on the web. Recently, Nissim Ben Ami posted a collection of 511 new dance videos on Youtube. I wanted to incorporate it into my site. But it quickly became apparent that said incorporation would basically require my entering all 511 video descriptions manually into my system, and I still haven’t gotten around to it.

The major barriers were twofold. The first was syntactic:, the structured descriptions of the videos were delivered as XML. That meant that in order to get at the data, I was going to have to learn XSLT—something I’ve been putting off for years. The second hurdle is semantic: Youtube has the wrong schema for my folkdance videos. I care about choreographer, dance type, and year choreographed; YouTube only offers slots for submitter and submission date of the video. So, as you can see from this example, the contributor takes the usual approach: he takes his nice structure data and shoves it into the generic comment (info) field as free text. All that structure is instantly lost.

Suppose instead that spreadsheets (or, in a pinch, RDF) were the accepted framework for publishing information on the web. The YouTube “spreadsheet” would contain submitter and submission date information, but Nissim could just add “artist” and “composition-date” columns to hold the data he wanted to enter. I would then be in a great position to download his data and incorporate it into my own catalog (spreadsheet). What would I have to do? After opening his spreadsheet and mine, I’d have to match columns—perhaps he called his “artist” and “composition date” while mine are “choreographer” and “year”. But a simple copy and paste fixes that discrepancy. Merging entities is not much harder than merging properties: a simple global replace will convert his choreographer “Israel Ya’akovi” to my “Israel Yakovee”. The local consistency of his data and mine means that I only have to work once per choreographer (and in most cases I won’t have to: there’s a standard spelling for almost every choreographer’s name, which serves as a unique identifier in this context even if it isn’t a URL).

Overall, my work has reduced by order of magnitude. Instead of laboriously entering 511 new records, I just download a spreadsheet and match up a handful of properties (columns) and a few tens of choreographer names.

Stepping back, observe that I’ve relied on two things. First, on data portability—my being able to download the data in a convenient form: not XML, which is a programmer’s friend but an end-user’s enemy; rather, something I can just look at and understand. Second, on schema flexibility—on Nissim’s being able to add whatever columns/properties he decides are important, instead of being limited to those used on the hosting web application.

I’m also relying on some features of this particular scenario, but I believe they often hold. I am relying on Nissim’s data having only a small number of properties so that I can map them manually to mine. I also rely on there being a small number of choreographers, and hope to take advantage of most of them having matching names in his data and mine—these names certainly aren’t globally unique identifers, but they are “unique enough” when considering just my data and his. Critically, I am not thinking of pulling all data about a given dance from a multitude of different web sites—this would demand global unique identifiers to link data since I would never have the patience. Rather, I am considering a pairwise data acquistion: taking data I want from one internally consistent site.

Such pairwise acquisition is commonplace: any time a scientists wants to pull a data set from some other scientist’s lab, or a consumer wants to download product information about several cameras from a review site, or a student wants to include a Wikipedia data set in a report they are writing, there is an obvious single source and target for a data merger. And there’s a human being who has the incentive, and with the right tools the capability, to do the limited amount of work needed to accomplish that merger.

This is a simple low-hanging fruit argument. It would be wonderful to be able to automatically merge data from thousands of different sources into a coherent whole. And this is a problem Freebase will need to solve, if they want to become the hub for aggregation of structured data. But right now we can’t even manually merge data from two sites without doing a ridiculous amount of grunt work—so perhaps we should give some attention to that easier problem on our way to solving the hard one.

Don’t skip the wild west

I’d like to so these efforts proceed in parallel, but I’m worried about enthusiasm for the more ambitious goal blocking movement toward the low-hanging fruit. I recently submitted a proposal to NIH on the topic of data integration that reflected my perspective above. I argued that the current efforts in the Biology community to force everyone to adopt a common ontology (and sometimes repository) for their experimental data are being resisted by biologists who think they know best how to present their data. I suggested as an alternative that we give biologists tools, such as Exhibit, that would encourage them to publish their data in a common structured syntax, and worry about integrating all that data after it has become available in structured form. The proposal rejection was accompanied by a review that said, on the one hand, “The benefit of the proposed approach is that it is very different from some multi-institutional data sharing projects (like caBIG), which have used a very rigid, top-down approach to creating semantics. Even if this project is unsuccessful it could bring to light new ideas and strategies that might make those large-scale projects more responsive to investigators and more successful.” At the same time, it argued for rejection because “The absence of any control over the information models and ontologies – truly a semantic wild west – is daring and may ultimately be the downfall of this project.”

I’m fascinated to see, in the same review, a recognition of the problems that the current centralized approach is bringing (lack of buy-in to common ontologies by individual scientists who think they know better and probably do), and an unwillingness to tolerate the contrary (anarchic) solution. I also love the metaphor of the “semantic wild west” because I think it supports my argument. Would anyone have suggested establishing a city of several million people just after the west was opened for settlement? The west’s early wildness was an unavoidable phase of its evolution towards the thickly settled and uniformly governed area it is now. In the same vein, I think that our semantic web is best grown by encouraging individual semantic-web settlers to create their own data homesteads and begin looking for the trails that connect them to neighboring collections. We need to get the data into plain view first. Later we can send in the data sheriffs and place all those data sets under uniform governance.

Introducing “Eyebrowse” – Track and share your web browsing in real time

Max Van Kleek — Fri, 28 Aug 2009 06:55:05 +0000

We’ve launched a service for letting people share, in real time, what pages they’re looking at on the web. Our system, eyebrowse, lets the person choose exactly what sites they want to share their viewing patterns about, and eyebrowse does the rest — producing statistical visualisations of your web browsing habits over time, compared to your friends and the world. It’s called “eyebrowse” and is available here:

http://eyebrowse.csail.mit.edu

It currently requires Firefox/Iceweasel and works on all major platforms. All data that is collected is public and available to anyone who wants it (we do not horde or claim to own any of your data. We like Twitter’s model.) We will soon provide a nice interface with daily tarballs of the database in RDF, XML and CSV.

Why would you want to share your web trails?

1. For Science! It’s not fair that certain Search Engine Companies can do web trail research because they have access to massive repositories of data. There should be public corpora for IR researchers around the world. And these should be OPEN.

2. For your friends! You look at lots of cool stuff on the web every day. You might not think of explicitly sharing every single thing you read. Eyebrowse is lightweight enough that you just have to tell it once per site you want to share. I’ve already discovered tons of weird things that my friends are looking at that they would not have bothered to share explicitly.

3. To understand your own browsing habits. How many times do you read ACM/IEEE every day? I bet you don’t know. Now you can get quantitative statistics and visualise long-term journal revisitation patterns – and other things.

Will it violate my privacy?

1. We give you control. You have to tell eyebrowse explicitly what you want to share on a site-by-site (host) basis. You can take things off the whitelist at any time. You can also go back and delete things that it has logged in the past all through our web interface. It also respects Private Browsing (aka pornmode) and will not log any data regardless during this mode.

2. It fosters contemplation/awareness: We are trying to also raise awareness of what OTHERS (e.g. Google Analytics) are collecting about you as you surf the web, by showing you what you can learn from yourself by selectively publishing your own data feeds.

By letting people selectively publish web trails in an open, non-invasive way, we are hoping to foster a discussion of how we can use our web browsing behavior to build more adaptive and effective interfaces that respect people’s privacy.

Feedback is appreciated. Please email us directly at : eyebrowse@csail.mit.edu

Oh and eyebrowse is free and open source software, licensed under the MIT License. The source is available as part of the list-it codebase here: http://code.google.com/p/list-it

Is RDF any good without a web of linked data?

David Karger — Fri, 24 Jul 2009 05:39:10 +0000

Stefano Mazzochi used to work at our SIMILE project here at MIT, where we explored the use of RDF and Semantic Web tools for the sharing of knowledge. He has since gone to work at Metaweb and, it seems, become much more friendly to their “top down” approach of trying to create a centralized repository of structured data with consistent identifiers, as opposed to letting that data grow all over the place any which way and get linked together afterwards. In particular, he argues for the critical importance of relational density in the data. His point is that when there are many distinct, unlinked identifiers for the same object, then what one person says about one of those identifiers (”Chicago”) won’t be visible to someone looking at a different identifier (”the Windy City”). He opines that “without it [relational density] there would be very little value in it compared to what traditional search engines are already doing”.

Being argumentative by nature, I wanted to highlight some of the benefits of the looser, sloppier approach to data sharing that we took for SIMILE. Obviously, being able to link data from multiple sources, and feed it into a search engine as Stefano describes, is a great thing. But there are some tremendous advantages that accrue when even a single individual decides to create a blob of structured data with no reference to anyone else’s.

The first is interaction. As shown with our Exhibit framework (created by David Huynh, now also at Metaweb), structured data enables rich visualization. If my data objects have coordinates, I can plot them on a map. If they have dates, I can put them on a timeline. If they have colors, I can filter or sort by color. It doesn’t matter if I call those properties latitude, longitude, date and color, or northSouth, eastWest, sinceTheCreation and elementOfTheRainbow, and whether I decide that my city is Chicago or the Windy City—as long as I have my own internally consistent names for them, I can use them to hook my data into interesting visualizations and interactions.

The second benefit is portability. If I publish some interesting data as part of an HTML document, then anyone who wants to use that data for something else—to rebut my argument, to mash it up with some other data, to put it some use I never thought of—has the unpleasant job of scraping said data out of the HTML into a usable form. This generally requires a programmer, and even for them it’s a tedious task that distracts them, and may deter them, from what they really want to do with the data. But if that data is published as data—even in something old fashioned as a spreadsheet—it becomes way easier to grab it and reuse it. Look at how much of the blogosphere is made up of cross-references, trackbacks, and responses to other blog postings. If you’re going to argue about something involving data—for example, whether a single payer system is going to end up saving or costing money, or whether today’s perfect game is all that unusual—you probably want to publish that data to support your argument. At which point, someone who wants to refute your argument is going to want to use that same data. That’s going to be a lot easier if they can get that data from your posting. That’s the theory behind our Datapress project, which aims to let you post data sets (and visualizations of them) in your Wordpress blog, and lets other people refer to and reuse that data. In that sort of one-on-one debate over data, it really doesn’t matter whether I use the same identifiers as Freebase—you can take my identifiers and use them to build your rebuttal.

Uniformity does start to matter when someone wants to mash up data from multiple sources. If those sources haven’t agreed on identifiers beforehand, then the masher has some work ahead—this is a case where a centralized vocabulary is really helpful. But again, getting the data at all is such a big jump over the current state of affairs—I imagine how grateful mashup makers would be if all they had to do was merge some identifiers instead of retyping a whole spreadsheet from scratch. The point here is that unlike Stefano’s hypothetical search engine, that wants to issue a query against all the world’s data at once, your typical mashup author just needs to deal with a couple of (probably small) data sets. His or her particular data integration problem is quite manageable a posteriori.

I’ll also dust off an argument David Huynh once made to me, even if it might get him in trouble with his current employer. Unification is not an absolute, but contextual. Whether two things are the same may change depending on what you are doing with them. Continuing my never-before attempted forays into sports analogies, are the Brooklyn Dodgers the same as the L.A. Dodgers? If you want to talk about the team that moved from Brooklyn to LA, the answer must be yes! But in a different context you might be interested in comparing the lifetime records of these two distinct teams. (In fact, Freebase tries to have it both ways: it asserts that the Brooklyn Dodgers were “later known as” the Los Angeles Dodgers (implying they are the same team with a name change) but asserts that Los Angeles Dodgers were founded in 1958, which clearly isn’t true of the Brooklyn Dodgers that folded in 57.)

This is obviously one of those half-empty half-full debates: We both recognize the value of both approaches, but are compelled by different aspects. Stefano looks at the amazing things that could be done with a single consistent data universe, and worries about how to create it. I look at the amazing things that can already be done with a host of disjoint but internally-consistent data microverses, and find that compelling enough to allay any worry about whether we’ll ever need http://www.freebase.com/view/en/lion to unify with http://en.wikipedia.org/wiki/Lamb .

A Simple Extension for Microformat & RDFa Table Support

Edward Benson — Tue, 19 May 2009 14:01:48 +0000

Microformats and RDFa provide a way to interweave semantic markup within a web document so that structured information can be more easily extracted. Both Microformats and RDFa follow the hierarchical model of HTML: structured data to be extracted may exist spread across several layers of the DOM

hierarchy. A pseudocode example of this is below, where we see that the statement is spread across three levels of the DOM Tree.



   
      Hamburgers

A wrinkle in this hierarchical mindset is the fact that a great deal of structured information on the web lives in the one HTML construct that does not fit a hierarchical representation: tables.

Consider Wikipedia, as just one source of structured data virtually begging to be annotated with RDFa. On many Wikipedia pages one of the first things that catches a visitor’s eye is the “Info Box”. This is a small box containing a structured summary of the key factual items on the page. Equally important is the way in which Info Boxes are populated: they begin their life as templates — the “Capital City” or “Baseball Player” template, for example – and all the Wikipedia contributor has to do is fill in the empty field values.

Microformats and RDFa are able to mark up tables, such as these Info Boxes, but they do so in a suboptimal way: they require repetition of semantic markup across each row (or column, depending on the orientation of the table). This:

Is redundant from a representational standpoint
Clouds the ability of a data enhanced web browser to infer that entire rows and columns of the table talk about the same thing.
Forces the template writer to put markup within the table body, rather than on its column and row declarations

To cure this, here is a simple proposal to add table support to both Microformats and RDFa. It is compact, needing only a single sentence to describe:

When parsing the DOM to extract embedded data and a element is encountered, treat its corresponding element as if it were the DOM parent of the element for that cell.

The problem with tables is that a table cell (TD) is contained in HTML by its row (TR) but not its column (COL) because of the way HTML works. This means that when we use tables and microformats/RDFa together, we’re stuck: we can put information across each row, but not down each column. So the proposal is to make a special case for table columns when it comes to pulling out structured information in the cells: even though the cell isn’t technically contained by the column element, pretend that it is.

Let’s see how this cleans up the representation of a simple table of president names. This table has one president per row: Thomas and John.

Here is a pseudocode example of how microformats/RDFa currently require such a table to be marked up. Notice how the “first” and “last” properties needed to be repeated across each row.


  
  
  

First Last
Thomas Jefferson
John Adams

First	Last
Thomas	Jefferson
John	Adams

If we allow structured content to live in the elements, then we do not need this repetition:


  
  
  
  


First Last
Thomas Jefferson
John Adams

First	Last
Thomas	Jefferson
John	Adams

When parsing either of these two tables for data, we extract the same information:

:tj :first “Thomas”
:tj :last ”Jefferson”
:ja :first “John”
:ja :last ”Adams

Tables are all over the web, and they make great templates to assist users in entering structured information. This small change to the semantics of microformat and RDFa parsing should allow a cleaner syntax for publishing both data and data-templates, easing the adoption of the respective

formats.

Making the Case for Raw Data

Adam Marcus — Tue, 24 Mar 2009 14:46:05 +0000

Tim Berners-Lee’s recent TED talk on Linked Data has inspired quite a few people to ask what exactly linked data is, how it differs from data on the semantic web, and how realistic it is to assume universal and unique addressability of data items. A world with linked data would be a world with richer, more explorable data, and that notion on its own makes Tim’s talk worth viewing. The most inspiring part of his talk, in my opinion, was the one in which he got the entire crowd to loudly demand RAW DATA NOW. Given the push for more open datasets in government, and given that more websites are becoming API-providing data platforms, it is important to demand raw data where possible.

The magic behind raw data

The best thing about raw data is that almost everyone knows how it works. This means that as far as the data (re)user is concerned, the datasets are text files (or perhaps a close variant) that they can download, open in some default application, and get some immediate use out of it.

If the US Federal budget dataset is released as a comma-separated file, a middle-schooler can download the file, open it in a spreadsheet application, and sum the columns to see how much we’re spending on the Department of Education this year. A more skilled high-schooler can upload the file to Many Eyes, make a pie chart out of it, and post it to their blog. A first-year college student can write a php script to allow people to comment on various parts of that pie chart, allowing you to drill in to various slices to get a finer granularity.

With raw data, you’ve opened more people to more visualization, exploration, and discussion than was available through the original web application that acted as a firewall to your database.

Hugging the data to death

During his talk, Tim spoke about “Database Huggers,” or people who, for various reasons, hide their data away in databases. Once the data sits in a database, the publisher might provide a specific and constrained view of the data by way of a website, or they might hide it even more, simply calculating some aggregate statistic over the data and claiming, without verification, that the data has certain properties.

There are several legitimate reasons for database hugging. Some data was meant to be private—academic, medical, and financial information are all datapoints we’d prefer to keep private. We’d hope our service providers will keep it out of the hands of others. Similarly, a company might have competitive reasons for keeping information private, especially when it would be equally valuable to their competitors and not too valuable to the public—lists of customers and transaction histories come to mind. Keeping this information far from the publicly accessible web is responsible and wise.

There are other cases, however, where the data should legitimately stay open and publicly accessible. Open government initiatives will result in many datasets published by organizations that will or should exist in the public domain. Many Long Tail websites, maintained by small groups of hobbyists, probably would not mind if the datasets they generate are published in their full glory. For these types of applications, raw data is ideal.

Even in the case of datasets that should be open to the public, database huggers will sometimes disable direct access to the data, instead opting to place it in a database that sits behind an html-generating web application. Thinking that you’ve hidden your data behind HTML, thus making it safe from reuse, is an unwise assumption. In about an hour, a decent programmer can write a perl script to crawl your site and tease the data apart from the obfuscated HTML that surrounds it, reverse-engineering your database without asking for permission. In fact, there are tools that make this process easier than writing a one-off perl script. And if you think you can block the person from accessing every page on your site in a short period of time, then they will just collaborate with everyone else who wants the data, write a Greasemonkey script to collect parts of the site that they browse, and eventually collect your entire presented dataset.

Databases are not inherently evil. They provide an excellent way to store, index, and query data, but they also have a way of separating the average user from that data. Most websites, for example, do not publish a read-only username and password to their database, for fear of arbitrary queries that could easily take down their machines, or at least keep the machines busy for a long time. We should design tools to maintain the excellent services that databases have been built to provide over the last four decades, without limiting the access to the raw data when such access would be most valuable.

Are APIs the future of raw data?

There is a middle ground between the highly private datasets and the obviously open ones. Most forward-thinking organizations have realized this. They have also realized that if they have something to sell, be it in meatspace or screenspace, it’s better to release the data about their offerings to anyone that wants to use it, so that people eventually end up at their site. They do this by providing a web API to make their dataset queriable, essentially telling other software developers which questions they can answer about the dataset (query for books by author, query for restaurants by cuisine). Amazon has some APIs, as does Yelp, and you’d have to be a pretty self-loathing web 2.0 company to not provide an API over some portion of your data. So are APIs the solution? Not always.

APIs are a step in the right direction—open data is better than obfuscated data. APIs help both third-party developers and dataset publishers get more out of a dataset. They have a few drawbacks as well:

The API is an HTTP interface to your database. This means that if someone else makes a third-party application that is immensely popular, it’s your database that pays for the brunt of its popularity. You weren’t expecting a huge ramp-up in server load? Too bad.
As kind as the dataset publisher is, they can’t predict every use of the data—if they could, they already would have implemented the best use cases. If they can’t predict how the consumer/developer will use the data, they might not publish a good hook into the dataset. This would either prevent or make awkward the interaction between the third-party application and the publisher.
Building an API for a dataset makes the people who are nice enough to share their data do more work on top of designing their application. Following common REST or CRUD conventions makes this easier, but still puts the onus on the developer. As a corollary, APIs don’t change with the data. APIs are frequently revised, meaning that a change in your data requires constant upkeep of your API.

One might argue that some of the criticisms of APIs are unfair:

Saying that raw data will reduce the load on your database implies that the third party has some cache of the data, which is thus slightly out-of-date. You could imagine some sort of Comet-updated raw dataset system, but it’s unlikely for now that dataset publishers will be willing to stream live updates to third parties.
Perhaps the limited API functionality is for good reason. Amazon might never want you to be able to download their entire dataset—they don’t want to waste the bandwidth and they don’t want competitors to know exactly how many items they have on hand.
Publishing any sort of raw data will require extra work on behalf of the dataset publisher. Perhaps API-writing is the least invasive of their time?

An ideal data management tool would allow raw data publishing when possible, and make it easier to build APIs when some limited access is desirable. We should not pretend to know the point at which raw data is superior to APIs, but the point exists somewhere. It’s important to understand the benefits that raw data provides on top of web APIs, so that you can think about when it would be valuable to use.

After all this time, the answer was text files?

You’ve probably become skeptical of these suggestions. Are we really supposed to throw away decades of database research in how to properly store, index, and query reasonably sized datasets so that a middle-schooler can look at the data in a different way? Of course not. The interesting research question becomes whether we can give the user the illusion of raw data while still benefiting from database technology where possible.

That’s one research direction we’re taking within the Haystack group. With the constraint that the raw data, in human-readable text files, should always be available, we’d like to blur the boundaries between databases and data-aware webservers.

Specifically, what we plan on designing is an apache web server module that recognizes when it is serving a dataset, perhaps by taking note that it is serving a .csv, .rdf, or .json file. In such cases, the server would cook the data into a database behind the scenes. Data-aware clients (in javascript for the time being, but in the browser one day) can then query the web server about the data directly. Updates become difficult, but we can make consistency guarantees about the original raw data text files to ensure that someone can download them and see up-to-date information.

If you prefer programmatic access to the files, the module turns into a REST(, SQL, SPARQL, you favorite path language)-capable endpoint. If you prefer to get down and dirty with the data, you’ve got the text files.

We certainly don’t want to stand in the way of a world with Linked Data, so if you’d like, the tool will eventually return data with URIs. We can’t guarantee the URIs will resolve to anything useful, but that just might require a human’s touch. We’re not sure how that fits into the picture for the average data publisher, since the marginal benefit to the individual of universally addressing your own data is small, whereas the benefit to everyone else of adding another linked dataset grows with the number of datasets it is linked to.

And now, for some questions

We’re early in the development of our tools, so we’re open to your ideas and suggestions. Keeping text files up-to-date with the database that’s proxying them is nontrivial. Thinking of the ideal client/server mode of operation will also take time. We probably haven’t thought of the most important must-have feature yet, so any suggestions are welcome.

Thanks to Ted Benson, Sam Madden, and David Karger for their thoughts on this post.

(Cross-posted on my blog)

What’s Wrong with SQL?

Eirik Bakke — Tue, 17 Feb 2009 04:27:33 +0000

A lot of things, Mike Stonebraker might say, but I have something rather fundamental in mind.

Suppose I’m developing some sort of academic course management system. Chances are I’ll want to display to the user a list of course offerings and their associated course codes, readings from the syllabus, meeting times etc. Maybe something like this:

Now according to Good Rules of Normalization and Decency, I probably stored this data across several database tables, related by foreign keys. I might have tables named “offerings”, “course_codes”, “readings”, “sections”, “meetings” and so forth. So how do I retrieve all this related data from the database?

The good news is that relational databases are made for just this kind of task: joining tables efficiently is what they do for a living. Unsuspectingly, I run my query [1]:

SELECT o.title, cc.code, r.author, r.title, s.name,
       m.start_time, m.end_time, m.day, m.place
FROM   offerings o, course_codes cc, readings r, sections s,
       meetings m
WHERE cc.oid = o.id
AND   r.oid = o.id
AND   s.oid = o.id
AND   m.sid = s.id;

The bad news is: That didn’t work too well. The mistake may seem obvious to seasoned database application developers: I can’t just do several unrelated joins in parallel like that, or I’ll get a gazillion rows [2] back. Not only does this lead to exponentially bad performance, but the result is also in a rather annoying form as far as the client application is concerned. There is even another problem: if any of the courses in the database do not happen to have any sections or readings listed, they will be omitted from the result. SQL “fixes” this through a hack known as outer joins. It introduces NULL values into the result and, rather undeclaratively, requires each join to have its particular join condition specified explicitly rather than as part of the more general WHERE clause.

So how do we retrieve data like this from a relational database? We pull the joins out of the database and evaluate them ourselves, in our own application-specific data structures. Just about every non-trivial database web app out there does this in some way or another. The data is stored across multiple related tables in some MySQL or Postgres database. When the Javascript in the end user’s browser needs to present data to the user in some hierarchical fashion like the example above, it issues a request to a server-side middle layer, written in PHP, Ruby on Rails, Python, Java, awk or whatnot. The middle layer, possibly with the help of a persistence library, then issues a bunch of separate SQL queries to the database to retrieve all the data involved, assembles (read: joins) this into some hierarchical data structure, and returns it to the Javascript app in JSON or XML form. True, the database does help limit the data enough that this assembly process is not too much of a performance concern. But joining tables is the job of the database, and we shouldn’t have to write middle layers to do it ourselves.

There should be a general and declarative way to make big joiny queries like the above work efficiently, returning the data in exactly the hierarchical form we want it — strictly relational result sets are not expressive enough. I am currently working on a simple SQL-like query language that does just this: send my generalized middleware a single big, declarative (no for loops or outer joins here!) query, and you’ll get back the JSON equivalent of the relational result set with the data nested into arrays and objects any way you want it.

[1] “No one does this!” some may object. Actually, Ruby on Rails’ own ActiveRecord did for a while.
[2] I believe the technical term is “The Cartesian Product.” Darn you, Descartes.

Building a content management system just by drawing the web forms

David Karger — Tue, 06 Jan 2009 20:37:19 +0000

This is a nice talk by Kian Win Ong of UCSD called “Do It Yourself custom forms-driven workflow applications.” They’re looking at all the work people invest building special purpose content management systems that really offer users little more than “CRUD” (create, read, update delete) interactins for certain specialized kinds of content.

The basic approach is for the owner to manipulate the visible parts of the system—the forms that people use to enter data, and the pages that show the data in the system—and for the server to automatically create the schemas and databases needed to support those interfaces. For example, if the owner adds a field in the form, the backend will add a field in the back-end database, without the owner knowing anything about that database. This class of tools are known as “forms driven applications”.

The main contribution here is that an important part is to manage “workflows”—they way content is entered and then flows through various stages of the system, evolving and changing who can and should see it as it goes. There needs to be a notion of roles and access permissions, and for pages to behave differently depending on both the state of the data and who is accessing the page. It’s hard to do this if you only work with one page/form at a time. Their tool tries to provide “guided debugging” of the entire workflow, suggesting the next steps that should happen to a particular piece of data, data it should be combined with, and roles it should be assigned to.

These ideas have been pushed into a startup called app2you. I quite like the approach and hope it is successful.