>> 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. > > +1 > > I think there are potential situations where a canonical format is useful > (perhaps Ben could elucidate some of these?), but for Exhibit, I don't > think you need or want a canonical non-js format - the easier it is to > input or output whatever you have and whatever you need, the better. > > Mike, is there a reason for a canonical format in this context that I'm > missing?
Keith, Probably my use of "canonical" creates more confusion than it helps. I'm no believer in "one ring to rule them all" and understand many data formats and serializations will appear in the wild and should be supported if market/use share is sufficient. Some of my recent writings supporting a range of ontology "formalisms" affirm this argument. (However, that is a different matter for the software developer; she needs to decide what the 'canonical' internal representation form should be.) What I meant to refer to in my excited response to Ben was simply the view or presentation layer. With Exhibit, the view is driven by JS and is not indexed by standard crawlers. With RDFa (or eRDF, as well), it is indexed, plus the presentation can be seen by those that choose not to use JS. The purpose of RDFizers, Babel, GRDDL, etc., is to convert one data form to another data form. My understanding is that Exhibit works natively off of JSON. But, if you have Bibtex, Excel, N3, RDF/XML, or tsv, you can use Babel to convert to JSON; you can import Google spreadsheets directly to Exhibit with Exhibit's own converters; or you can use other means further upstream to convert a wild form into JSON, RDF/XML, whatever. In fact, I seem to recall a couple of your own cool posts where you have literally a chain of conversions from multiple sources in order to get the data in a form ultimately necessary by the app. The only thing I was trying to muse about in the misuse of the word "canonical" was whether RDFa could become that conversion target, with Exhibit in turn working off of RDFa rather than JSON. (Or, perhaps more appropriately, the conversion of RDFa to JSON!). That's where my rhetorical question about roundtripping to JSON arose. My only real point was how/what to offer users as a format target that both displays independent of JS and Exhibit could use. As for the need to remove friction that you and Stefano mention, of course, absolutely! Mere mortals want automated background tools to do all of this. But, if those tools existed, I for one would use them to convert my lightweight data sources to Exhibit displays that I could also post as indexable HTML. Mike _______________________________________________ General mailing list General@simile.mit.edu http://simile.mit.edu/mailman/listinfo/general
