I don't see that we need to think about _a_ canonical format at all. There are many different dimensions of quality of various input formats, and none will do well on all of them. As long as exhibit can input and output all of them, The serialization of the data can change as the user and usage of the data changes. RDFa would certainly be a great format to add to the mix, for those who like RDF.
For my own exhibit I find json in a separate file the most convenient/editable format. That loses on searchability, so I currently paste exported exhibit html in my page to be found. That's annoying because it's out of date. I've imagined a hacked solution to that---server-side includes. Assuming they're available in the server, I can server-side include the json file inside noscript tags in whatever pages use the data. Haven't gotten around to trying it out yet though. Stefano Mazzocchi wrote: > Ben Adida wrote: > >> Stefano Mazzocchi wrote: >> >>> Agreed, this <iframe> idea is not that useful if google sends you to a >>> crappy HTML table page instead of your pretty exhibit-enabled one. >>> >> So Keith Alexander's been working on an RDFa importer for Exhibit which >> should make it into v2, and it really seems like the ideal solution to >> this problem: make an ugly HTML table marked up with RDFa, let Google >> index that, and use Exhibit JS to transform that ugliness into the >> beautiful lens'ed view. >> > > Yes, this seems like the only solution so far. > > >> You can even make the HTML table not so ugly so your non-JS-enabled >> friends can enjoy the data. All of this, and no data repetition. >> >> I know I'm an RDFa fanboy, so what am I missing? >> > > The appeal in separating the data from the page comes from the fact that > it's easier to imagine somebody (say, a college professor) embedding > exhibit into their web pages and then use some other web service (say > google spreadsheet or equivalent) to keep their data up to speed.... or > even just publish their bibtex file and let exhibit+babel do the rest. > > The step of having to generate an HTML+RDF/A table out of that data > *and* have to embed it into their HTML page *and* post it/ftp it/webdav > upload it over to their homepage is a *much* less attractive scenario, > so unattractive, in fact, that I doubt such data would be kept in synch > and even less that the exhibit data would become *the* place where such > person stores his/her data primarily. > > I have nothing against embedding RDF/A or eRDF in HTML... I just wish > there was a way to keep the concern of maintaining the presentation > layer separate from the concern of maintaining the data model without > sacrificing the google availability for the two combined. > > If only Google used Crowbar :-( > > _______________________________________________ General mailing list General@simile.mit.edu http://simile.mit.edu/mailman/listinfo/general
