One thing to keep in mind about whole-site statistical tables is that there are already tools to do this for web sites in general, such as AWStats or Webalizer or whatever your favorite may be. We probably should not spend effort to try to duplicate those.
Another consideration is that there are stat.s which would be useful anytime, and stat.s that you dream up once and may never use again, or may only find interesting at irregular intervals. So I think we should be careful not to try to do too much ourselves. We can have some generally-useful stuff built in, but we also need ways to expose the raw cases in a useful form for ad-hoc analysis with general-purpose statistical tools (SPSS/BMD/SAS/Stata/R/whatever). Stuff to be inserted as one component of e.g. an item page probably needs to be built in. Stuff that would be a page on its own should perhaps not be part of DSpace at all, but rather something we make easy to do with other tools. We need to keep clearly in mind the distinction between capturing raw cases (someone fetched a bitstream) and abstracting useful patterns from the collected cases (frequency histogram of this collection's fetches over time, last month's fetches broken down by nation of origin). What might be helpful is to provide some views or stored procedures that stat. tools could use to classify observations. Such tools usually have good facilities for poking around in databases, but could perhaps use help in getting the information they need without having to understand (and track changes to!) the fulness of DSpace's schema. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite.
pgpYBDrredjHV.pgp
Description: PGP signature
_______________________________________________ Dspace-general mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/dspace-general
