The final attachment sketches a possible solution. The first level of the hierarchy roughly corresponds to groups of suggested user goals. These could be presented as a horizontal tab array. The second level of hierarchy would in most cases be actual topic documents (such as the eyeball howto in the tools section). However, three of the goals are sufficiently large that having a second level of hierarchy would be helpful to our users, I think. I propose that, where it's necessary, the second level of hierarchy would ideally be consistent, to aide findability. A working suggestion is:
RDF (i.e. the core API) querying (ARQ & SPARQL) persistence (TDB, SDB, FileModel, etc) ontology API inference serving data (Joseki, Fuseki)My proposal is that we use a static navigation structure, using nested <ul> elements to model the hierarchy, but use progressive enhancement javascript techniques to pretty this up as a more dynamic reveal-on-demand menu structure. That way, we get benefits of accessibility, and visibility to search engines, keep the ease-of-update of the Apache CMS (thus avoiding the Forrest approach of update the site config & rebuild everything), but manage the visual and complexity we present to most users on capable browsers. This would all need some prototyping and experimentation, of course.
Comments welcome. Ian -- ____________________________________________________________ Ian Dickinson Epimorphics Ltd, Bristol, UK mailto:[email protected] http://www.epimorphics.com cell: +44-7786-850536 landline: +44-1275-399069 ------------------------------------------------------------ Epimorphics Ltd. is a limited company registered in England (no. 7016688). Registered address: Court Lodge, 105 High St, Portishead, Bristol BS20 6PT, UK
jena-apache-ia.mm
Description: application/freemind
jena-apache-new-structure-goals.mm
Description: application/freemind
new-jena-site-structure.mm
Description: application/freemind
