Tags:
create new tag
, view all tags

Topic Not Found In This Web

When it says "Topic not found" I am thinking about getting it to check in a set of other webs (definable from the sourceweb in WebPreferences), perhaps showing them in BookView.

Has anyone else implemented this?

-- MartinCleaver - 04 May 2001



Let me give an example:

Say someone were to work for a company called BigTimeConsulting (BTC) which had divisions for Audit, Tax, Legal and BusinessConsulting (BC).

Every person in BC then belonged to:

  1. a group such as Technology, People or Process, and
  2. a specialism such as KnowledgeManagement or DataManagement
  3. an industry team

Furthermore, each person then worked on one or more projects.

Then, lets say that each of these areas (BTC, Audit, Tax, Legal, BC, Technology, People .... okay you get the picture .... all the way down to a project) gets its own web.

As an organisation, BTC would want to appear coherent at the very least to the outside world. This would mean that:

  • Terms would need to be used consistently and not duplicated between parts of the organisation.
    • (This can be difficult once an organisation gets beyond workable grapevine size)

We can say certain things about each web:

  • Certain webs implicitly inherit concepts from others:
    • BTC would need key (market-facing) concepts from each of the divisions
    • You would use ImportingContexts to bring in the market-facing concepts from BTC into the divisions, without bringing in terms such as KnownProblems (see WhatDifferenceBetweenATopicAndAWeb)
  • There would be an explicit hierarchy such that that which was intended by default would be the web that was closest to the current topic.
  • All webs that form the hierarchy form the context for that topic.

So when contributing topics to a web about KMProject for CTDI bank using middleware technologies for the knowledge management specialism in the Technology group in Business Consulting, my entire context would be (most-relevant to least relevant):

  1. KMProject
  2. CTDIbank
  3. middleware technologies
  4. knowledge management specialism
  5. technology group
  6. BC
  7. BTC

Consequently, when topics in KMProject refer to a WikiWord TIBCO, I don't need to define the topic TIBCO or StandardTermsAndConditions in KMProject. Instead the KMProject web explicitly inherits the CTDIBank, middleware technologies and knowledge management specialism webs and through inheritance brings in the (exported) terms from technology group, BC and BTC. It might find StandardTermsAndConditions in BTC and TIBCO in middleware technologies

More once my brain is ready again.

-- MartinCleaver - 19 Jun 2001

Not strictly a follow up to the above, but a comment that resolving topic references by searching through a path or sequence of multiple webs would mean that we could generalise our current way of getting values from variables.

At present these are found in firstly thisweb.WebPreferences then TWiki.TWikiPreferences.

It could be generalised to a path of webs and a consistant use of topic name so that any setting could be firstly looked up in the topic at the current project (KMProject) level, then through each of the 7 others I listed until it got to the topic in the TWiki default system configuration. (Performance matters aside).

As an aside I think the topic is better consistantly named TWikiPreferences because as we expand our Web* names we run a greater and greater risk of conflicting with a topic name that people migt want to use. (For example, if ''WebMethods'' gets defined as a TWiki system topic I will be very peeved!!)

-- MartinCleaver - 24 Jun 2001

Martin, this is a great idea. I have been under heavy pressure to provide something similar, but differently constrained; namely, all the Webs in our TWiki reflect some part of the organisational matrix, but all groups are working on common product lines. Therefore a reference to a topic such as "WidgetProductOptions" should first try to resolve within the current web and second resolve within other webs.

I can accept the need for some constraints on the search scope, so how about exclusion rather than inclusion. A single web should be in a position to protect it's topics (by being hidden?), but the egalitarian default is to permit access to all. This recovers some of the original flavour of the c2 wiki without losing the advantage of the TWiki organisational hierarchy.

-- CrawfordCurrie - 25 Jun 2001

Another time this would be useful is when you have terms such as PlugIn, AddOn, FormDefinition all defined as nouns, in say the TWiki web, and you want to refer to them in the Codev web without having to write TWiki.PlugIn, TWiki.AddOn, TWiki.FormDefinition. Using this idea you import either all terms from the Codev web or just the named ones then you could literally write PlugIn and have it resolve to TWiki. PlugIn

You wouldn't necessarily show the TWiki. bit - ToolTips could do that.

-- MartinCleaver - 12 Jul 2001

I think this is a great idea. There are often words/concepts that cut accross the organization and are often used in many of the webs. In these cases, the concepts are often dangling links, unless a search is done and the proper location for that concept's page is found in one of the other webs. I'm concerned that we'll start to have duplicated/inconsistent information when people start to define these terms in their own web.

It definitely seems important to have a hierarchical list of webs in which to look for topics. With this kind of feature, it would be easy for a site's administrator(s) to define a web like a "Glossary" where common definitions/terms/concepts are kept.

To implement this, is it as simple as this somewhere in the view script? See this rough pseudo-code:

    if (TopicName doesn't exist in myWeb)
        get list of other webs to look in
        for each web 
            if (TopicName does exist in this web)
                terminate for loop, topic is found in that web
        insert the link for Web.TopicName

-- MikeBarton - 13 Jul 2001

This came up recently in discussions during our roll out. The approach we came to as a nice solution is to do this: (not yet coded)

  • When a topic is created, update a DBM File that maps TopicName to a comma separated list of webs. (Makes the view script lower overhead)
  • Then when rendering a link if this list is just the local web, we render it as normal.
  • If however there is 1 link inside the Twiki Server, but not in the local web, we render it as normal, but with an indicator it's external (eg in square brackets, or italicised or something)
  • If there is >1 link then we render it using a dropdown box to cause the right page to be loaded - ie list all the items in a dropdown box, preferably with the local one listed with no prefix, and non-local ones prefixed with their web name.

Whilst this'd need Javascript, and raises the requirements above those that the main Twiki base normally accepts, the format would be relatively elegant, making the results easier to read.

-- TWikiGuest - 13 Jul 2001

Another example of needing this topic is given by the fact that we just have had created a topic called Codev.WikiWord as well as one already having existed as TWiki.WikiWord. I can envisage a dialog saying:

     A topic by the name WikiWord already exists in the TWiki web. 
     Do you wish to edit that definition instead of creating a duplicate definition?

-- MartinCleaver - 18 Jul 2001

Has anyone thought about this some more? I'd be especially interested to hear of objections...

-- MartinCleaver - 27 Sep 2001

I've played with a small mod to the internalLink method in TWiki.pm so that it calls a new plugin method for WikiWord that don't have a topic to link to. I've then got a simple plugin that reads the preference value USEWEBS to decide which other Webs to search for links. The change to TWiki.pm and Plugins.pm is pretty minor - is there much interest in add this to TWiki? If not, it can all be written as a plugin, but it will mean duplicating internalLink and the processing in the rendering sub that finds potentially linking text.

-- JohnTalintyre - 27 Sep 2001

IMO this should be a PlugIn...

About the duplication of the code: this is very good indication that this code should be split us into more specific subs, so the duplication effort would be minimal...

-- HansDonner - 28 Sep 2001

I have written this as a Plugin. The duplication is significant mainly because this is a core part of TWiki code i.e. converting WikiWords to links.

-- JohnTalintyre - 30 Sep 2001

John, I'm just learning Perl. Is there something in Perl (or the design of TWiki) that prevents you from calling this duplicate code from your plugin and returning values to it? (I'm assuming that the code in question is in one or more subroutines in one of the .pm modules.)

-- RandyKramer - 30 Sep 2001

I'd very much like to beta test it !! ;^> (Hey, when's the SmiliesPlugin going to be installed here wink

-- MartinCleaver - 30 Sep 2001

The general idea above would be excellent. Ideally, I could see it working like this (dunno how difficult this may be to implement, or how efficient it would be):

   WikiWord processed
          |
   topic exists in web ------ autolink (as it works now)
          |
   exists in other web --- autolink off/on** --- crossweb
  (search by priority*)         |                 autolink 
          |                create "?" link          : 
   create "?" link                           More options***     
                                              (modify autolink)   
                                              /           \     
                                          change       create crossweb
                                      crossweb link    =



    Warning: Can't find topic ""."" 
=****

* Admin-defined web priority list to search in preset order for a WikiWord match. Individual webs can be excluded from the list.

** In practice, especially if a topic exists in more than one other webs, any sort of selection device appearing in the edit/preview/save process might be too disruptive. Instead, the highest priority crossweb match is autolinked. User can override with a <nop>-type tag that turns off autolinking outside of the home web. There's also a crossweb autolink disable preference setting, by topic or by web.

*** A second level of control -- a [More] option available after the initial edit -- calls up a list of crossweb linkable WikiWords in a topic, with a selection of links for each, in web priority list order (this is similar to the rename referring links set-up in [Rename/move], with a drop down of available webs in priority order).

**** As an alternative to a crossweb link, a same-named topic is created in the current web, with an ==

Warning: Can't find topic ""."" == of the crossweb topic content. Use: Text can be added before and after the included content, while the imported content itself is protected. This fits here, because it makes use of the automatic location of same-named topics/content.

-- MikeMannix - 01 Oct 2001

Mike, can you clarify a few things:

  • Why have topics in home Web with %INCLUDE%? That wasn't clear - edited above in the note. It's just an option: instead of an interweb link, an interweb INCLUDE (as id done now, manually). - MM
  • I'm don't think a UI for "auto link selection" fits in too well with TWiki style. We do have the JavaScript based editor, with drop down of Topics in the Web. In think this should be replaced with a pop-up box that lets you get topics in current Web and others.
    Not clear on what you mean. But I had reversed the order of note 2 and 3. I switched them and rearranged the diagram. - MM

-- JohnTalintyre - 02 Oct 2001

Nice description Mike. I think that intially it would be enough to omit crosslink. Also I think that links to other webs should render in another colour, perhaps the colour can be listed in the destination web's WebPreferences.

-- MartinCleaver - 04 Oct 2001


I have 2 things to add:

Zope ( http://www.zope.org ) has this concept, it's called aquisition. The difference though is that Zope is very hierarchical. That is, there's a top (root) level and it branches down like tree roots. This means at any level you can specify a resource (object) and the system will first look in the current level then progress up till the root level and use the first one it finds. Thus you can define global object by creating them at the root level and you can use them anyway. However if you want to override the object at the root level create it in a level below and all references to it form lower levels use that one and not the root level one.

Sorry that's not very well expressed. But I hope you get the idea.

There's only one path up to the root level though. If you want to link across the root system you need to specify the path to the object.

BUT there are 2 main differences between Zope and Twiki as far as I can see.

  • Twiki is not a strict hierarchy of objects like Zope, each web is equal to the next.
  • The display of link words in wiki is inseperable to the creation of a new topic. In Zope you can use the admin interface to create a new object at any level. With the behaviour of Twiki however, if you type a link word that does not already exist, you can only create a new topic, of that name, in the current web.

I think these are 2 fundamental characteristics of Twiki that will prevent an easy solution, or one that has a simple interface.

Second thing I had to add, was that you already have the powers to link across webs:

  • either link explicitly: Web.LinkWord
  • or, make a topic on every web using the same title that links to the master topic of that title.
The solution may only be one of policy: the link to CompanyHistory will be Company.OurHistory. If all participants in the enterprise know this it won't be a problem.

Ultimately, it's something that affects one of the core components of Twiki and indeed any wiki. WikiWords work because of their simplicity. I don't know if it's right to make it more complex.

-- AndrewTetlaw - 06 Dec 2001

I propose that there are two useful related concepts here: TopicExistsInAnotherWeb & TopicInheritance.

Topic exists in another web would be a CompositionTimeActivity, it would occurs as an event and manifest as a pop-up to prompt the user that there exists the same (or similarly) named term in another web. This propmpts a user to statically alter the references in the page just written to be links to terms in other webs.

TopicInheritance what Andrew is calling acquisition. It is the dynamic binding that leaves the references in the document floating such that their meanings are dependent on the current context.

TopicInheritence is closer to how people think when they use an unqualified name. Like you know someone called Amanda and that is "Amanda" until there is someone closer to you in your life with that name. Then "Amanda" is that someone else. In the parlance that I am using your context has changed.

-- MartinCleaver - 09 Jan 2002

Martin --

You stated that you created a plugin for this. I didn't find the plugin you've worked on in the PluginPackages here at TWiki.org.

I have been working on one, as discussed above, so I could learn the Plugin framework.

At this point the plugin does: If TopicNotFoundInThisWeb but the TopicExistsInAnotherWeb, it replaces the WikiWord using the [[Web.TopicName]] syntax.

Do you want to collaborate & share our implementations so we can get a plugin posted?

Mike Barton -- MikeBarton

(I added Mike barton's sig line above. I must have accidently clobbered it in adding my comment JohnRouillard)

In preview mode, unlinked topics that exist in other webs could have a selection box before them. Something like:

This is John's homepage .JohnRouillard.

Where (NEW) means that it should allow creation of a new topic in the current web, the rest of the list would be ordered according to a WebPreferences variable called e.g WebOrder. If the unknown link was already qualified Test.JohnRouillard, it wouldn't receive the selection box before it.

I envision check boxes below the preview Changes button marked "Spell Checking", "Link Suggestions", "Search other Webs" etc to control what functions are done during the preview.

Quips, Comments, Evasions, Questions or Answers?

-- JohnRouillard - 18 Jan 2002

I'm not quite ready to contribute it yet, I suggest we coerce them after you release. Regards.

-- MartinCleaver - 18 Jan 2002

I posted the FindElsewherePlugin that I put together. It doesn't do everything that has been discussed on this page, but it's a start.

-- MikeBarton - 30 Jan 2002


I addressed this issue on my TWiki site by changing my WebTopicNonWikiTemplate and WebTopicViewTemplate to include the following:

---+++ Similar topics (if any):<br>
%<NOP>SEARCH{"%<NOP>TOPIC%" limit="10" scope="topic" nosearch="on"
 nototal="on" web="all" header=" "
 format="   * [[$web.WebHome][$web]].[[$web.$topic][$topic]]" }%

This allows the "Go" control to be used as a poor-man's topic search and also will show you topics of the same name in different webs before allowing you to create a duplicate.

-- GladeDiviney - 24 Apr 2002

Glade, this is a great idea and KISS. Added this to the Beta and TWiki.org:

---+++ If you used the "Go" feature to jump to this page:
<blockquote>
Make sure you spelled the TWiki06x00.WikiWord correctly and try again.
Remember, a WikiWord is case sensitive. Similar topics (if any):

%SEARCH{ "%TOPIC%" limit="10" scope="topic" nosearch="on" nototal="on" web="all"
  format="   * [[$web.%HOMETOPIC%][$web]].[[$web.$topic][$topic]]" }%
</blockquote>

-- PeterThoeny - 25 Apr 2002

Hmm, realized that this can be slow. At my daytime job we have over 11K pages and it takes many seconds to display the topic not found topic because of the search all web flag.

-- PeterThoeny - 29 Apr 2002

I both like and dislike this idea. Sometimes you want to be consistant and sometimes you don't. For example, a plugin topic in Codev might have far different content from a plugin topic in the TWiki or Main web (whichever has the TWiki doc).

It would be nice to offer some sort of option to either update the UnknownLink? that got one to the "topic not found" page to point to the web.pageName that was intended or to create a new page in the current web for the new topic.

-- DavidLeBlanc - 28 Apr 2002

Peter;

An alternative idea is to put a search button on the "topic not found" page to allow the user to link to an existing page rather then bring them all up before the not found page displays.

-- DavidLeBlanc - 05 May 2002

That is a good idea. Is done now: The "not found" page shows only similar topics located in the current web; a separate Search link will show similar topics in all public webs.

-- PeterThoeny - 05 May 2002

Looks like the solution has come full circle back to not-a-solution. The core problem is that new users don't intuitively grasp the concept of different webs and are therefore unlikely to understand that they're recreating a page that already exists in another web. This is why a transparent search of all webs is critical to solving the TopicNotFoundInThisWeb problem. At least on my site :-).

Seems to me if the problem is "the search is too slow" or "searches result in too many hits" then those are solved by "speed up searches somehow" and "use limit= in your search".

-- GladeDiviney - 08 May 2002

I disagree that a transparent search of all webs is critical.

Consider the case where TWiki serves an entire organisation with 1,000s of users. The users would have various interests, for the parts of the organisation that they were interested in. (See the original CTDG example, above.)

I think therefore even the Topic Not found fix (my first posting 4 May 2001) would benefit in the idea of which webs should be searched. These webs should be searched/presented in a defined order that depends on the context the user is working in.

My second idea was less about the time of writing and more about the time of rendering, a dynamic binding. This has not been addressed.

-- MartinCleaver - 11 May 2002

Perpaps the idea of specifying a related set of webs, or web search order, in the WebPreferences topic, in the RELATEDWEBS variable, would help. If the variable is not specified, all webs are searched.

A search order would help establish a context for the search, especially if we end up adding HierarchicallyNestedTwikiWebs. It would also be a good idea to add another variable to turn off searches for topics in webs that are not in the RELATEDWEBS list. That way, topics which match, but are of the wrong context, or describe an entirely different subject, are not accidentally linked if the moderator so wishes.

-- PeterNixon - 27 Jun 2002

Yes, I agree, a WebPreferences RELATEDWEBS variable would meet my requirements.

It would be nice to have this Plugin installed at TWiki.org.

Note that this Plugin is not a RenderPipelinePlugin but rather a ParsePipelinePlugin wink

-- MartinCleaver - 02 Jul 2002

The thing that worries me about having a search across webs is that you do not always know when the link may change. So if a page in Web A links to TargetPage that exists in Web C, but then a user adds another page called TargetPage to Web B that is searched before Web C, the link from Web A will change and possibly nobody will be aware of it.

Here's another proposal to add to the pool - how about having one Web whose pages are global to the whole TWiki, and can be referred to without their web prefix? Pages like Users, and maybe some forms - basically anything that would be common to all webs - could go in here. An object oriented analogy would be to consider this global web as a base class and the members of that web as base class members, then all other webs derive from that base web and inherit all the pages that exist there so they can refer to them as if they are members of their own web. This would also be analagous to the way TWikiPreferences defines global TWiki variables that are picked up by all derived webs.

-- MartinWatt - 08 Sep 2002


How about this means of gently reminding users of the existence of a topic in other webs, without complicating the semantics of WikiWords as FindElsewherePlugin does?: if a topic exists in other webs, add a small header/footer to the displayed page looking something like:

This topic in other webs:
  [[General.ThisTopic][General]] -
  [[DeptA.ThisTopic][DeptA]] -
  [[DeptB.ThisTopic][DeptB]]

rendering as:

This topic in other webs: General - DeptA - DeptB

The problems I'm trying to solve with this:

  • We're tending towards a semi-hierarchical TWiki with a web for each active project (or similar community), and a general web for distilled wisdom. Consider a topic about a tool, such as TelelogicDoors. The topic in project webs is more likely to be actively maintained, but will contain project-specific info, and it would be nice to avoid duplication of common wisdom across lots of project-specific webs. Manual cross-web linking might help but is tedious; automatically cross-web linking to the generic web might reduce the temptation to duplicate.
  • If a common topic in one web has suffered from lack of maintenance, make it easier to find more up-to-date information on the subject elsewhere in the organisation.

(This is quite a different FeatureEnhancementRequest to the one that started this topic, so perhaps I should have started a new topic. Oh well.)

-- JacobNevins - 13 May 2003

A colleague has implemented this locally as a plugin. I don't know whether he plans to upload it here.

-- JacobNevins - 23 Sep 2003

See NamespaceControl for a different (simple) approach to this problem.

-- RaymondLutz - 31 Dec 2003


Edit | Attach | Watch | Print version | History: r46 < r45 < r44 < r43 < r42 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r46 - 2003-12-31 - RaymondLutz
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.