The reason this is not all automated is because a) it would require the maintenance of a separate link database, and b) in a double linked graph there may be potentially a lot of irrelevant pages pointing to the current page, so you do not always want to list them. Thus, the manual strategy of adding category tags or parent pages at the end.
That's only true if a category tag is the same thing as a link (as is now); this is a wiki; while we ''can'' use a file to saw and a saw to file, there is no excuse to go into a forest armed only with a file.
-- MichaelPaulukonis 2014-03-19 15:57 UTC
----
What exactly are you proposing? On a different site, I'm using tags with a typed link: ##[[tag:Something]]## together with a simple database to keep track of them. I'm mostly concerned about category pages:
# do we want to keep them?
# if we want to keep them, will we still maintain them by hand?
# if we maintain them by hand, what's the benefit of using ##[[tag:Something]]## as opposed to ##CategorySomething##?
Or are you arguing that we don't need a bottom-up categorization of pages, we can do a top-down categorization. If a category page links to a page, that page automatically belongs to that category and can link back to the category without being modified? If so, I guess we could define a set of /entry/ pages (such as the SiteMap) which links to /category/ pages (as it does), and the category pages would still be maintained by hand, but it is no longer necessary to mention the categories on the page itself.
-- AlexSchroeder 2014-03-19 17:40 UTC
----
I'm proposing that category tags not be links, they be something distinct -- as far as wiki markup goes. When rendered, they'd act like a link and look like a link (depending upon css or other presentational issues).
But having a category tag be ''distinct'' from a link, would allow for automatic aggregation of ''tagged'' pages, as opposed to linked pages.
Somebody's profile could link to CategorySomething -- but it would be a link.
An actual article that is tagged [[tag:Something]] would render as a link to, and be auto-included on the CategorySomething page (presuming a mechanism exists for listing all pages with tags).
Tagging, categorizing is human-powered manual activity, but aggregating and listing pages tagged should be automatic.
-- MichaelPaulukonis 2014-03-20 15:53 UTC
----
OK, I think I understand your proposal, now. One problem remains, as far as I can see: Simple aggregation and listings are often inferior to well-written category pages. Take CategoryAccessibility, for example: I don't want to replace it with an automated list. Even a simple list like CategoryBookmarking has a little summary for every page instead of just the page name. Would you also support markup to identify the tagline for each page, or would you just take the first sentence of the first paragraph, or nothing at all?
-- AlexSchroeder 2014-03-20 17:15 UTC
----
What I'm proposing is two forms of markup -- one that makes a tag distinct from a link (markup-wise), and one that can list all pages marked with a tag (or with other parameters -- a pagelist if you will).
This way, the page CategoryAccessibility can be handcrafted -- an intro, an outro, a hand-curated list of links, **or** an intro, an outro, and a list of all pages that contain the [[tag:Accessibility]] markup
The model I have in mind is [http://www.pmwiki.org/wiki/PmWiki/PageLists PmWiki's pagelist] markup -- which is written in PHP and in the source noted to be somewhat hermetic. It's pretty powerful, but a small subset of features would be nice -- wildcard inclusions and exclusions, for instance.
Pagelists themselves are rendered according to a template) or a default template -- which could mean including the entire page (g-d forbid!), a sentence, a paragraph, the full title, a summary, or some other portion of the page or page's metadata.
While Pmwiki's own site implements category pages [http://www.pmwiki.org/wiki/PmWiki/Categories automatically] -- see [http://www.pmwiki.org/wiki/Category/Administration Category.Administration] for example -- that's configurable. In our case, manually including the listing-markup is probably preferable.
-- MichaelPaulukonis 2014-03-20 21:09 UTC
----
I installed two modules: The [[Oddmuse:Tagging Extension]] implements the ##[[tag:...]]## markup; [[Oddmuse:Search List Extension]] creates a list based on a query.
The syntax is simple: ####. The search terms apply to title and page content
(and therefore this is extremely slow unless you limit yourself to tags, ie. ####.
Check out this example: [[Deutsche Seiten]].
-- AlexSchroeder 2014-03-21
----
Unfortunately feature implementation is not the only impediment. Usually it also takes a significant amount of page editing to make the transition, even if we only switch a single category. I'm going to wait for people to actually start using the existing features before implementing any new features.
-- AlexSchroeder 2014-04-04 06:48 UTC
----
Since I don't remember seeing any activity relating to this, I will uninstall this feature.
-- AlexSchroeder 2014-05-12 09:30 UTC