[Sigia-l] Taxonomies & Navigation

Mon Aug 27 00:47:16 EDT 2007

Taxonomy, taxonomies, classification, navigation, etc...etc...etc...

It all depends on the context of  what you are doing. Context is the
key to this whole thing. If you don't understand the context none of
the terms will help you.

understand the context ad define what is it you actually need, every
one of  those terms are used as synonms depending who , which
organization, which function or dept etc...etc..

Its all Context.

Regards,

Jay Kumar

On 8/27/07, Filip Borloo <filip.b at gmail.com> wrote:
> On 26/08/07, Filip Borloo <filip.b at gmail.com> wrote:
> >
> > Coming back to the original question, we typically differentiate between a
> > taxonomy and a navigation by making a difference between the offer and the
> > demand for content.
> > The offer is where the content is created and typically this is a
> > structured environment where each peace of information can be placed in a
> > unique box. Furthermore each peace of information comes with a set of meta
> > data explicit (added by the author) and implicit (added by the "system").
> > This is a taxonomy, a means of classifying information where each individual
> > peace exists only once and has a unique address (as such a paragraph has a
> > unique place within a document which has ... ).
> > On the demand side you want to work according to the expectations and
> > needs of your users and, unless you work in an environment where each user
> > has the same level of knowledge and experience, different users will use
> > different paths to come to the same information. This is the navigation
> > where one peace of information can occur in different places based on the
> > different dimensions your navigation has. You can find it on a page aimed at
> > a specific audience, about a specific topic or related to some other
> > information.
> > Between the offer and demand is where your CMS should sit and allow your
> > site team to make the link between the incoming information (in the
> > taxonomy) and the outgoing information (in the navigation).
> >
> > Filip
> >
> > On 26/08/07, Ruth Kaufman <ruth.kaufman at gmail.com> wrote:
> > >
> > > Ziya wrote:
> > > > The drastic and scalable solution lies in a totally different
> > > direction:
> > > > eliminating 'documents' altogether by giving access to live, real-time
> > > > 'views' of the data, customized just-in-time for specific uses and
> > > users.
> > > > Multi-dimensional metadata can allow the architect to shape the 'view'
> > > in
> > > > amazing ways, not possible with frozen docs, thereby eliminating the
> > > need
> > > > for users to actually 'navigate'. Taxonomy dissolves into
> > > multi-dimensional
> > > > (not faceted) metadata and rarely needs to be exposed to the user. Of
> > > > course, there's a rules engine running in the background,
> > > orchestrating the
> > > > whole thing.
> > > >
> > > > No docs: not much to store, version, maintain, archive, purge, etc.
> > > And no
> > > > formal navigation, either.
> > > >
> > > > This gets complicated, if one's not used to dealing at this level of
> > > > abstraction and integration, but the power therein is undeniable. I
> > > intend
> > > > to write about it in detail in a blog or something, one of these
> > > months.
> > >
> > > Another POV on scalability, complexity and overhead costs for a
> > > non-document content model: (Caveat: my background is with very
> > > large-scale systems, and that colors my POV)
> > >
> > > Complicated, indeed. When attempting a fragmented content model, in
> > > support of a page-less, document-less experience and content strategy,
> > > respectively, expect to build in  the overhead you'll need for
> > > creating and managing a significantly more complex data model.
> > >
> > > It's important to think in terms of user objects. What this means is,
> > > if your users will expect to find documents, like white papers, maybe
> > > it's a good idea to keep them intact so that your system doesn't have
> > > to build them each and every time a user requests one (i.e., by
> > > clicking on the corresponding link). This is assuming that your
> > > content is separated from your navigation components in the first
> > > place. In the case of content types that are, in the real world,
> > > documents, a larger content object from which elements can be selected
> > > and extracted can be more useful than a disconnected pile of smaller
> > > content objects that need to be assembled in order to display
> > > something coherent.
> > >
> > > One of the reasons, and tying this back to taxonomy and metadata, is
> > > that you'll ultimately need at least 2 "taxonomies" for "content
> > > type".
> > > 1) The first to support your users -- to catalog the types of content
> > > and information objects they came to your site to find and explore in
> > > the first place, regardless of how these things are stored and managed
> > > in the back end. This may include document types, but may also include
> > > things like tools, search interfaces & search results, dashboards...
> > > anything from the real or digital world, that they may expect to find
> > > or access on your site.
> > >
> > > 2) The second to support your authors and content owners -- to enable
> > > their user experience with the CMS. "I want to upload a press release"
> > > or "I need to modify my product description -- features  &
> > > benefits"...
> > >
> > > As both of the above are about "perceived" content types -- sometimes
> > > rolling up to genre-like categories, you'll also need some
> > > classification of the digital nature of the content and of the posture
> > > of the content. Both of these dimensions have something to do with the
> > > concept of "format".
> > > 3) Digital nature -- this is like MIME type, but in my experience,
> > > I've needed to create my own list of allowed values... it's easiest to
> > > just think of it as MIME type or data type and to figure out what your
> > > project, site and/or systems particular needs are when the time is
> > > right.
> > > 4) Posture -- the interaction paradigm that the content follows. For
> > > example, "webcast" is a posture, not a content type, as in #1 above. A
> > > webcast is the paradigm in which an event, interview, earnings
> > > announcement, etc. is delivered. (Event, interview, and earnings
> > > announcements are examples of #1)
> > >
> > > That's complicated enough.
> > >
> > > 5) Now, if you're also going to deconstruct your #1s into
> > > paragraph-level fragments, you're  going to need standards and a data
> > > model to enable (re-)compilation of these fragments into something
> > > meaningful to end-users. In truth, you would need to label
> > > paragraph-level objects even if they are part of a document-based
> > > content model, as you're most likely storing these in XML -- you'd
> > > need some kind of <paragraph> tag to encapsulate each content block.
> > > The difference is that now you're going to need to further type these
> > > blocks (i.e., what type of paragraph? ...similar to the spirit of #1),
> > > and you're going to probably need multiple systems to understand this
> > > expanded vocabulary. What I mean by this is that it's no longer your
> > > "local" CMS that needs to know about the granular intra-document
> > > objects, but also your rendering system, search system, etc... of
> > > course, all depending on when and where, in your system landscape, you
> > > compile these fragments into something meaningful for the user.
> > >
> > > Of course, this is easier if the content at hand is born of the
> > > digital world in the first place, like the content of micro-blogs. But
> > > keep in mind that even micro-blog entries, as fragmented and
> > > disconnected from each other as they tend to be, may also be parts of
> > > a larger "conversation" or "event"...
> > >
> > > (Sidebar: it's important to consider, but not assume, that compiling
> > > fragments into complex objects will happen on the fly with the help of
> > > portal software. This "on the fly" process may be resource intensive,
> > > and your architects may ultimately opt for pre-compiling and caching
> > > certain combinations of fragments and objects.)
> > >
> > > So to sum it up, my word of caution is -- before you start unpacking
> > > your content into a fragmented model, do some cost-benefit analysis
> > > and consult with your system architects, data architects and
> > > developers. The bigger your system and ecosystem, the more expensive
> > > managing smaller pieces becomes. Not to say that there isn't benefit
> > > (or beauty) to this level of complexity. This s more to say that
> > > scaling your content model requires deep scrutiny -- what MUST be
> > > shared,  extracted, and/or compiled in real- or near-real time based
> > > on rules (for both operational efficiency and the users' benefit, of
> > > course) v. what CAN be... very different questions to answer.
> > >
> > > thanks,
> > > Ruth
> > > ------------
> > > IA Summit 2008: "Experiencing Information"
> > > April 10-14, 2008, Miami, Florida
> > >
> > > -----
> > > When replying, please *trim your post* as much as possible.
> > > *Plain text, please; NO Attachments
> > >
> > > Searchable Archive at http://www.info-arch.org/lists/sigia-l/
> > > ________________________________________
> > > Sigia-l mailing list -- post to: Sigia-l at asis.org
> > > Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l
> > >
> >
> >
> ------------
> IA Summit 2008: "Experiencing Information"
> April 10-14, 2008, Miami, Florida
>
> -----
> When replying, please *trim your post* as much as possible.
> *Plain text, please; NO Attachments
>
> Searchable Archive at http://www.info-arch.org/lists/sigia-l/
> ________________________________________
> Sigia-l mailing list -- post to: Sigia-l at asis.org
> Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l
>