Re: Wiki Classification Schemes [Was: Page rename crashed second time around]

Dirk, murray Great input thx.
> It should be easy to select from
>the available WikiCategories when you need them, while you are viewing
>the info.

Yes. Perhaps it should be an attribute of the Page class.
Dirk:
Is the dot notation separate from the page name when using the Namespace
Plugin?

>links generated by a plugin are not seen by the engine
Ouch huge limitation. Is there a workaround to this?
If not all referrences to the renamed page would have to be found and
renamed manually, right?

While looking for an open source wiki project, I was warned that the lack of
namespace
was thought to be a strong arguement against jspwiki.

>
>IMHO, it is very natural and powerful to organize information in a
>hierarchical matter
IMHO, classification systems  often beg to be  refractored and this process
needs to be easy for the user. I remember my early days with MS Studio
where  the ide did not allow you to  change the name of a class. What a
nightmare that was. I grew up pushing Martin Fowler's refractoring methods
way before XP was practiced.

The simplest solution I can think of is to work topdown and create the Page
Index for each category before creating the page itself. This is a
discipline which most users can easily adopt with ease. I wouldn't need any
plugin at all.

As I am still familiarizing myself with the core functionality, are there
any reasons to stay away from the plugins that are not a part of the default
template? IOW, should I study the core pluggins first?




On 8/3/07, Dirk Frederickx <[email protected]> wrote:
>
> @ Claudia and @Murray :
>
> The NameSpacePlugin is really a very simple, convenient plugin.
>
> IMHO, it is very natural and powerful to organize information in a
> hierarchical matter, although there are indeed limitations to such an
> approach. (may be we are all intoxicated by the way computer file
> systems work ;-)
> Wiki's have the capabilities to support much more complex,
> multi-dimensional, categorization.  But I think, JSPWiki still lacks
> good support to help a user to exploit that capability.
> Eg, tagging a page should really by very simple. And not require you
> to go to edit to add category-links. It should be easy to select from
> the available WikiCategories when you need them, while you are viewing
> the info. Probably we would need an extra security level,
> 'page-tagging' , to limit the tagging process to a smaller
> WikiGardener group of people to keep the tagging space clean.
> Eventually, a workflow could help to ensure all create pages are
> getting tagged, etc etc.
>
> Something to be added to the wishlist of v3.0.
>
> - - - -
>
> Claudia,
>
> There are a few issues you should consider before using the Namespace
> plugin, as this is not really integrated in the core of jspwiki.
> Eg: renaming a page inside the hierarchy will not automatically rename
> all pages in the hierarchy; the referenced-by plugin is incomplete,
> cause links generated by a plugin are not seens by the engine.
>
>
>
> dirk
>
> On 8/3/07, Murray Altheim <[email protected]> wrote:
> > Claudia Frers wrote:
> > [...]
> > > In short I just want to have some way of keeping track of what I am
> doing as
> > > the number of pages grow and I am not sure that i trust that a search
> will
> > > make the right page pop up.
> >
> > Hi Claudia,
> >
> > Yes, a common issue as the wiki grows.
> >
> > > thus I have been poking around Multiwikis and categories and
> namespaces and
> > > i assume that it's all about trade offs....
> >
> > To some extent, yes, complexity vs findability. Trying to find a balance
> > that doesn't require users to learn classification schemes, use complex
> > and problematic syntax (ala the "semantic wiki" solutions), or create a
> > nightmarish world of rigid rules, well, there's gotta be an 80/20
> solution
> > here somewhere.
> >
> > > Will copy my answer to him here as well:
> > > Dirk  wrote:
> > > "
> > >
> > > Due to the absence of a hierarchical folder concept in JSPWiki, I am
> using
> > > extensively a dot syntax to group related pages together. (similar to
> the
> > > java package concept) Therefore, I needed a way to generate Index
> pages of a
> > > subset of wiki pages, based on a certain Namespace or page prefix.
> > >
> > > "
> > > Perhaps I am using the wrong plugin. The Namespace Index Plugin seems
> to
> > > give me what I want.
> > > But I still need to test it.
> > >
> > > The multiple categories is a good second choice if I cant get the
> > > NamespaceIndex Plugin to work.
> >
> > I've not tried using the NamespacePlugin so I can't really comment on
> how
> > it works in a production environment, i.e., on whether people can figure
> > out how to use it effectively. My criticism of any such system is that
> it
> > does then rely to a great degree on designing and following a controlled
> > vocabulary of terms. For example, in the example on the NamespacePlugin
> > page it uses
> >
> >     Zoo.Birds.Flamengo
> >
> > which points out a few problems. First, why is the top level category
> > "Zoo"? In most zoological taxonomies the level above birds (the
> zoological
> > "Class" of "Aves") would be "Order". If one wanted to skip the various
> > levels the next might be "Animalia", but skipping levels would be a
> > problem if at some point there needed to be something between "Zoo."
> > and ".Birds". In the case of using "Birds" there are potentially name
> > conflicts with other things that use the same five characters for their
> > common descriptor (since "Birds" is a non-scientific, colloquial term
> for
> > "Aves" that provides no context and is only expressed in English, and in
> > plural -- should it be expressed as a singular or plural term?).
> >
> > Then there's the issue that "Flamengo" is misspelled. I'm assuming
> > someone really meant "Flamingo", but I might be wrong: perhaps
> "Flamengo"
> > is a common name of some other bird or the name of the flamingo in a
> > different language than English. There's also six species of flamingo,
> > which one does this refer to?
> >
> > I'm using the above example to point out the various kinds of problems
> > that *will* arise in any use of a simplistic classification system (i.e
> .,
> > my questions are rhetorical). There can be no simple solution to a very
> > complex problem. We need at a minimum either a means of expressing scope
> > (aka context) or having great flexibility in our navigation and search
> > (e.g., potentially permitting "flamengo" for "flamingo").
> >
> > > To have to remember to add a link on each page is a bit of a strain on
> the
> > > old memory. If I forget to add a link to a page, that page can be
> easily
> > > forgotten. For me, its easier to attach the category as a name
> > > Zoo.Birds.Stork
> >
> > Or how about having the page inherit characteristics, so if you're on
> the
> > "Birds" page you'd only have to attach "Stork"? So that all of the
> > characteristics of Birds are also true of Storks...
> >
> > You may also look into using the QueryPlugin which includes regular
> > expression matching on wiki page names. It probably could be used
> > as an alternative to the NamespacePlugin, but either of them would
> > have many of the same issues, and would require users to learn an
> > arcane query syntax in order to obtain query results. Another
> possibility
> > would be to set keywords in page metadata (like tags) and query on
> > matching keywords/tags. There's stuff in the works for that but
> > nothing available right now that I'm aware of.
> >
> > Murray
> >
> >
> ...........................................................................
> > Murray Altheim <murray07 at altheim.com>
> ===  = =
> > http://www.altheim.com/murray/                                     =
> =  ===
> > SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               =
> =  = =
> >
> >        Boundless wind and moon - the eye within eyes,
> >        Inexhaustible heaven and earth - the light beyond light,
> >        The willow dark, the flower bright - ten thousand houses,
> >        Knock at any door - there's one who will respond.
> >                                        -- The Blue Cliff Record
> > _______________________________________________
> > This is the Jspwiki-users mailing list, in which we discuss the
> > stable release (even-numbered, 2.4.x, 2.6.x), and user-issues.
> > For development discussion, please join jspwiki-dev.
> > http://ecyrd.com/cgi-bin/mailman/listinfo/jspwiki-users
> > http://www.jspwiki.org/JSPWikiMailingList
> >
> _______________________________________________
> This is the Jspwiki-users mailing list, in which we discuss the
> stable release (even-numbered, 2.4.x, 2.6.x), and user-issues.
> For development discussion, please join jspwiki-dev.
> http://ecyrd.com/cgi-bin/mailman/listinfo/jspwiki-users
> http://www.jspwiki.org/JSPWikiMailingList
>