RE: Special vs general schemes

[Travis]
> To take Phil's words to more of an extreme -- Can there even be such a
> thing as a general faceted schema? Facets only seem to make sense within a
> context.

I'll leave that for comment by the LIS experts on this list, but my
impression is that FC can be applied quite successfully to large library
collections.

But I think the inverse is true. That is, given a context (for example, a
product catalog or the knowledge of an organization), it's much, much easier
to develop and maintain a faceted classification for that context than it is
to develop and maintain a "traditional" polyhierarchical schema. (But the
two approaches can be complementary.)

[Travis]

> As for Ranganathan's five-objective-facet approach, I hope we can just
> regard that as early work and move on.

I agree with that, and I think that Dr. Louise Spiteri pointed to several
ways in which the Classification Research Group (CRG) did move beyond
Ranganathan's seminal work. (See "A Simplified Model for Facet Analysis" --
which is now available at
http://aifia.org/pg/a_simplified_model_for_facet_analysis.php.)

I believe that Kathryn La Barre has also mentioned on this list that the CRG
was very practical in its approach.


[Aida]

> While you CAN use fc based on conceptual/general categories to create
> facets for wine bottles. You CAN't use wine bottle facets
> anywhere else but for wine bottles.

Ah, here's where we come to the heart of what appears to be a very deep
difference in viewpoint. I disagree on both points ... with some important
qualifications. (See below.)

[Aida]
> And this is why some of us on this list mentioned that there is need
> to think about the possibility of building on conceptual facet
> categories if the goal is knowledge presentation, ontology etc.
> This is the point where the difference between understanding
> of facet analysis scope comes into focus.

Although the wine-categorization example is a simple one, it is directly
connected to the objectives of a business devoted to the consumption of
wine. The wine categorization facets reflect the stakeholders' understanding
of what's important and essential in that domain.

The "true facets" and topics therein come from (1) those who are deeply
immersed in communication about those topics -- people who are selling,
consuming, and investing in wine -- and, ideally, (2) the dynamic, ongoing
interaction of those stakeholders with the information resource.

So, should the selection of facets and topics for a business devoted to wine
be driven by general schemas? Can they be? My answer is No. Not even if you
have a large number of oenologists deeply immersed in the analysis and
construction of the schema.

But the underlying principles of faceted classification -- identifying
objects by describing orthogonal characteristics -- still work for practical
implementation. In fact, as implementations have already shown, they often
work superbly.

Should we jam the knowledge organization developed in practical
implementations back into a broader conceptual framework of faceted
classification? Or should the broader framework adapt to and be informed by
the real world experience of information seekers?

The answer lies somewhere in between, because the specific wine-selection
implementation may not be a particularly good one, and *mapping* of such
"special" schemas into broader, top-down schemas can be an alternative to
constant revision of schemas for general collections under which specific
implementations may be subsumed.

The wine-bottle facets represent experience in implementation. Is there
nothing we can extrapolate and generalize from that experience? I would be
quite surprised if there were not.

[Claudio]
>Well, I suppose that what can change is the choice of which
>facets are the most useful ones for the organization on hand.
>However, the basic principles of FC were intended by CRG
>members as a guide to develop even _special_ classifications
>and thesauri, and were applied in such a way around the 60s
>to build many schemes.
>
>How could we describe the differences between requirements
>of special vs general faceted schemas?

It's more than a matter of "choice of facets" or "special" vs. "general," I
think.

There are, I believe, some very fundamental differences in objectives and
needs between users within organizations and users of library collections,
whether general or special. (Aida also pointed specifically to the
differences in goals.)

Let me put aside, for a moment, such simple examples as online product
catalogs, in which ad hoc faceted approaches have already shown their
merits.

Let's talk, instead, about organizing the "knowledge" of a business --
categorizing information from reports, presentations, email, meetings,
exchanges with customers and prospects, etc. The primary goal, in business
environments, is to enable stakeholders (employees, customers, investors,
media) to leverage the knowledge of the organization more effectively and
efficiently. The vast experience of the FC community and the broad
categorizations proposed and implemented for both special and general
collections should be more applicable here than for product catalogs.

But there are still some key differences in objectives and requirements,
including:

-- In part because the stakeholders of a business organization already have
a basic shared context, efficiency and currency are far more important than
accommodating every possible context. (Not that you can ever accommodate
every possible context, but public collections attempt to be as
accommodating as possible to a wide range of perspectives.)

-- You want to enable retrieval of chunks of information smaller than books,
articles, presentations, and reports. You're not "doing research" in most
cases. You're looking for answers, rapid understanding, or "actionable
knowledge." For this reason, the organizational knowledge-organization
schema must more closely resemble good back-of-the-book indexes than
library-style subject indexes. (Yes, I know Ranganathan wrote on this topic,
and the Energy facet may be particularly relevant here. But I am not
personally familiar with any public implementations of FC that demonstrate
the useful characteristics of good book indexing. I'd love to see one.)

-- Exhaustiveness of categorization is neither possible nor desirable in
most business organizations. And at some point, you have to point to
subject-matter experts ... who should be categorized according to the schema
in the same way that documents should be categorized.

-- Prolonged effort to find an answer should not be repeated. The experience
of one person trying to find an answer should be fed back into the
classification and retrieval system so that no further time is wasted by the
organization in answering the same questions repeatedly.

-- The schema should be seen as a common element in multiple requirements --
including Web content management, document indexing, and customer support.

-- Evaluation of the merits of specific documents (or information chunks)
retrieved should be fed back into the system. Public collections attempt to
be neutral with regard to the merits of a particular document or chunk of
information. An organization cannot afford such "indifference". Bad ideas,
misinformation, poor categorization, and dated information must be attacked
mercilessly and rooted out or (perhaps better) deprecated.

-- You may (probably must) begin with a foundational schema -- a top-down
construction -- but you must then adapt the schema dynamically to meet the
information needs of the stakeholders of the organization. The knowledge
organization specialists within the organization must continuously monitor
and analyze the queries posed by information-seekers and alter the schema
itself to accommodate the changing needs of the members of the organization.
The principles of FC help make this possible. These principles also enable
much of the hard work of classification to be distributed among stakeholders
... and computer applications.

In businesses, the goal is not categorization; the goal is business success.

    Phil

-------------------------------------------
"I have made this letter longer than usual, only because I have
not had the time to make it shorter."
-- Blaise Pascal, Lettres Provinciales, 1657

Phil Murray -- Chief Knowledge Architect
The Knowledge Management Connection | http://www.KMconnection.com
401-247-7899




----------
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/