DMOZ Regional Trees
Regional trees are a new feature in the DMOZ software. They add new ways of navigating the Regional structures in the directory, making it easier to find specific types of listings within a broad regional structure. In the "classical" DMOZ Regional view, each listing is only shown in the particular category in which it is placed. Usually this is a locality-level category, but sometimes websites are placed at higher levels (e.g., at County or Province level) according to our editing guidelines. This ensures that websites are treated equitably, and establishes a much needed framework within which editors can organize sites.
But it's not always easy to find websites by navigating the classical structure. When they can be used, downward @links and upward relcat links help to find sites of similar topics up and down a regional structure. But in small localities with few listings, the regional template structure is not or only sparsely implemented, so that their listings cannot be found by @links from higher-level template categories.
Regional trees add another layer of information to our Regional listings, which allows sites to be found according to their topic or type regardless of how shallow or deep the template structure is developed in their locality. It can show all sites of a particular kind throughout a regional structure on one page, saving a lot of clicks. The details are explained in the sections below.
The Public Tree View
Categories that are part of a defined regional tree have a link near the top labeled "Tree View". Clicking this link switches the user to tree navigation mode. And of course, clicking the "Classic View" link from the tree view switches back to the familiar category view.
Tree navigation mode is governed by a "path", not a "category". Just like in classic mode, the path has a regional part (e.g. Regional/Europe/Netherlands/Zuid-Holland/Rotterdam) and a topical part (e.g., Recreation_and_Sports/Soccer). But while classical mode only recognizes paths that correspond exactly to existing categories, in tree mode it doesn't matter if a category exists. The combination of the regional part and the topical part are used together to find all listings
- in that regional node and regional nodes below it
- classified with that topic, or its subtopics
If there are more than 300 listings that could be listed for a particular path, the listings belonging to deeper-level categories are not shown. Instead, links to subtopics and deeper-level regional categories are shown to allow you to narrow down your selection. At any point in the structure, you can navigate upward regionally by clicking the "See Also" links to higher-level categories, and topically by clicking a link in the path breadcrumb trail.
What Editors Need To Know
So how does this all work? The regional tree navigation requires an extra layer of information, as well as extra housekeeping to keep track of what belongs where. Most of this happens behind the scenes, but there are a few new concepts that editors in Regional Trees need to be aware of.
A Tree Needs to be Created
Not all the Regional structures belong to regional trees. In fact, as the concept is relatively new, there are only a few regional trees defined at this time. Hopefully, in time, they will cover more and more of Regional around DMOZ.
To define a new regional tree, you need to work with an admin who can serve as tree coordinator. Defining a tree takes several steps.
Defining the Regional Structure
Regional structures in DMOZ come in many different forms: countries have different administrative structures, and languages use different words to describe things like "Localities" and "Regions". A collection of information about a particular structure, called a Regional Definition, is used to interpret the human-built Regional structure of DMOZ. Before a tree can be set up in a particular section of Regional, the corresponding Regional Definition must be established. They are managed from the Regional Definition Management Form. All editors can view the information on this form, but only admins can change definitions, or add new ones.
Defining the Topical Structure
The other half of the Regional Tree path is the topical part. This is much like the Regional Templates that have been in place for a long time, but allows for more fine-grained classification of the topic of a site. For example, the template will only take you to Society_and_Culture/Religion, but the topical template can take you deeper, e.g. to Society_and_Culture/Religion/Christianity/Orthodox.
The topical structure for each language is first defined by importing from the template categories in Test, but can then be further expanded using the Topical Structure Management Form. As with regional definitions, this form can be viewed by all, but in this case only metas and admins can make changes.
It's good to keep track of which topics are the same across languages. For example, Onderwijs/Basisscholen in Dutch is the same topic as Education/K-12/Public/Elementary_Schools in US English. To make sure that we can translate the topics between languages, each topical structure is mapped on the Master Topical Structure, which you can also see on the Topical Structure Management Form. This master structure is a grand collection of all the topics defined in all the language-specific topical structures. Specific topical structures only implement the parts of the master topical structure that are useful in that language. Only admins can change the master topical structure.
Defining the Tree
With all necessary Regional and Topical machinery in place, it is now possible to define a new Regional Tree. Each tree has a Regional Definition, a Topical Structure, and a language. It also needs a top-level category, and can optionally define the next two regional layers above the tree. For example, the tree for Canada/Nova_Scotia might define Canada/Regions/Atlantic_Provinces and Canada as the two upward layers.
Admins can modify regional trees and create new ones using the Tree Management Form. Filling out the form is only the first part of the job. The next steps are to import all of the categories and listings that are included in the tree. This may take some time and effort, especially if there are inconsistencies in the existing category structure.
As an editor, you will not notice much difference when you edit a category that is part of a tree. The main difference is the appearance of a new input on the URL editing forms, to define the "Topic" of a listing. Using the dropdown, you can quickly find the most appropriate topic for every listing. There are three important things to know:
- A listing that has no topic assigned will not appear in any tree view. This will be the case for listings that were not placed in template subcategories at the time the tree was defined, for example top-level listings in small localities. It is important to assign topics to these listings, so that they may be found in the tree view.
- You may (and should) assign topics that are deeper than the category structure. For example, for a dentist's site you should select the topic Health/Dentistry, even if the category template structure only goes as deep as Health.
- You cannot assign a topic that conflicts with the category structure. If you try to assign, for example, the topic Society_and_Culture/Spirituality to a listing in subcategory Health/Alternative, the editing system will override your topic selection, and assign the Health/Alternative topic.
Another change you may notice is when you create a new subcategory inside a tree structure. The editing system will evaluate topical subcategories that are not yet created but for which listings have already been defined (using topic assignments). If you select one of these subcategories, the software will offer to move the corresponding listings into the new subcategory, and also create upward relcat links to higher-level regional entities, saving you just a little bit of editing time and effort.