You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeff Turner <je...@apache.org> on 2003/10/12 04:23:47 UTC
Forrest and the NDS (Re: [RT] Moving towards a new documentation system)
On Sat, Oct 11, 2003 at 03:17:48PM +0200, Stefano Mazzocchi wrote:
>
> On Saturday, Oct 11, 2003, at 14:25 Europe/Rome, Nicola Ken Barozzi
> wrote:
>
> >Please don't forget Forrest.
>
> we are not.
:) Let's remember that there's hard reuse and soft reuse. Hard reuse
means physically integrating with Forrest/Lenya. Soft reuse means
reusing ideas, people, and code where appropriate. For a new project in
RT phase, worrying about hard reuse with Forrest and Lenya would IMHO
just slow things down.
Forrest started with a RT, a mailing list, and a bunch of Cocooners
willing to contribute. I wasn't at the GetTogether. I've never seen a
RT articulating the vision for this project. There's just tantalising
snippets. Could we perhaps dream up a name ('linotype' seems obvious),
start a mailing list, and have some RTs on what this is all about? :)
> I thought about it and I totally resonate with Bertrand: we need to
> outline an incremental transition to our own CMS reusing as much dog
> food as possible (which is also good for a community perspective).
>
> Here is my proposal:
>
> 1) the system gets divided into three parts
>
> - frontend -> mapped to http://cocoon.apache.org -> static
> - repository -> a WebDAV server
> - backend -> mapped to http://edit.cocoon.apache.org -> dynamic
The mozilla.org site does something similar, in that the 'edit this page'
link goes to:
http://doctor.mozilla.org/?file=mozilla-org//html/index.html
I've long thought this would be a great Forrest enhancement.
[snip cool stuff]
> The future idea is to use indirect linking where lookup is a sort of
> "what's related" understood out of the analysis of user patterns, but
> this is far ahead in the future.
>
> For now, I think direct linking would be enough for our needs... we
> just need a good "lookup and discovery" of learning objects integrated
> in the backend.
>
> - o -
>
> As the implementation
>
> 1) forrest will be used to generate the site from the contents of the
> repository
>
> 2) the repository can be either plain vanilla subversion or a webdav
> server implemented by cocoon on top of another repository (either
> subversion or catacomb or JSR170). even CVS, but we might want to stay
> away from it.
>
> 3) lenya will be used as the backend.
>
> Missing things:
>
> 1) is forrest already capable of doing what we ask?
Possibly. Forrest's sitemap is built in layers:
cocoon://**.xml # Source pipelines generating doc-v12
cocoon://body-*.html
cocoon://menu-*.html
cocoon://tabs-*.html # Intermediate formats
cocoon://**.{html,pdf} # Destination formats
So just switch in a different **.xml subsitemap, and Forrest will build
the site from whatever backend you choose.
Forrest's indirect linking system is (IMHO:) pretty cool and Wiki-like,
in that I can write <a href="site:foo"> from anywhere, and it links to
the 'foo' page wherever (or whatever) it is. The source files have a URI
space all of their own, independent of the final http: URI space.
The linking implementation is very flexible, built in input modules. <a
href="site:index"> causes the 'site' InputModule to be fetched and passed
the 'index' key. A SimpleMappingModule converts this to
'/site//index/@href', which is fed to an XMLModule, which interprets it
as an XPath into the navigation file, site.xml. As the XPath prefix and
suffix are configured in cocoon.xconf, any XML format for the 'linkmap'
(aka site.xml) can be used. Lots of gory details at
http://xml.apache.org/forrest/linking.html
> 2) what's the best repository? where do we install it?
>
> 3) is lenya enough for what we need? (Michi says so)
>
> 4) how much work is the integration of linotype with lenya? (I'll
> investigate this soon)
>
> 5) how do we get the wiki into the repository? (I plan to write a
> wiki-syntax editing pane for linotype, would this be enough?)
Could use the Chaperon Wiki grammar to convert to XML, but..
grammar-based validation results in really undecipherable error messages.
Might be best to first use a regular Wiki engine as a 'lexer', to get the
Wiki syntax 'well-formed', and then use a grammar to go from well-formed
Wiki -> XML, and then use an XML schema to ensure validity. 3-phase
validation of Wiki syntax. Could warrant a project all on its own..
> 6) how do we get the rest of the data into the repository?
>
> 7) how do we make it simple to edit linkmaps? what searching and
> proximity tools can we provide for this?
Lenya is probably the best hunting-ground for this.
--Jeff
> Enough of a braindump for now.
>
> Fire at will.
>
>
> --
> Stefano.
>
Re: [RT] Improved navigation of learning objects
Posted by Alan Gutierrez <al...@izzy.net>.
* Stefano Mazzocchi <st...@apache.org> [2003-10-12 16:04]:
> On Sunday, Oct 12, 2003, at 16:13 Europe/Rome, Alan Gutierrez wrote:
>
> >The trouble with Wiki and docs is that new users, such as myself,
> >are going to look for a documentation outline. A good TOC and index
> >makes all the differnece in the world when searching documentation.
>
> eheh, right on.
>
> >Has anyone discussed how to impose an outline on a Wiki?
>
> yes. there are some proposals on the table, ranging from simple to
> futuristic.
Did you just bang this out? Thanks for responding to my question so
thoroughly.
> - o -
>
> the simple one is a manually created single-dereferencing linkmap.
>
> Imagine that you have a repository with the following learning objects:
>
> /1
> /2
> /3
> /4
>
> which are edited and created individually. Then you have a linkmap that
> basically says
>
> Trail "A"
> /1
> Section "Whatever"
> /3
> /4
> Section "Somethign else"
> /2
>
> Trail "B"
> /4
> /1
>
> Trails are like "books", and they might share LOs. Trails might be
> published as a single PDF file for easier offline review.
>
> Trails can be used as "tabs" in the forrest view, while the rest is the
> navbar on the side.
>
> the LO identifier (http://cocoon.apache.org/LO/4) can be translated to
> a real locator (http://cocoon.apache.org/cocoon/2.1/A/introduction) and
> all the links rewritten accordingly.
>
> This link translation is a mechanical lookup, based on the linkmap
> information.
>
> [note: this is getting closer to what topic maps are about! see
> topicmaps.org, even if, IMO, it wouldn't make sense to use topic maps
> for this because they are much more complex]
An outline is a classic tool for organizing a document. This is the
aspect of content managment that I find interesting, creating a
mechanism for organization by an information architect. Searching is
well and good, but I've learned more from the "Cocoon Developers's
Handbook" in two hours than I've learned form the Cocoon Wiki in a
week.
Make this tedious task of link map creation simplier and you will
have an exciting solution for myriad business problems.
Creating the link map would be easier if the learning object was a
proscribed object, rather than a found object, the way things tend
to be in the semanitc web. Gathing up all the micro topics of a Wiki
has got to be akin to hearding cats. You might connect to a
two sentance learning object on the topic map, one only to have it
change meaning as people contribute to the object.
To my mind it is best to have a go between. A documentation Wiki
really ought to be documentation tasks that are pareceled out to the
community. There is a ready context for a contributors submission.
A topic map, or outline, that specifies topics. Sections are given
over to a tecnhical writer, who acts a maintainer. Wiki
contributions are attached to a topic in the outline, the maintainer
pulls relevent discussion up into the topic, editing it for
consistant style.
This is how good open source documentation is created anyway.
> - o -
>
> The approach above works but it requires two operations:
>
> 1) creation of the LO
> 2) connection of the LO in the linkmap
Or those operations could be inverted and iterative.
> - o -
> In the more futuristic approach, each learning object specifies two
> things:
>
> 1) what it expects the reader to know
> 2) what it expect to give to the reader
>
> Suppose that you have learning object library of
>
> /1 -(teaches)-> [a]
> /2 -(teaches)-> [a]
> [a] <-(expects)- /3 -(teaches)-> [b]
> [a] <-(expects)- /4 -(teaches)-> [c]
This to me is a parallel course to an outline. In many of the
cookbook style software texts I read, there is a see also section in
each recipie. The above would not replace an outline, but the
absence of the above shows a neglection of the medium of hypertext.
> - o -
>
> If each editor comes up with his own identifiers, we might have to
> issues:
>
> 1) identifiers are so precise that there is no match in between
> documents written by different people
>
> 2) identifiers are so broad in spectrum that concepts overlap and
> dependencies blur
>
> So we must find a way to come up with a system that helps us in the
> discovery, creation and correctness maintenance of a taxonomy, but
> without removing or overlapping human judgment.
Discovery, creation and correctness maintence. I'm repeating this
because they sound like the overarching goals of content managment.
I like this because it implies that a content managment system aids
decision making, rather than obsolesing decision making.
> - o -
>
> Here is a scenario of use (let's focus on text so, LO = page)
>
> a) you edit a page.
>
> b) you highlight the words in the page that you believe are important
> to identify the knowledge distilled in the page that is transmitted to
> the reader.
>
> c) you also highlight the words in the page that you believe identify
> the cognitive context that is required by the user to understand this
> page
>
> [this can be done very easily in the WYSIWIG editor, using different
> colors]
>
> c) when you are done, you submit the page into the system.
>
> d) the page gets processed against the existing repository.
>
> e) the system suggests you the topic that might be closer to your
> page, and you select the ones you think they fit the best. or you
> introduce a new one in case nothing fits.
>
> point d) seems critical in the overall smartness of the system, but I
> don't think it is since semantic estimation is done by humans on point
> e), point d) just has to be smart enough to remove all the pages that
> have nothing at all to do with the current learning object.
>
> Possible implementations are:
>
> - document vector space euclidean distance (used by most search
> engines, including google and lucene)
> - latent semantic distance (but this one is patented but it will
> expire in a few years, used for spam filtering by the Mail.app in
> MacOSX, used by the Microsoft Office help system and the assistant).
Democracy is another useful algortihm. (Altough, I'm giddy thinking
about the use of Google/Lucene not only to extract but to inject
content into a Web.) Moderation is one approach.
Prior to a) there is the contributors interataction with the system
that prompted the sumbission. The submission is not entirely
without context, so perhaps it is enough to inject the submission at
the point where the author got on board, just as I am injecting my
content into this thread here, and let the community move the
content around. That is, provide community tools for moderation and
classifcation. Heck, invite the community to highlight what they
feel are keywords as they read the document, feed that to Lucene.
> - o -
> The above model paints a double-dereference hypertext, sort of
> "polymorphic" hypertext where links are made to "abstract concepts"
> that are dereferenced against resource implicitly.
Help. Double-dereferenced? Polymorphic? Maybe I don't understand the
meaning of the word dereference in this context.
> In fact, navigation between learning objects can be:
>
> 1) hand written
> 2) inferred from the contextual dependencies
> 3) inferred from the usage patterns
For 3) keep in mind that once can trace a visitor's through the
documentation. These proximities can be fed to a search engine,
perhaps with feedback from the visitor. A link that says, I found
it! and/or a Did you find this useful? menu. (This is all being
done somewhere I am sure.)
> I believe that a system that is able to implement all of the above
> would prove to be a new kind of hypertext, much closer to the original
> Xanadu vision that Ted Nelson outlined in the '60s when he coined the
> term hypertext.
Lofty!
> I don't think we have to jump all the way up here, there are smaller
> steps that we can do to improve what we have, but this is where I want
> to go.
I am very interested in creating the tools to assist in the ceation
of the outline. I'd like to look at the problem from the persepctive
of a librarian (which I am not) or an editor.
I am intereseted in managing the content of a single project, rather
than managing a the content of an enormous organziation, or the
entire web. I want a document management system that gears itself
towards the publication of a document, with toc, index, chapters.
Collective Word Processing?
--
Alan Gutierrez - alan@agtrz.com - C:504.301.8807 - O:504.948.9237
RE: Forrest and the NDS (Re: [RT] Moving towards a new documentation system)
Posted by Reinhard Pötz <re...@gmx.net>.
From: Alan Gutierrez
> * Reinhard Poetz <re...@apache.org> [2003-10-12 14:06]:
>
> > Stefano envisions a system where it is very easy to edit
> content using
> > a WYSIWIG editor (no structured text, no strange XML) for
> *everybody*
> > by simply clicking on an 'edit' button - without having
> installed any
> > unknown software - and to the changes right at the moment when you
> > spot e.g. a spelling mistake. A Cocoon committer has to confirm the
> > changes or additions and then the new stuff is published
> > (mini-workflow).
> >
> > After a non-committer has provided e.g. 3 substantial
> patches to our
> > documentation or new documents he can get the status of a doc
> > committer and can publish directly without the confirmation of a
> > Cocoon CVS committer.
> >
> > With this simple system we can use the power of Wiki (everybody
> > becomes a doc author) and combine this with our requirement that we
> > *must* have a backend repository where we store our content
> in order
> > to be able to re-publish our website at every time.
>
> The trouble with Wiki and docs is that new users, such as
> myself,
Thank you! It is very appreciated to get feedback from new users!
> are going to look for a documentation outline. A good
> TOC and index makes all the differnece in the world when
> searching documentation. Has anyone discussed how to impose
> an outline on a Wiki?
In order to navigate through the many documents (Stefano calls them
'learning objects') in a plain structure which a Wiki-like system
provides there will be special documents which are tracks through the
forest of documents (e.g. How to setup Cocoon?, Write your first sitemap
component, ...).
Reinhard
Re: [RT] Improved navigation of learning objects
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Oct 13, 2003, at 07:48 Europe/Rome, Andreas Hochsteger wrote:
> Hi Stefano!
>
> Stefano Mazzocchi wrote:
> > The approach above works but it requires two operations:
> >
> > 1) creation of the LO
> > 2) connection of the LO in the linkmap
>
> Can you explain to me, why you are always talking from learning
> objects in this context?
>
> Isn't a learning object a bit too specific to be used as a general
> term?
>
> Here's a list of documents which might be published on the Cocoon
> website with a classification if LO is suitable or not:
> * HOWTOs (LO fits)
> * FAQs (LO fits)
> * Tutorials (LO fits)
> * Guides (LO fits)
> * References (LO fits?)
> - Cocoon Component Reference
> - Cocoon URI Reference
> - Cocoon XML Schema Reference
> * News (LO doesn't fit)
> * Status information (LO doesn't fit)
> - Changes, Todo, Planning notes, ...
> * Release notes (LO doesn't fit)
> * Event reports (LO doesn't fit)
> * Links (LO doesn't fit)
> * ... many more where LO would fit and not
>
> As far as I see it a document would still be the more generic term and
> a LO a certain subclass of documents (HOWTOs, FAQs, Tutorials, Guides,
> ...), where the user can really learn something.
>
> What do you think?
It's a matter of terminology and communicating with a intermediate
natural language doesn't help, but I think that "learning" is the act
of increasing (or modifying!) the state of your cognitive abilities
(aka knowledge and ability to interoperate with your environment,
physical and mental)
definitions of "learning object" are:
http://labs.google.com/
glossary?q=learning+object&btnG=Google+Glossary+Search
I personally believe that e-learning (as much as web services) is just
a marketing term to refer to something that we've been doing since the
web was started.
anyway, it's a philosophical detail: I think everything that we have in
our documentation is a learning object, but if you don't, it's not a
problem and we can get back to call them "pages".
But it would feel strange, though, to have the "video" of Sylvain's
presentation about woody called "page".
We could call them "resources" (just like the URI RFC does), but then
we would have to distinguish between resources created for human
consumption and resources created for machine consumption.
My definition of a learning object is: a particular kind of web
resource created for human consumption that can be referenced directly
or indirectly thru the cognitive contexts that it exposes.
I don't think anybody would agree with me on that. It's just my
personal view of the matter (some people have a more restricted
definition of what a learning object is) and I'm fine with any other
terminology, as long as the functionality of indirect referencing is
taken into account.
--
Stefano.
Re: [RT] Improved navigation of learning objects
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Hi Stefano!
Stefano Mazzocchi wrote:
> The approach above works but it requires two operations:
>
> 1) creation of the LO
> 2) connection of the LO in the linkmap
Can you explain to me, why you are always talking from learning objects
in this context?
Isn't a learning object a bit too specific to be used as a general term?
Here's a list of documents which might be published on the Cocoon
website with a classification if LO is suitable or not:
* HOWTOs (LO fits)
* FAQs (LO fits)
* Tutorials (LO fits)
* Guides (LO fits)
* References (LO fits?)
- Cocoon Component Reference
- Cocoon URI Reference
- Cocoon XML Schema Reference
* News (LO doesn't fit)
* Status information (LO doesn't fit)
- Changes, Todo, Planning notes, ...
* Release notes (LO doesn't fit)
* Event reports (LO doesn't fit)
* Links (LO doesn't fit)
* ... many more where LO would fit and not
As far as I see it a document would still be the more generic term and a
LO a certain subclass of documents (HOWTOs, FAQs, Tutorials, Guides,
...), where the user can really learn something.
What do you think?
> Stefano.
Bye,
Andreas
Re: [RT] Improved navigation of learning objects
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>
> On Sunday, Oct 12, 2003, at 16:13 Europe/Rome, Alan Gutierrez wrote:
>
>> The trouble with Wiki and docs is that new users, such as myself,
>> are going to look for a documentation outline. A good TOC and index
>> makes all the differnece in the world when searching documentation.
>
>
> eheh, right on.
>
>> Has anyone discussed how to impose an outline on a Wiki?
>
>
> yes. there are some proposals on the table, ranging from simple to
> futuristic.
>
> - o -
>
> the simple one is a manually created single-dereferencing linkmap.
>
> Imagine that you have a repository with the following learning objects:
>
> /1
> /2
> /3
> /4
>
> which are edited and created individually. Then you have a linkmap
> that basically says
>
> Trail "A"
> /1
> Section "Whatever"
> /3
> /4
> Section "Somethign else"
> /2
>
> Trail "B"
> /4
> /1
>
> Trails are like "books", and they might share LOs. Trails might be
> published as a single PDF file for easier offline review.
>
> Trails can be used as "tabs" in the forrest view, while the rest is
> the navbar on the side.
>
> the LO identifier (http://cocoon.apache.org/LO/4) can be translated to
> a real locator (http://cocoon.apache.org/cocoon/2.1/A/introduction)
> and all the links rewritten accordingly.
I like being able to have meaningful URLs as this is something that I
can remember (yeah, my bookmarks file is in my head). On the other hand,
this also means that a single LO will have several URLs depending on the
considered trail.
What would be good is to have in the page displaying a LO the list of
the trails where this LO appears (i.e. it's other URLs). This would
allow to explore other trails related to a given subject, and hence help
to achieve the cognitive dissonance required to engrave the LO in the
reader's mind.
<snip what="super great RT"/>
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Improved navigation of learning objects
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Oct 13, 2003, at 15:12 Europe/Rome, Bertrand Delacretaz
wrote:
> Le Lundi, 13 oct 2003, à 14:57 Europe/Zurich, Stefano Mazzocchi a
> écrit :
>
>>> ...Some form of topic map would be useful to build "what's related"
>>> info though, which helps navigation and discovery a lot.
>>
>> Yes, but such a topic maps would have to be human edited. this is
>> what scares me. tools for ontology creation (like Protege,
>> http://protege.stanford.edu/ for example) are available but are
>> *incredibly* complex to to use.
>
> I was thinking of something simple, I think even just "broader term
> (BT)" / "narrower term (NT)" relationships (like in a thesaurus) would
> help find a lot of related stuff, conceptually something like:
>
> cocoon
> NT: sitemap
> sitemap
> NT: matcher
> NT: sitemap configuration
> matcher
> NT: matcher pattern
>
> This would be an XML file from which a Generator could build a
> bidirectional tree of narrower/broader terms. Clearly not a full-blown
> topic map, but lightweight and easy to improve incrementally, we could
> start with a limited set of terms and already have something useful
> once learning objects are connected (by numerical IDs if we want this
> to be solid) to relevant terms.
>
> But this is something that needs to be tested on a prototype to see
> how useful/easy it is.
sound good to me.
--
Stefano.
Re: [RT] Improved navigation of learning objects
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 13 oct 2003, à 14:57 Europe/Zurich, Stefano Mazzocchi a écrit
:
>> ...Some form of topic map would be useful to build "what's related"
>> info though, which helps navigation and discovery a lot.
>
> Yes, but such a topic maps would have to be human edited. this is what
> scares me. tools for ontology creation (like Protege,
> http://protege.stanford.edu/ for example) are available but are
> *incredibly* complex to to use.
I was thinking of something simple, I think even just "broader term
(BT)" / "narrower term (NT)" relationships (like in a thesaurus) would
help find a lot of related stuff, conceptually something like:
cocoon
NT: sitemap
sitemap
NT: matcher
NT: sitemap configuration
matcher
NT: matcher pattern
This would be an XML file from which a Generator could build a
bidirectional tree of narrower/broader terms. Clearly not a full-blown
topic map, but lightweight and easy to improve incrementally, we could
start with a limited set of terms and already have something useful
once learning objects are connected (by numerical IDs if we want this
to be solid) to relevant terms.
But this is something that needs to be tested on a prototype to see how
useful/easy it is.
-Bertrand
Re: [RT] Improved navigation of learning objects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
...
> "automatic harvesting" scares the crap out of me, Conal.
We will probably be moving the Forrest DTD to XHTML2 in one of the next
things to do. As you know, there are <meta> tags that are a nice way of
adding additional info in the page.
http://academ.hvcc.edu/~kantopet/xhtml/index.php?page=xhtml+meta+content
"
Types of meta-information include:
* The contents and topics of the document.
* The relation of this document to other documents.
* The type of document. In other words, is it a text document or
an image, etc.
* Information to assist users in navigating the content.
* Information to assist programs in accessing or processing
the content.
"
It's also possible to make a page tell which is the next and previous,
and some browsers like Mozilla or Firebird are able to navigate in that too.
> I agree that there must be some kind of automatism going on, but the
> topic creation is a human task and programs would do a terrible job at
> doing this.
It's still humans editing them, but the information can be scattered in
the documents themselves.
> but anyway, we decided to do a first step with handwritten linkmaps. we
> can move incrementally from there on.
What I see is that metadata in the docs cannot and should not totally
replace a centralized bell-written site.xml, but can nicely complement it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Improved navigation of learning objects
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Oct 14, 2003, at 20:42 Europe/Rome, Conal Tuohy wrote:
> Stefano wrote:
>
>> "automatic harvesting" scares the crap out of me, Conal.
>
> This is conceptually no different to harvesting JavaDoc tags from Java
> source.
good point.
>> I agree that there must be some kind of automatism going on, but the
>> topic creation is a human task and programs would do a
>> terrible job at
>> doing this.
>
> The example I gave assumed precisely that a human editor had written a
> namespace topic; the harvester was simply linking a document (which
> mentioned that namespace) to that existing topic. So this is automatic
> creation of associations or links, rather than topics.
yes, but this is simply spreading the issue of topic creation all over
the place, you are not making it any easier (IMHO)
> But topics can also be safely created automatically in some cases:
> where
> good structured metadata exists we can confidently base topics on it.
> e.g.
> topics can usefully be automatically harvested from Java classes that
> implement particular interfaces (generators, transformers, etc).
True, but again, I don't see the point. I'm sure that if we make the
editing interface to our doc system people will find it much easier to
just make a list of components and update them as we go (expecially
since they are not so many).
>> but anyway, we decided to do a first step with handwritten
>> linkmaps. we
>> can move incrementally from there on.
>
> Yes that's true.
>
> What I particularly like about TM is that they invert the usual
> relationship
> of resources to metadata - in a TM the topics are central and the
> resources
> are attached to them. So the key activity is to identify the high-level
> topics (the ontology) and then build a harvester to link your
> resources to
> the topics in the ontology. This linking can be done by recognising
> patterns
> in the resources (e.g. a reference to a namespace), or, better, by
> recognising explicit metadata (e.g. JavaDoc).
Very true.
--
Stefano.
RE: [RT] Improved navigation of learning objects
Posted by Conal Tuohy <co...@paradise.net.nz>.
Stefano wrote:
> "automatic harvesting" scares the crap out of me, Conal.
This is conceptually no different to harvesting JavaDoc tags from Java
source.
> I agree that there must be some kind of automatism going on, but the
> topic creation is a human task and programs would do a
> terrible job at
> doing this.
The example I gave assumed precisely that a human editor had written a
namespace topic; the harvester was simply linking a document (which
mentioned that namespace) to that existing topic. So this is automatic
creation of associations or links, rather than topics.
But topics can also be safely created automatically in some cases: where
good structured metadata exists we can confidently base topics on it. e.g.
topics can usefully be automatically harvested from Java classes that
implement particular interfaces (generators, transformers, etc).
> but anyway, we decided to do a first step with handwritten
> linkmaps. we
> can move incrementally from there on.
Yes that's true.
What I particularly like about TM is that they invert the usual relationship
of resources to metadata - in a TM the topics are central and the resources
are attached to them. So the key activity is to identify the high-level
topics (the ontology) and then build a harvester to link your resources to
the topics in the ontology. This linking can be done by recognising patterns
in the resources (e.g. a reference to a namespace), or, better, by
recognising explicit metadata (e.g. JavaDoc).
Cheers
Con
Re: [RT] Improved navigation of learning objects
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Oct 13, 2003, at 22:57 Europe/Rome, Conal Tuohy wrote:
> Bertrand Delacretaz wrote:
>
>>> Some form of topic map would be useful to build "what's
>> related" info
>>> though, which helps navigation and discovery a lot.
>
> Stefano Mazzocchi wrote:
>
>> Yes, but such a topic maps would have to be human edited.
>> this is what
>> scares me. tools for ontology creation (like Protege,
>> http://protege.stanford.edu/ for example) are available but are
>> *incredibly* complex to to use.
>
> Certainly some, but not all of this topic map needs to be
> human-edited. I
> think a basic ontology could be written by hand in a text editor and
> still
> be large enough to be usable. NB there are other sytaxes for authoring
> topic
> maps which are simpler than XTM, too.
>
> To be useful, a hand-written ontology would only need to cover some of
> the
> core concepts such as "namespace", "component", "block", "howto",
> "generator", "transformer". The bulk of the topics and relationships
> are
> implicit in the docs, and could be automatically harvested into XTM
> with a
> bunch of XML stylesheets, and linked to the underlying ontology.
>
> For instance, references to java classes, XML namespaces, etc could be
> automatically harvested from xdocs:
>
> <xsl:template
> match="source[contains(.,'http://apache.org/cocoon/request/2.0')]"
> mode="harvest-namespace-topics">
> <!--
> This document contains a reference to the request namespace,
> so it can be harvested as an occurrence of the namespace's topic
> -->
> <xtm:topic>
> <!-- topic for the request namespace -->
> <xtm:subjectIdentity>
> <xtm:subjectIndicatorRef
> xlink:href="http://apache.org/cocoon/request/2.0"/>
> </xtm:subjectIdentity>
> <!-- this occurrence -->
> <xtm:occurrence>
> <xtm:resourceRef xlink:href="{$current-page-url}"/>
> </xtm:occurrence>
> </xsl:template>
>
> <xsl:template match="source[contains(.,'org.apache.cocoon.')]">
> <!-- reference to a cocoon class: -->
> <!-- harvest the class-name and link this resource to the topic
> reifying
> that class -->
> etc.
> </xsl:template>
>
>
> A topic map layer could be harvested not just from the docs, but also
> from
> the Wiki, the javadoc, the cvs, etc, etc, and the resulting topics
> merged to
> reveal the relationships which are currently produced by hand. Then
> you can
> define a website FROM the topic map. Also, of course, you can use
> other TM
> tools such as the tm-visualiser "tmnav" which displays the topic map
> using
> the TouchGraph component.
"automatic harvesting" scares the crap out of me, Conal.
I agree that there must be some kind of automatism going on, but the
topic creation is a human task and programs would do a terrible job at
doing this.
but anyway, we decided to do a first step with handwritten linkmaps. we
can move incrementally from there on.
--
Stefano.
RE: [RT] Improved navigation of learning objects
Posted by Conal Tuohy <co...@paradise.net.nz>.
Bertrand Delacretaz wrote:
> > Some form of topic map would be useful to build "what's
> related" info
> > though, which helps navigation and discovery a lot.
Stefano Mazzocchi wrote:
> Yes, but such a topic maps would have to be human edited.
> this is what
> scares me. tools for ontology creation (like Protege,
> http://protege.stanford.edu/ for example) are available but are
> *incredibly* complex to to use.
Certainly some, but not all of this topic map needs to be human-edited. I
think a basic ontology could be written by hand in a text editor and still
be large enough to be usable. NB there are other sytaxes for authoring topic
maps which are simpler than XTM, too.
To be useful, a hand-written ontology would only need to cover some of the
core concepts such as "namespace", "component", "block", "howto",
"generator", "transformer". The bulk of the topics and relationships are
implicit in the docs, and could be automatically harvested into XTM with a
bunch of XML stylesheets, and linked to the underlying ontology.
For instance, references to java classes, XML namespaces, etc could be
automatically harvested from xdocs:
<xsl:template
match="source[contains(.,'http://apache.org/cocoon/request/2.0')]"
mode="harvest-namespace-topics">
<!--
This document contains a reference to the request namespace,
so it can be harvested as an occurrence of the namespace's topic
-->
<xtm:topic>
<!-- topic for the request namespace -->
<xtm:subjectIdentity>
<xtm:subjectIndicatorRef
xlink:href="http://apache.org/cocoon/request/2.0"/>
</xtm:subjectIdentity>
<!-- this occurrence -->
<xtm:occurrence>
<xtm:resourceRef xlink:href="{$current-page-url}"/>
</xtm:occurrence>
</xsl:template>
<xsl:template match="source[contains(.,'org.apache.cocoon.')]">
<!-- reference to a cocoon class: -->
<!-- harvest the class-name and link this resource to the topic reifying
that class -->
etc.
</xsl:template>
A topic map layer could be harvested not just from the docs, but also from
the Wiki, the javadoc, the cvs, etc, etc, and the resulting topics merged to
reveal the relationships which are currently produced by hand. Then you can
define a website FROM the topic map. Also, of course, you can use other TM
tools such as the tm-visualiser "tmnav" which displays the topic map using
the TouchGraph component.
Cheers
Con
Re: [RT] Improved navigation of learning objects
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Oct 13, 2003, at 09:36 Europe/Rome, Bertrand Delacretaz
wrote:
> Le Dimanche, 12 oct 2003, à 17:55 Europe/Zurich, Stefano Mazzocchi a
> écrit :
>> On Sunday, Oct 12, 2003, at 16:13 Europe/Rome, Alan Gutierrez wrote:
>>> ....Has anyone discussed how to impose an outline on a Wiki?
>>
>> yes. there are some proposals on the table, ranging from simple to
>> futuristic....
>
> I think we should concentrate on the simple one for now, maybe by
> creating an experimental block to work on a prototype?
> We could copy the existing docs there, assign unique IDs to them and
> start playing with trails.
> Having permanent IDs leaves room for the futuristic stuff to emerge.
exactly, create a foundation solid enough for us to build upon, but
without forcing the futuristic stuff to slow us down.
>> ...[note: this is getting closer to what topic maps are about! see
>> topicmaps.org, even if, IMO, it wouldn't make sense to use topic maps
>> for this because they are much more complex]
>
> Some form of topic map would be useful to build "what's related" info
> though, which helps navigation and discovery a lot.
Yes, but such a topic maps would have to be human edited. this is what
scares me. tools for ontology creation (like Protege,
http://protege.stanford.edu/ for example) are available but are
*incredibly* complex to to use.
> <snip very-interesting-futuristic-stuff>
> Thanks for sharing this!
my pleasure.
I'm going to research a lot on this in the future and I would like to
use the cocoon community as a "beta testing" of the community dynamics
on top of this. it might take a while, but I'm a patient guy ;-)
--
Stefano.
Re: [RT] Improved navigation of learning objects
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Dimanche, 12 oct 2003, à 17:55 Europe/Zurich, Stefano Mazzocchi a
écrit :
> On Sunday, Oct 12, 2003, at 16:13 Europe/Rome, Alan Gutierrez wrote:
>> ....Has anyone discussed how to impose an outline on a Wiki?
>
> yes. there are some proposals on the table, ranging from simple to
> futuristic....
I think we should concentrate on the simple one for now, maybe by
creating an experimental block to work on a prototype?
We could copy the existing docs there, assign unique IDs to them and
start playing with trails.
Having permanent IDs leaves room for the futuristic stuff to emerge.
> ...[note: this is getting closer to what topic maps are about! see
> topicmaps.org, even if, IMO, it wouldn't make sense to use topic maps
> for this because they are much more complex]
Some form of topic map would be useful to build "what's related" info
though, which helps navigation and discovery a lot.
<snip very-interesting-futuristic-stuff>
Thanks for sharing this!
-Bertrand
fyi: agora
Posted by Robert Koberg <ro...@koberg.com>.
Not just for social engineering anymore :)
http://www.agora.de/eng/index.html
[RT] Improved navigation of learning objects
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Oct 12, 2003, at 16:13 Europe/Rome, Alan Gutierrez wrote:
> The trouble with Wiki and docs is that new users, such as myself,
> are going to look for a documentation outline. A good TOC and index
> makes all the differnece in the world when searching documentation.
eheh, right on.
> Has anyone discussed how to impose an outline on a Wiki?
yes. there are some proposals on the table, ranging from simple to
futuristic.
- o -
the simple one is a manually created single-dereferencing linkmap.
Imagine that you have a repository with the following learning objects:
/1
/2
/3
/4
which are edited and created individually. Then you have a linkmap that
basically says
Trail "A"
/1
Section "Whatever"
/3
/4
Section "Somethign else"
/2
Trail "B"
/4
/1
Trails are like "books", and they might share LOs. Trails might be
published as a single PDF file for easier offline review.
Trails can be used as "tabs" in the forrest view, while the rest is the
navbar on the side.
the LO identifier (http://cocoon.apache.org/LO/4) can be translated to
a real locator (http://cocoon.apache.org/cocoon/2.1/A/introduction) and
all the links rewritten accordingly.
This link translation is a mechanical lookup, based on the linkmap
information.
[note: this is getting closer to what topic maps are about! see
topicmaps.org, even if, IMO, it wouldn't make sense to use topic maps
for this because they are much more complex]
- o -
The approach above works but it requires two operations:
1) creation of the LO
2) connection of the LO in the linkmap
It is entirely possible to have a page that lists all the LO, but it
would be pretty useless. It is also possible to find a LO by
searching... this is normally how wikis are accessed, but it would be
better to find a way to have LO "self connecting".
- o -
In the more futuristic approach, each learning object specifies two
things:
1) what it expects the reader to know
2) what it expect to give to the reader
the above reflects a mechanical model of the theory of cognition that
indicates that information is transformed into knowledge by projection
onto the existing cognitive context.
Suppose that you have learning object library of
/1 -(teaches)-> [a]
/2 -(teaches)-> [a]
[a] <-(expects)- /3 -(teaches)-> [b]
[a] <-(expects)- /4 -(teaches)-> [c]
now you add a new learning object indicating
[c] <-(expects)- /5 -(teaches)-> [b]
and you can infer that
[a] <-(expects)- /4+/5 -(teaches)-> [b]
therefore
/3 and /4+/5
are cognitively related
- o -
The above is nice and good, but we hit the big wall: who defines the
taxonomy and how.
The taxonomy is the collection of all those identifiers that [a]
identify abstract concepts.
If each editor comes up with his own identifiers, we might have to
issues:
1) identifiers are so precise that there is no match in between
documents written by different people
2) identifiers are so broad in spectrum that concepts overlap and
dependencies blur
This is, IMHO, the biggest problem that the semantic web has to face.
The RDF/RDFSchema/OWL stack is very nice. A piece of art once you get
it (and I still don't, but the fog is starting to clear up a little),
but it's all based on taxonomical or ontological contracts... which
are, IMO, the most painful and expensive thing to create an maintain.
So we must find a way to come up with a system that helps us in the
discovery, creation and correctness maintenance of a taxonomy, but
without removing or overlapping human judgment.
- o -
Here is a scenario of use (let's focus on text so, LO = page)
a) you edit a page.
b) you highlight the words in the page that you believe are important
to identify the knowledge distilled in the page that is transmitted to
the reader.
c) you also highlight the words in the page that you believe identify
the cognitive context that is required by the user to understand this
page
[this can be done very easily in the WYSIWIG editor, using different
colors]
c) when you are done, you submit the page into the system.
d) the page gets processed against the existing repository.
e) the system suggests you the topic that might be closer to your
page, and you select the ones you think they fit the best. or you
introduce a new one in case nothing fits.
point d) seems critical in the overall smartness of the system, but I
don't think it is since semantic estimation is done by humans on point
e), point d) just has to be smart enough to remove all the pages that
have nothing at all to do with the current learning object.
Possible implementations are:
- document vector space euclidean distance (used by most search
engines, including google and lucene)
- latent semantic distance (but this one is patented but it will
expire in a few years, used for spam filtering by the Mail.app in
MacOSX, used by the Microsoft Office help system and the assistant).
- o -
The above model paints a double-dereference hypertext, sort of
"polymorphic" hypertext where links are made to "abstract concepts"
that are dereferenced against resource implicitly.
This allows the structure of the system and the navigation between LO
to grow independently, using information from the various contextual
dependencies and from the analysis of the use of the learning objects
from the uses.
In fact, navigation between learning objects can be:
1) hand written
2) inferred from the contextual dependencies
3) inferred from the usage patterns
I believe that a system that is able to implement all of the above
would prove to be a new kind of hypertext, much closer to the original
Xanadu vision that Ted Nelson outlined in the '60s when he coined the
term hypertext.
I don't think we have to jump all the way up here, there are smaller
steps that we can do to improve what we have, but this is where I want
to go.
--
Stefano.
RE: Forrest and the NDS (Re: [RT] Moving towards a new documentation system)
Posted by Reinhard Poetz <re...@apache.org>.
From: Alan Gutierrez
> * Reinhard Poetz <re...@apache.org> [2003-10-12 14:06]:
>
> > Stefano envisions a system where it is very easy to edit
> content using
> > a WYSIWIG editor (no structured text, no strange XML) for
> *everybody*
> > by simply clicking on an 'edit' button - without having
> installed any
> > unknown software - and to the changes right at the moment when you
> > spot e.g. a spelling mistake. A Cocoon committer has to confirm the
> > changes or additions and then the new stuff is published
> > (mini-workflow).
> >
> > After a non-committer has provided e.g. 3 substantial
> patches to our
> > documentation or new documents he can get the status of a doc
> > committer and can publish directly without the confirmation of a
> > Cocoon CVS committer.
> >
> > With this simple system we can use the power of Wiki (everybody
> > becomes a doc author) and combine this with our requirement that we
> > *must* have a backend repository where we store our content
> in order
> > to be able to re-publish our website at every time.
>
> The trouble with Wiki and docs is that new users, such as myself,
Thank you! It is very appreciated to get feedback from new users!
> are going to look for a documentation outline. A good
> TOC and index makes all the differnece in the world when
> searching documentation. Has anyone discussed how to impose
> an outline on a Wiki?
In order to navigate through the many documents (Stefano calls them
'learning objects') in a plain structure which a Wiki-like system
provides there will be special documents which are tracks through the
forest of documents (e.g. How to setup Cocoon?, Write your first sitemap
component, ...).
Reinhard
Re: Forrest and the NDS (Re: [RT] Moving towards a new documentation system)
Posted by Alan Gutierrez <al...@agtrz.com>.
* Reinhard Poetz <re...@apache.org> [2003-10-12 14:06]:
> Stefano envisions a system where it is very easy to edit content using a
> WYSIWIG editor (no structured text, no strange XML) for *everybody* by
> simply clicking on an 'edit' button - without having installed any
> unknown software - and to the changes right at the moment when you spot
> e.g. a spelling mistake. A Cocoon committer has to confirm the changes
> or additions and then the new stuff is published (mini-workflow).
>
> After a non-committer has provided e.g. 3 substantial patches to our
> documentation or new documents he can get the status of a doc committer
> and can publish directly without the confirmation of a Cocoon CVS
> committer.
>
> With this simple system we can use the power of Wiki (everybody becomes
> a doc author) and combine this with our requirement that we *must* have
> a backend repository where we store our content in order to be able to
> re-publish our website at every time.
The trouble with Wiki and docs is that new users, such as myself,
are going to look for a documentation outline. A good TOC and index
makes all the differnece in the world when searching documentation.
Has anyone discussed how to impose an outline on a Wiki?
--
Alan Gutierrez - alan@agtrz.com - C:504.301.8807 - O:504.948.9237
Re: Forrest and the NDS (Re: [RT] Moving towards a new documentation system)
Posted by Alan Gutierrez <al...@agtrz.com>.
* Jeff Turner <je...@apache.org> [2003-10-12 12:27]:
> On Sun, Oct 12, 2003 at 12:40:39PM +0200, Stefano Mazzocchi wrote:
> ...
> > In case something is not clear, I'll be very happy to explain it.
>
> My main question is: to users, how is this system functionally different
> from a Wiki? Eg, a good one that has 'related pages' inferred from the
> page's content:
>
> http://wiki.opensymphony.com/space/WebWork+2+Components
>
> And a naive question: wouldn't Subversion be a better backend than this
> JSR170 thing? Then developers could store xdocs in the same repository
> as code, and could check in updates with standard svn tools (including
> IDEs).
It looks like JSR170 is an API specification, so one can create an
API for Subversion. It is important that there is an API for
Subversion available however. Also, if this is to be a Cocoon
application, wouldn't it be _nice to have_ a content management
system that creates XML deltas of XML data?
--
Alan Gutierrez - alan@agtrz.com - C:504.301.8807 - O:504.948.9237
Re: Forrest and the NDS
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Oct 12, 2003, at 14:31 Europe/Rome, Jeff Turner wrote:
> On Sun, Oct 12, 2003 at 12:40:39PM +0200, Stefano Mazzocchi wrote:
> ...
>> In case something is not clear, I'll be very happy to explain it.
>
> My main question is: to users, how is this system functionally
> different
> from a Wiki?
for editing, you will get a three-pane editor:
- wysiwig
- xhtml source
- wiki source
and you can switch between one and another, depending on what you like
the most (or what type of content you have to cut/paste from outside
the editor)
> Eg, a good one that has 'related pages' inferred from the
> page's content:
>
> http://wiki.opensymphony.com/space/WebWork+2+Components
Yes, SnipSnap. I had some private email conversation with the guys at
Fraunhofer, at some point they wanted to use cocoon for it (IIRC) but
they decided it was too complex for their needs.
The ideas are very similar, in fact.
What I dislike is the weblog-ish appearence... from a navigational
perspective, it's too hyperlinked for my own taste, a documentation
system should help me go thru, it should guide me, not give me tons of
potential choices and make me choose all the time.
both wikis and weblogs tend to lack a navigation system. it's basically
what allowed them to grow exponentially. but we need to find a way to
distill some structure and guide our readers... but without limiting
the power of expressiveness of an unstructured collection of notes.
> And a naive question: wouldn't Subversion be a better backend than this
> JSR170 thing? Then developers could store xdocs in the same repository
> as code, and could check in updates with standard svn tools (including
> IDEs).
the goal is to have the backend so friendly that you'd never use the
repository directly anyway.
but as I said, a webdav repository is the best choice for now (and
subversion is a good choice for that); we can move on JSR 170 would the
need emerge (I think it will, but I can't predict when)
--
Stefano.
RE: Forrest and the NDS (Re: [RT] Moving towards a new documentation system)
Posted by Reinhard Poetz <re...@apache.org>.
From: Jeff Turner
> On Sun, Oct 12, 2003 at 12:40:39PM +0200, Stefano Mazzocchi wrote: ...
> > In case something is not clear, I'll be very happy to explain it.
>
> My main question is: to users, how is this system
> functionally different from a Wiki? Eg, a good one that has
> 'related pages' inferred from the page's content:
>
> http://wiki.opensymphony.com/space/WebWork+2+Components
>
> And a naive question: wouldn't Subversion be a better backend
> than this JSR170 thing?
JSR170 is the draft to come up with *one* API for all repositories. This
makes sense from a technical point of view but also it will be the first
time that we all have a common understanding what a repository is (where
does it start? where does it end?)
Back to your question: IMHO Subversion would be a good choice to be the
backend but behind a JSR170-API layer. (see
http://www.apache.org/dist/cocoon/events/gt2003/presentations/17-cocoon-
webdav.pdf)
> Then developers could store xdocs in
> the same repository as code, and could check in updates with
> standard svn tools (including IDEs).
Wiki lowered the barrier to become editor and to contribute to a project
and people love to use it. Also many committers (including myself) like
it more to write a new text at the Wiki than to edit XML for our
'official' docu.
Stefano envisions a system where it is very easy to edit content using a
WYSIWIG editor (no structured text, no strange XML) for *everybody* by
simply clicking on an 'edit' button - without having installed any
unknown software - and to the changes right at the moment when you spot
e.g. a spelling mistake. A Cocoon committer has to confirm the changes
or additions and then the new stuff is published (mini-workflow).
After a non-committer has provided e.g. 3 substantial patches to our
documentation or new documents he can get the status of a doc committer
and can publish directly without the confirmation of a Cocoon CVS
committer.
With this simple system we can use the power of Wiki (everybody becomes
a doc author) and combine this with our requirement that we *must* have
a backend repository where we store our content in order to be able to
re-publish our website at every time.
Reinhard
Re: Forrest and the NDS (Re: [RT] Moving towards a new documentation system)
Posted by Jeff Turner <je...@apache.org>.
On Sun, Oct 12, 2003 at 12:40:39PM +0200, Stefano Mazzocchi wrote:
...
> In case something is not clear, I'll be very happy to explain it.
My main question is: to users, how is this system functionally different
from a Wiki? Eg, a good one that has 'related pages' inferred from the
page's content:
http://wiki.opensymphony.com/space/WebWork+2+Components
And a naive question: wouldn't Subversion be a better backend than this
JSR170 thing? Then developers could store xdocs in the same repository
as code, and could check in updates with standard svn tools (including
IDEs).
Thanks,
--Jeff
> --
> Stefano.
>
Re: Forrest and the NDS (Re: [RT] Moving towards a new documentation system)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Dimanche, 12 oct 2003, à 12:40 Europe/Zurich, Stefano Mazzocchi a
écrit :
>
> On Sunday, Oct 12, 2003, at 04:23 Europe/Rome, Jeff Turner wrote:
>> ...
>> :) Let's remember that there's hard reuse and soft reuse. Hard reuse
>> means physically integrating with Forrest/Lenya. Soft reuse means
>> reusing ideas, people, and code where appropriate. For a new project
>> in
>> RT phase, worrying about hard reuse with Forrest and Lenya would IMHO
>> just slow things down.
>
> I agree: try to come up with a system that runs first and *after* try
> to merge the results and possible changes back in the original
> systems. This reduces the potential community friction when changes
> require some little paradigm shifts.
How about creating an "nds" (or "learningtrove") block and work more or
less as I outlined in the original message:
-copy all existing docs to a single directory, "big bag of docs", in
this new block
-rename docs as needed to give them permanent names (=numeric IDs)
-create a very simple publishing system for now
-start building the navigations, trails, tables of contents
incrementally
-if the docs format changes for the new doc management system,
navigation definitions stay valid
I like the idea of temporarily forgetting about Forrest and Lenya: a
simple prototype with minimal constaints would help this move forward,
and we can later backport the good ideas where they belong.
-Bertrand
Re: Forrest and the NDS (Re: [RT] Moving towards a new documentation system)
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Oct 12, 2003, at 04:23 Europe/Rome, Jeff Turner wrote:
> On Sat, Oct 11, 2003 at 03:17:48PM +0200, Stefano Mazzocchi wrote:
>>
>> On Saturday, Oct 11, 2003, at 14:25 Europe/Rome, Nicola Ken Barozzi
>> wrote:
>>
>>> Please don't forget Forrest.
>>
>> we are not.
>
> :) Let's remember that there's hard reuse and soft reuse. Hard reuse
> means physically integrating with Forrest/Lenya. Soft reuse means
> reusing ideas, people, and code where appropriate. For a new project
> in
> RT phase, worrying about hard reuse with Forrest and Lenya would IMHO
> just slow things down.
I agree: try to come up with a system that runs first and *after* try
to merge the results and possible changes back in the original systems.
This reduces the potential community friction when changes require some
little paradigm shifts.
> Forrest started with a RT, a mailing list, and a bunch of Cocooners
> willing to contribute. I wasn't at the GetTogether. I've never seen a
> RT articulating the vision for this project. There's just tantalising
> snippets. Could we perhaps dream up a name ('linotype' seems obvious),
> start a mailing list, and have some RTs on what this is all about? :)
That's what we are trying to do with this thread, Jeff, get a name, a
collection of random thoughts and get going. I don't think we need a
different list for now.
The things that were discussed at the hackaton were simply
higher-bandwidth version of this conversation. And Bertrand started it
over in order for everybody to know what were talked about and having
the ability to jump in and help.
In case something is not clear, I'll be very happy to explain it.
>> I thought about it and I totally resonate with Bertrand: we need to
>> outline an incremental transition to our own CMS reusing as much dog
>> food as possible (which is also good for a community perspective).
>>
>> Here is my proposal:
>>
>> 1) the system gets divided into three parts
>>
>> - frontend -> mapped to http://cocoon.apache.org -> static
>> - repository -> a WebDAV server
>> - backend -> mapped to http://edit.cocoon.apache.org -> dynamic
>
> The mozilla.org site does something similar, in that the 'edit this
> page'
> link goes to:
>
> http://doctor.mozilla.org/?file=mozilla-org//html/index.html
>
> I've long thought this would be a great Forrest enhancement.
exactly. Zope does similar things as well.
It's been 3 years I wanted to implement this in cocoon
(frontend/repository/backend architecture)... the incubation of lenya
was instrumenting for this. also the creation of linotype
(experimenting with serious editing, repository separation and
numberical URIs).
the wiki forced me to realize it's now time to move on and the hackaton
gave me a way to express myself clear enough so that others were
tickled by it.
>> The future idea is to use indirect linking where lookup is a sort of
>> "what's related" understood out of the analysis of user patterns, but
>> this is far ahead in the future.
>>
>> For now, I think direct linking would be enough for our needs... we
>> just need a good "lookup and discovery" of learning objects integrated
>> in the backend.
>>
>> - o -
>>
>> As the implementation
>>
>> 1) forrest will be used to generate the site from the contents of the
>> repository
>>
>> 2) the repository can be either plain vanilla subversion or a webdav
>> server implemented by cocoon on top of another repository (either
>> subversion or catacomb or JSR170). even CVS, but we might want to stay
>> away from it.
>>
>> 3) lenya will be used as the backend.
>>
>> Missing things:
>>
>> 1) is forrest already capable of doing what we ask?
>
> Possibly. Forrest's sitemap is built in layers:
>
> cocoon://**.xml # Source pipelines generating doc-v12
> cocoon://body-*.html
> cocoon://menu-*.html
> cocoon://tabs-*.html # Intermediate formats
> cocoon://**.{html,pdf} # Destination formats
>
> So just switch in a different **.xml subsitemap, and Forrest will build
> the site from whatever backend you choose.
Sounds perfect.
> Forrest's indirect linking system is (IMHO:) pretty cool and Wiki-like,
> in that I can write <a href="site:foo"> from anywhere, and it links to
> the 'foo' page wherever (or whatever) it is. The source files have a
> URI
> space all of their own, independent of the final http: URI space.
Very good as well.
> The linking implementation is very flexible, built in input modules.
> <a
> href="site:index"> causes the 'site' InputModule to be fetched and
> passed
> the 'index' key. A SimpleMappingModule converts this to
> '/site//index/@href', which is fed to an XMLModule, which interprets it
> as an XPath into the navigation file, site.xml. As the XPath prefix
> and
> suffix are configured in cocoon.xconf, any XML format for the 'linkmap'
> (aka site.xml) can be used. Lots of gory details at
> http://xml.apache.org/forrest/linking.html
As you can see from my question, I (and possibly many others here) lost
contact with forrest a while ago: you people simply did the job well
enough for us crawl back in our corner as simple users ;-)
but as you suggest, we might need "soft reuse" at this point, so you'll
hear from us when things don't work (or you are more than welcome to
join, of course).
>> 2) what's the best repository? where do we install it?
>>
>> 3) is lenya enough for what we need? (Michi says so)
>>
>> 4) how much work is the integration of linotype with lenya? (I'll
>> investigate this soon)
>>
>> 5) how do we get the wiki into the repository? (I plan to write a
>> wiki-syntax editing pane for linotype, would this be enough?)
>
> Could use the Chaperon Wiki grammar to convert to XML, but..
> grammar-based validation results in really undecipherable error
> messages.
> Might be best to first use a regular Wiki engine as a 'lexer', to get
> the
> Wiki syntax 'well-formed', and then use a grammar to go from
> well-formed
> Wiki -> XML, and then use an XML schema to ensure validity. 3-phase
> validation of Wiki syntax. Could warrant a project all on its own..
yeah
>> 6) how do we get the rest of the data into the repository?
>>
>> 7) how do we make it simple to edit linkmaps? what searching and
>> proximity tools can we provide for this?
>
> Lenya is probably the best hunting-ground for this.
yep, forrest as the frontend engine, lenya as the backend engine,
cocoon empowering both, documents all safely stored in one repository
(no more CVS branching for docs!!), easy editing, easy workflow,
ability to assemble trails of documentation, no need to bug
infrastructure@ for a dynamic site, mirror friendly...
... gosh, seems like heaven ;-)
--
Stefano.