NEGS - Navibars Extension for Google Sitemaps 1.0

Specification, 04 January 2006

This version:
http://navibar.oaklett.org/specs/negs-10-wd/NEGS-10-20060104.html
Latest version:
http://navibar.oaklett.org/specs/negs-10/
Previous version:
http://navibar.oaklett.org/specs/negs-10-wd/
Author:
Markus Siebeneicher, <siebeneicher@oaklett.org>

Abstract

A few days ago Google has introduced a Sitemap format called Google Sitemaps. The Sitemap contains information about location, frequence of change and other data about web pages of a web site. Google Sitemaps helps Google to index web pages and crawl the contents individually. Unfortunately the Sitemap format does not contain any information about the structure and relation of any web pages - it is just a plain list of URLs. NEGS - Navibar Extension for Google Sitemaps - is an extension for the Google Sitemaps format and it aims to give information about title, structure, relation and other meta data of web pages.

Navibar is an extension for the Firefox Browser and it tries to profit from Google Sitemaps but it needs some more information in it. NEGS is the Addon for Google Sitemaps to solve this problem.

NEGS does a good job, but the recommended format for the Firefox Navibar Extension is NNS - Navibars Native Sitemap.

Table of Contents

1. Introduction

This working draft aims to design an extension for Google Sitemaps. NEGS comes down the road with a set of elements and attributes which give any defined URL additional information about title, structure, relation and optional other meta information. NEGS is not a completely new sitemap format, it just extends Google Sitemaps without loosing any former information or functionality.

1.1. What is Google Sitemaps?

In the summer of this year(2005) Google began to support a new service. It is called "Sitemaps" and is currently in version 0.84(BETA). Google Sitemaps are used to index web pages and help Google to crawl pages all over the world. The Sitemap is written in XML and could look like:

example copied from http://www.google.com/webmasters/sitemaps/docs/en/protocol.html
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.google.com/schemas/sitemap/0.84">

   <url>
      <loc>http://www.example.com/</loc>
      <lastmod>2005-01-01</lastmod>
      <changefreq>monthly</changefreq>
      <priority>0.8</priority>
   </url>
   <url>
      <loc>http://www.example.com/catalog?item=12&desc=vacation_hawaii</loc>
      <changefreq>weekly</changefreq>
   </url>
   <url>
      <loc>http://www.example.com/catalog?item=73&desc=vacation_new_zealand</loc>
      <lastmod>2004-12-23</lastmod>
      <changefreq>weekly</changefreq>
   </url>
   <url>
      <loc>http://www.example.com/catalog?item=74&desc=vacation_newfoundland</loc>
      <lastmod>2004-12-23T18:00:15+00:00</lastmod>
      <priority>0.3</priority>
   </url>
   <url>
      <loc>http://www.example.com/catalog?item=83&desc=vacation_usa</loc>
      <lastmod>2004-11-23</lastmod>
   </url>
</urlset>

The Sitemap gives information about the location, last modification and other meta properties. The URLs are written down in a plain list which do not contain any hierachical structures. The Sitemap file lies on the webserver and Google downloads/parse it.

Google supports a Sitemap Generator written in python. There are also other scripts on the net: wordpress module or phpsitemapng. If you are interesting in Google Sitemaps and want to learn more consider Google Sitemaps Home, About Google Sitemaps and Creating a Sitemap.

1.2. What is the Firefox Navibar Extension?

Navibar is an Extension for the Firefox Browser and it helps navigating through the internet. Navibar helps navigating in the way that it builds up a tree representation of all known web pages on a web site you can browse through like the windows explorer. The tree representation comes from a Sitemap file on the webserver containing the web pages and the hierachical structure.

The Sitemap is mostly written in the Navibars Native Sitemap format(XML/RDF). The basic informations are the title, url and children of a web page. Optional a web page could contain related web pages which are displayed as link in the context menu. Navibars Native Sitemap format do contain all information to build up a sophisticated navigation panel. Unfortunately Google Sitemaps does not.

1.3. Why extend Google Sitemaps?

The question is: why should we extend Google Sitemaps?

The reason lies in the format itself and what the Firefox Navibar Extension needs to represent the tree of the web site. Unfortunately Google Sitemaps does not support important information for Navibar. Google Sitemaps is missing...

Most of these information have to be added as new elements or attributes to Google Sitemaps. With this additional information Navibar is able to load the Sitemap file and build up the navigation panel like the native format(NNS) without any limitation. Another issue is that Google Sitemaps is supported by an increasing number of web sites and it is easy for webdevelopers to extend Google Sitemaps for Navibar users to hit two flies with one strike force.

1.4. Design aims

The following design aims are sorted by magnitude:

1.5. Terminology

2. Namespaces

The native Google Sitemaps format can be extended with the NEGS and the Dublin Core Meta Elements. Each of them complements the other. The NEGS gives information about the hierachical structure and the Dublin Core Meta Elements gives additional information like Title.

The XML Namespace of the NEGS format is: http://navibar.oaklett.org/negs/1.0#

The XML Namespace of the Dublin Core Meta Data Elements 1.0 is: http://purl.org/dc/elements/1.1/

3. Hierachical Structures

The benefit of NEGS over the native Google Sitemaps format is, that it additionaly defines a hierarchical structure. How does it work:

There are 3 attributes for the url element: the xml:id, negs:childOf and negs:relatesTo attribute. You only have to extend those urls which should be displayed in the Navibar tree or context menu. The xml:id attribute is a must have and ether the negs:childOf or negs:relatesTo attribute or both of them.

The ID will be referred by other url elements from within the childOf or relatesTo attribute. So, the ID is the glue between the parent and their children in the Navibar tree(negs:childOf), and between any item in the Navibar tree and their related context menu items(relatesTo). Here is an example(the bolded elements and attributes are the extentions to the Google Sitemaps format):

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.google.com/schemas/sitemap/0.84"
	xmlns:gs="http://www.google.com/schemas/sitemap/0.84"
	xmlns:negs="http://navibar.oaklett.org/negs/1.0#"
	xmlns:dc="http://purl.org/dc/elements/1.1/">
  <url id="articles" negs:childOf="urn:sitemap:root">
    <dc:title>Articles</dc:title>
    <loc>http://myexampleapp.oaklett.org/articles/</loc>
    <changefreq>daily</changefreq>
    <priority>0.5</priority>
  </url>
  <url id="articles-soccer" negs:childOf="articles">
    <dc:title>Soccer</dc:title>
    <loc>http://myexampleapp.oaklett.org/articles/soccer/</loc>
    <changefreq>monthly</changefreq>
  </url>
  <url id="articles-soccer-1" negs:childOf="articles-soccer">
    <dc:title>Barcelona beats Manchester</dc:title>
    <loc>http://myexampleapp.oaklett.org/articles/soccer/1/</loc>
    <changefreq>monthly</changefreq>
    <lastmod>2005-08-25</lastmod>
  </url>
  <url id="create-new-article" negs:relatesTo="articles-soccer">
    <dc:title>Create New Article</dc:title>
    <loc>http://myexampleapp.oaklett.org/articles/soccer/create-new-article/</loc>
  </url>
</urlset>

The example would produce the following tree and context menu in the Navibar sidebar:

Example

So lets take look into the example. You will recognise, that all url elements of the native Google Sitemaps have an id attribute. Without the ID we could not refer to any url element and make no children or related ones. The negs:childOf attribute of the url element with the ID articles has the value urn:sitemap:root. The urn:sitemap:root value is a special value because it do not refer to any URL in the Sitemap, but it indicates that the articles URL is a root element in the tree. Root elements are those elements who do not have a parent. The urn:sitemap:root value can be set only in the negs:childOf attribute of any URL. You should not set any ID to urn:sitemap:root, this could cause unknown errors.

A valid value of a negs:childOf attribute can be any IDREF or urn:sitemap:root. Lets take a look at the URL with the ID articles-soccer. This URL has defined a negs:childOf attribute with the value articles, that indicates, that the URL with the ID articles-soccer is a child of the URL with the articles ID. Also, the articles-soccer URL is refered by the articles-soccer-1 URL, so the articles-soccer-1 URL is a child of the child of the root URL(articles-soccer-1 childOf articles-soccer childOf articles). The depth of the tree is not limited(only by your computers hardware). As a matter of course a parent can have more than one child.

The last URL in the list is the URL with the ID create-new-article and it has defined a negs:relatesTo attribute with the value articles-soccer. The create-new-article URL relates to the articles-soccer URL and this means, that the create-new-article URL is not displayed as a child of the articles-soccer URL in the regular tree, but as a context menu item of the articles-soccer URL. You can define more than one related URL to any element and you can also define children to URLs which already relates to a URL. Please use the childOf attribute instead of the negs:relatesTo attribute to make a URL a child of a related URL in the context menu.

The difference between the negs:childOf and negs:relatesTo attribute lies in the reprentation: the tree or the context menu, but both are used to represent a kind of a tree.

Lets imagine another issue, you want to have one URL as child of two different parents in the tree. Unfortunately the value of the negs:childOf and negs:relatesTo attribute has to be of type IDREF and not IDREFS. If the type could be IDEFS the problem would be simple, because we could define one or more ID's separated by a space. But we have to go another way, exactly we need two url elements of the same URL with exception of the negs:childOf or negs:relatesTo attributes. The value of the attributes have to be the ID of the second URL. If you do so, you should define all elements and attributes of the Google Sitemaps namespace too.

4. dc:title Element

The Dublin Core has defined some elements under the namespace http://purl.org/dc/elements/1.1/ and one of them is the title element. The dc:title element gives the title of any URL in the tree or context menu and it is a must have. You have to define the dc:title element as a child of the url element.

There are also other elements and attributes, for example the negs:order or negs:icon attributes. All of them are listed and described in the Summaray of Elements and Attributes section.

5. Full Example

You can view the full example and if you have installed Navibar(version 0.10 or later) you can view it in action in your sidebar.

Full Example

6. Summaray of Elements and Attributes

The Google Sitemaps url element is extendable by the following attributes and child elements.

Attribute: xml:id
Value Type ID
Definition The xml:id attribute is required for all URL elements which are part of NEGS. The ID is the major player in the game because it glues the parent with their children.
Attribute: childOf(NEGS)
Namespace http://navibar.oaklett.org/negs/1.0#
Value Type IDREF
Definition The childOf attribute contains the ID of the URL element this URL should be child of. The childOf attribute is optional with one exception: the root URL element(s) of the tree. So, all URLs which should be placed on the top of the tree have to define the childOf attribute containing urn:sitemap:root as value. If you do not define any root URL the Sitemap will broke. If you do not define the childOf attribute you probably should define the relatesTo attribute. Furthermore the childOf attribute can be used to define children of URLs which are related to other URLs defined by the relatesTo attribute. There is no conceptual limitation of the depth of the tree.
Attribute: relatesTo(NEGS)
Namespace http://navibar.oaklett.org/negs/1.0#
Value Type IDREF
Definition The relatesTo attribute is of type IDREF and contains the ID of the URL element this URL should relate to. Its up to the Firefox Navibar Extension how to interprete the relatesTo attribute but for easiness the current Navibar version(0.10.x) will list all related URLs in the context menu of the specific tree element. As you can define children of children of children of an URL by using the childOf attribute you can define children of URLs which are related to other ones. If you define a URL(B) which relates to another URL(A) you can use the childOf attribute ín the child URL(C) containing the ID of the URL(B) which relates to URL A. There is no conceptual limitation of the depth of the tree.
Attribute: order(NEGS)
Namespace http://navibar.oaklett.org/negs/1.0#
Value Type Number
Definition The order attribute - as the name suggest - is used to order the siblings in one branch of the tree. The value of the order attribute have to be a number from 1 up to ... the sky.
Element: icon(NEGS)
Namespace http://navibar.oaklett.org/negs/1.0#
Value Type Literal
Definition optional, absolute url to 15x15 icon of any supported Firefox image format
Element: title(Dublin Core)
Namespace http://purl.org/dc/elements/1.1/
Value Type Literal
Definition required
Elements: *(Dublin Core Metadata Element Set 1.1)
Namespace http://purl.org/dc/elements/1.1/
Value Type Literal
Definition optional, elements do not have any functionality, just as metadata

References

Google Sitemaps
Google Sitemaps Protocol, by Google itself.
XML 1.0
Extensible Markup Language (XML) 1.0 (Third Edition), F. Yergeau, J. Paoli, C. M. Sperberg-McQueen, et. al., Editors, W3C Recommendation, 04 February 2004
DCES 1.1
Dublin Core Metadata Element Set, Version 1.1Dublin Core, 20 December 2004
NNS 1.0
Navibars Native Sitemap 1.0, Markus Siebeneicher, 21 August 2005

If you have questions about the usage or notes concact <Markus Siebeneicher>.