Suggestion for enhancing the knowledge of page structure and the role of content

I dropped this idea by PF (in a very incomplete form) , and it was
suggested (by Charles) that I write it up and suggest it hear 
 
It may be incorporated into the RDF techniques document for WCAG 2.0
(excluding the adding new types stuff...)
 
All the best
Lisa Seeman 
 
Suggestion for enhancing the knowledge of page structure and the role of
content 
 
 
Introduction
It has long been a wish for assistive technologies and transcoders to be
able to encapsulate the functional substructures in a page, and marking
their roles in the page known.
 
However it seemed a infinite task to compile a complete list (and reach
consensus) of what types of content can be expected on a page.
 
On the other hand, it seems to me, with the flexibility of RDF that we
can allow for this encapsulation without the requiring a full or near
full list of content types. 
 
Firstly we could compile a short and incomplete list of known common
types of content section each with a valid reference -able URI.
 
 Then Web authors would be able to  annotate sections of  document
content, linking them to known types of content. 
 
Finally  authors could create new types as needed.  (Preferably  when
they define these types they should be required to define closeness to
other known types, and provide a semantic description.)  
 
 
Examples for initial types
Each type would require a valid URI.
 Identifier types of content typically found in a page could include:
 
navigation siteWide main
navigation siteWide secondary
navigation department
navigation department section
Main content 
Footer navigation
Sitemap link
Contact us link
Summary
Table of content
Advertising section
Adult content section
Unmonitored section
 
 
Expanding and adding types
 
Part of the coolness ( there is no other word for it) of this solution,
using RDF is that we can start off with a very basic set of types (say
15) and then allow authors to add to an open repository of types, when
they feel a new type is needed.
 
A good process for adding types could be incorporated into new type
submission. I would recommend that each new type would have to map
closeness to existing or base types before submitting a new type. A
textual description and URI would also need to be submitted.
 
 
 
Duplication checking:
 
Before a new type is submitted, one could  a type author asked to check
any similar types already submitted (easy implemented , compare if the %
similarity to know types exists in close proximity to a known type, were
- consider it vector mapping in multi directional space...)All the best