Hi Brian,
On 18/02/11 11:08, Brian McBride wrote:
There has been some good discussion in this thread and I agree with
Paolo that it would be suboptimal to present the user with a long list
of choices e.g. in a getting started page.
I don't think anyone is suggesting such a list. The current Jena site
does hava a long "jump list" of links, and I think there's a clear
consensus that we'd like to fix that as part of the transition.
I suggest it might be better not to treat Jena as a single monolothic
thing, but to give the user a map to its regions at the top level. One
way to do this might be to have a top level page with a menu on the left
and the main body of the text that says something along the lines of:
* Jena is a software package consisting of a number of modules:
o a Java library for creating and manipulating RDF graphs
supporting
+ reading/writing different text formats for RDF graphs
+ creating/editing/querying RDF graphs
+ creating/editing/querying OWL ontologies
+ rule based inference on RDF and graphs and OWL ontologies
o TDB: a file system based persistent store for RDF graphs
optimised for speed of query and access supporting:
+ SPARQL 1.1
+ integration with Lucene for text search
+ named graphs
+ fast bulk loading from common RDF serialistion formats
o Fuseki: an RDF server that runs out of the box stand alone
or in an app server supporting:
+ SPARQL protocol 1.1
+ ...
+1 for some sort of structuring.
Menus need to be short so that they can be scanned quickly. My view is
that it would be better for the users if, as much as possible, we
organize the menus around what they want to do, rather how we structure
the code. In other words, as a principle I would rather see a menu
* Jena
* TDB
* Fuseki
be presented as something like
* Handling RDF
* Persisting RDF data
* Serving RDF data
because - I claim - that would be more helpful to users coming with
either no knowledge of Jena, or with a specific problem to solve. (NB
I'm not actually proposing that menu structure, just trying to
illustrate a principle)
There is a counterargument, which is that someone who's already using,
say, TDB, and needs to know how to, say, enable the default union graph,
needs to be able to find that specific piece of information quickly and
easily. I think, though, that this use case can be handled by additional
indexes / pointers in the navigation structure.
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
