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