joey said:
Really, the only difference I can see between your model and mine is that mine is a server-side, collaborative effort, while yours builds destkop-oriented data islands.
well, you've done some semantic loading there, contrasting "collaborative" with "data-islands". i could counter with "nonpersonalized" versus "individualized", but i don't see much purpose. ultimately, the catalog should work both online and offline. and either approach is capable of it. the real difference is shown when you contrast your system with the wiki system marcello made, which operates in a fashion similar to my system. in your system, tags are applied toward e-texts. in marcello's system (or mine), the e-texts are applied toward categories. that's the difference. again, whether we want to consider that to be a "significant" difference doesn't really matter, as long as we understand that _is_ the difference. all this boils down to the catalogers: would they rather start with a _category_, and apply e-texts, or would they rather start with an e-text and then apply categories. i tend to think it'd be the former. (and certainly, from my standpoint of programmatic cataloging, rather than human-enacted, the former approach is far more easy for me to write code for.) there are still some things you haven't shown us with your example. the first is how nimble it is, once you have scaled it up to the 20,000 e-texts. so i multiplied your 1000-set by 20 times. it's here:
http://snowy.arsc.alaska.edu/bowerbird/misc/joeytags.html at 3.1 megs, it'll be a bit of a pain for dial-up users.
the second is the back-end work that you will do to assign tags automatically. (for instance, although i recognize you were just using it for your example, language tags are unnecessary, because that info is already available in the current catalog, and just needs to be converted.) the third is how you're gonna let your catalogers add new tags to your standard set. the fourth -- a big one -- is how the catalog will be made into a public-facing entity end-users navigate. but none of these are especially _difficult_ challenges, so i'm sure you can manage them, and i look forward to experimenting with your system when it's finished.
And I don't see why they would need to be mutually exclusive, either.
sure, the data can be munged to work either way; as usual, it is just a question of _doing_ that work. and giving cataloger volunteers a choice of models would seem to me to be the best way to proceed... but my mission is not to work with volunteers at all, but rather to build a system myself and then put it directly into the hands of end-users. that's my focus. my gut feeling is that a wiki-style approach will be more successful at attracting volunteers than your tag model, but i wouldn't be surprised if i'm wrong. marcello's wiki has an inordinate level of difficulty; i'd allow people to simply enter the e-text number, and then automatically generate all the other info. having them enter that info (and then formatting all the links in wiki-markup) is a recipe for errors, plus it raises the cost of contributing to the point where i think you would have very few volunteers...
Perhaps you could populate your client-side app with a list of "folders" and "alias files" generated by polling my server-side app, and perhaps people could publish their data island back to the world as a set of tags.
you are welcome to collect data from my model if you want. and just as i'll be getting info from samizdat and blackmask, i'll also collect data from your server-side approach if i can... except i expect to be finished with my effort (limited as it is) before you even get fully started with your (unlimited) one... -bowerbird