Hi Ian,
I found the messages about documentation structure in the archive, but
haven't figured out how to reply to messages from the Archive, so sorry
for the new thread.
One comment on goals, born out of recent frustrations, is that there is
a class of potential Jena user who building some app or whatever, who
needs a component to perform some specific subtask. Lets call her
Joanna. Joanna is an experienced programmer, is busy, has a deadline
looming and is looking to make a quick decision about a component to use
for some RDF processing in her application. Her application isn't
'about' RDF - its not a major thing - its just that she has to do some
RDF processing in order to get her job done. Maybe she has a DOM and
just wants to process it to extract RDF from the embedded RDFa and then
munge it. She doesn't want a tutorial on RDF or anything like that and
she doesn't want to plow through a lot of javadoc to figure out if Jena
will do what she wants. On another day in another project she is
looking for a triple store, she has some basic requirements (fast read,
standard update protocol, SPARQL 1.1) - and she want a quick way of
determining if TDB, SDB, Fuseki etc meet those requirements.
Joanna needs to a quick way to figure which component she should be
looking at, whether that will do the job, and then a pointer to where to
look to figure out how. In my mind she is looking for some data sheets
about the components - just the bare facts ma'am type documents.
Reading your mind maps, I don't think Joanna is represented there, but
maybe I'm missing something, or maybe she isn't important enough to show
up.
Brian
- more on documentation structure Brian McBride
-
