Johan Sundström wrote: > I like your thinking, David. Below I'm sorting out additional problems > I think we should, if not even must, address and solve to make it work > well in practice. > > >> David Karger wrote: >> >>> one other question about your method: can I combine it with the standard >>> method? eg put a pointer to some schema in a link from the head while >>> putting actual data into the html table? >>> > > While written with the intention of being self sustained, I think it > should work great without any schema data agreed, just as json xibits work without schema data. my point was that, just as with json, you may want to say a few things about the properties (plural label, type of values, etc) and that (as with several of the xibit examples) it would be reasonable to put this schematic information in a separate place from the data. Even if the data is in the file (for google searchability) I might want the schema elsewhere (for modularity, or to reduce the clutter in my html page). And even if I am using an html table for data, I could put the schema into a json file. > but the ex:type attribute on > the table tag itself, denoting what type of data the table contains, > allowing the rest to sit in your schema files. (And even that > attribute is optional, if you for some reason prefer to add a column > named "type", keeping the same value for every row. I personally find > that uncalled-for verbosity, but it is certainly supported.) > agreed. on the other hand it might be useful to make sure that an analogue to the json schema file can be done in the html table---for example, that properties like pluralLabel that appear in a json schema file could also appear in the table---eg as attributes of the header row of the table. > One thing your whole line of thought -- alternate formats provided > with the same data -- seems to lack is picking a favourite. Which one > is authoritative? As soon as you have data in duplicate (or more) > copies, you have synchronization issues (as the data maintainer) and > canonization or importing uniquifying issues (as the data consumer, i > e the Exhibit code base). I will focus on the latter. Your examples > will all have Exhibit load all of the data files, fetch the data three > or four times and (I guess) end up with four items per intended item > in its presentation mode, which is neither what you wanted nor > resource conservation intelligent. > I think you may have misunderstood my example. My thinking was not that the same data appeared three different ways, but rather that three _different_ blobs of data were represented three different ways. No big deal in theory since they are all being parsed into the same model.
I agree that having the _same_ data represented three times would be awful for synchronization. Given the clutter of html, my assumption is that json or some such would be the format I actually edit, and that I use the cut/paste html technique discussed earlier to create html data only as a publishing step, not for data management. > I would propose picking one of the data formats linked as the > authoritative one (for Exhibit itself, or the browser, as it gains the > support natively) and marking the others as alternate, similar to how > you can provide ten different-looking stylesheets for visitors to > choose among while only picking one of them for presentation by > default. rel="alternate" is the standard procedure, so I would like to > decorate your example into: > > <link rel="exhibit-data" type="application/json" > href="my-data.json" /> > <link rel="exhibit-data alternate" type="application/rdf+xml" > href="rdf-xml-blob.rdf" /> > <link rel="exhibit-data alternate" type="application/n3" > href="n3-blob.n3" /> > > and perhaps toss in a rel="alternate" attribute on the <table> tag > presumed present in the page too, given your original query. The above > would render Exhibit only load and process my-data.json and ignore the > rest (or, assuming there is some load error with that and we are > sophisticated enough to keep trying the list until we run out of > alternatives, the others, one at a time, until we succeed with one). > if these are all about the same data, it isn't clear to me that there is value to having all the alternate links---it isn't like the use of alt in html which suggests different ways to display info by differently abled browsers; clearly anything that can handle the data in one syntax can handle it in any syntax. > All reasoning so far assumes a single data source, one data set per > tag. The <link>:ed resources above all (I believe) may contain a full > data set, including multiple typed subjects per file, full schema data > and so on. The table format can't (requiring one tag per type of > subjects -- as html tables are only two-dimensional and each type > needs a separate set of header cells for naming its properties) and > presently requires one tag per type. Still, in either case it is often > useful to actually split up data into multiple resources you include > separately. > > This creates the issue of dividing resources into equivalence classes, > demarcating resources as belonging to one format, the total sum of > each equivalence class summing up to the complete exhibit. CSS uses > the title attribute to, if you will, add a unique id property for each > data set; I think we ought to as well. Ideally we should tie this id > to a specific Exhibit instance in the page, too (as we should support > multiple exhibit instances running in parallell on a single web page, > IMO -- we do now, anyway). I would find it pretty if this title > attribute is the name of the javascript variable that references the > Exhibit in question (but if we want something else we can certainly > add a level of indirection). > I agree that we want to use naming to be able to address multiple exhibits running on the same page. However, this should work regardless of the data syntax---not only for data represented as tables. So, we want to separate being able to name a particular blob of data (eg a particular table or file) from being able to specify which names appear inside a given xibit. > (If we decide on trying to be intelligent about trying multiple > options for loading an exhibit, if some of the resources making up the > authoritative version linked fail, we add some complications and > implementation overhead in a transactions system to roll out the > incomplete exhibit data set and try the next -- as each alternate data > set might have been split up into multiple resources in different ways > and we have no way of knowing what parts of one map to what parts of > another.) > I think the easy approach is the one taken now---xibit loads whatever it succeeds in loading, and if there are duplicate data then you get duplicates in the xibit. Your data, your mess :) > >> <body ex:ondataload="do something with 'database' variable"> >> ... >> </body> >> </html> >> >> You don't have to have ex:ondataload. By default, that will be a handler >> for constructing an exhibit. But if you have it, then you can do custom >> things with 'database'. >> > > I agree. It is also only useful for the use case "a single exhibit > instance running in the page", which will of course be the most common > case. > > With some of the uncoupling ideas tossed about for future versions of > Exhibit, it might even be a good design only allowing single instance > operation, though I have a feeling there would still be situations > where namespacing different exhibits into their own containers is > useful. > > _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
