incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: Jena documentation - new structure working notes
Date Thu, 17 Feb 2011 12:13:55 GMT
Hi Ian,
first of all, thank you.

I like the fact we are thinking how to better serve the needs of
new users, expert users as well as potential contributors/new
committers. This is a common approach with many open source
projects [1,2,3,4,...] and I find if very useful for the open
source projects I use.

Things I appreciate about other open source project websites,
in particular for those open source projects I decide to depend
on, are: roadmap pages (i.e. what is going on and, approximately,
when it will be done), wish lists (i.e. what it would be nice to
have, if only we had infinite time) and/or feature requests (a
page could point to a subset of JIRA issues) and related
specifications/standards/recommendations (this is useful to new
users as well). (See JENA-16 [5]).

Another very useful thing for us and/or new potential contributors
are pages like: "how to submit a patch" or "how to build/release" [6].
For example, we recently have received patches which have not
been 'properly' generated and it was a pain to apply.

It is not clear to me the role that Jena's wiki [7] will have (if
it will have one).

Sharing and pointing to specific examples of other websites we
like or we think would server our community well is very useful,
at least to me. So that we can get ideas and/or compare what we
have with what we would like to have.

Finally, I am for an incremental approach where we start with
the homepage and the three/four main sections and then we gradually
migrate the existing pages we want to migrate (changing them if

What are the three/four main sections from the homepage?

My 2 cents,


Ian Dickinson wrote:
> Thinking about the structure of the new site, I spent some time 
> surveying what we have. The attached pdf & freemind documents show the 
> current structure, including tdb, sdb and fuseki.  The second attachment 
> shows some suggested goals for the new IA, thinking in terms of the user 
> goals we would like to satisfy.
> 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

View raw message