Re: FAST and GRIS

> Fully agree with your points. But the quality of a dish
> depends of the ingredients you put in :-)


True and I pretty much agree with your points. Semantic
interoperability would be A Good Thing, and LCSH is ugly and messy
which makes FAST a suspect solution.

But let's ignore the detais of FAST for a minute and look at the
problem in more general terms.
 
  (this turned out much longer than I expected; sorry)

First, the domain we are talking about is large scale,
international, and standardized vocabulary control. This means LCSH,
LCC, Dewey, AACR2, MARC (to a degree), and yadayadayada. Yes, I am
deliberately stirring catalaloging and classification standards and
practices into one big pot.

Second, this domain is facing The Mozilla Problem, or TMP (tm).

TMP is characterized by two elements:

  1. The recognition that the current solution is well known and
     widely used, but it's also big, unwieldy, and basically sucks.

  2. There is a strong desire to fix it. However, there are two basic
     ways of fixing it and neither way is appealing. Both involve
     a lot of risk, time, money, blood, sweat, tears, etc.

What are these two ways of fixing things?

The first way is the Bubblegum & Twine method:

  You just sort of patch things up as you go along and slowly
  transform your beast into a beauty. The process is slow and when
  you're done you've probably got that lingering ugliness down deep,
  but it works within the system. Critics of this approach will say
  that you're just putting lipstick on the pig, and not really
  fixing what needs to be fixed.

  This is essentially the strategy that we've had with LCSH (hence
  the pseudo-facets that have been tacked to it; DDC has done
  something similar). 

  This is also the FAST strategy, but instead of patching LCSH
  directly it adds a layer of abstraction to it, which should
  sorta-kinda-maybe hide the stench rising up from the deep.
  
The second way is Let's Start From Scratch, immortalized by Fred
Brooks in the aphorism "plan to throw one away, you will anyhow."
 
  This is what it sounds like. You throw out everything, except the
  knowledge gained from the failed first attempt, which is applied
  to construct a new design that will be sleek and clean and
  powerful and wonderful. All the crud will be swept away and when
  you're finished you won't have any lingering ugliness way down in
  the deep dark recesses of your new world order.

  But starting from scratch is risky because it will take a looooong
  time, the design will be overly ambitious, it might not work,
  people might not use it, or--worst case scenario--IT MIGHT NEVER
  GET FINISHED! 

  Even so, this choice is appealing to the engineers in the crowd.
  Not only do you get to Do It Right This Time, but you get to solve
  a really-big-seemingly-impossible problem: a wet dream for a good
  engineer, who loves nothing more than solving seemingly
  intractable problems (disclosure: my first degree is engineering,
  think what you want).
  
This is the choice the Mozilla folks were facing with Netscape 4.x
back in early 1998 (hence, TMP). The basically sat down and said "Do
we keep patching this hunk of junk or do we throw it out and do it
all over again?"

They picked door number two--the utopian road--and FIVE YEARS later
delivered a replacement which was slow and bloated but really
powerful (and pretty good if you got enough juice), so they started
a sub-project called Firebird (formerly Phoenix) to create a simple,
lightweight, but first-class browser. Firebird is still in beta and
by the time they hit 1.0 it will probably be SIX-PLUS years from the
day they open sourced the Mozilla code.

Software guru/gadfly Joel Sposky wrote a great essay about how
Mozilla made "the single worst strategic mistake that any software
company can make." But then again, he has rightly praised the
Firebird browser.

  Things You Should Never Do, Part I
  by Joel Sposky, April 6, 2000  
  http://www.joelonsoftware.com/articles/fog0000000069.html

Now then, myy examples are drawn from the software domain, but we
are facing the same fundamental choice in this domain (that is,
large scale, international, and standardized vocabulary control).

One major difference between these two domains is time scale.
Rebuilding a major piece of code could take years. Rebuilding a CV
the size of LCSH would take decades. Ouch!

The FAST paper recognizes this fact and proposes a solution. The
solution goes down the first road, but with a twist. Previous
travellers have focused on fixing LCSH directly. FAST adds a layer
of abstraction instead.

I think this approach has merit.

But yeah, the engineer in me says blow-it-up-and-start-from-scratch.



--karl

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/0bmwlB/TM
---------------------------------------------------------------------~->

----------
Thanks for playing. To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/