Tim Williams wrote:
On 8/8/05, Anil Ramnanan <[EMAIL PROTECTED]> wrote:
Tim Williams wrote
I just went back to the Anil's original proposal and it calls out
Lenya specifically (see below). I went back and looked because I
don't understand what exactly this does. I thought the general
approach for "integrating" backend repositories was the use of
locationmap, thus not so much integrated as "linked to". Is this
"Repository Browser" a way to "browse" the repository then create a
location match based on what is found? I've been a way for a couple
weeks now and am slowly catching up so I apologize if I missed
something. Can someone give me more details of exactly this is to do?
Thanks,
--tim
The "Repository Browser" as I saw it would be a view in the Eclipse
plugin that would allow the user to browse the documents in a particular
repository. The user would then select the document that they are
interested in and drag it to the locationmap where it will create the
appropriate entries for it. The browser should be bale to support the
browsing of multiple repositories.
I suppose it's the selecting *the* "document that they are interested
in and drag it to the locationmap" that's the question. Maybe an
easier question would be is this tied to a real-world use-case?
Please explain that.
(I'll jump in here because this is driven by my own use case, however I
know Anil also has his own, he'll let us know about it if it raises more
issues)
I do voluntary work for a charity (http://www.cawd.net). This charity
does work in a rural village in Nigeria, they have installed a computer,
satellite link and generator (they don't even have piped water, but they
have an Internet connection!).
They use the CMS to generate content of use to their community, to the
charity as a whole, and to the wider Nigerian communities. There is a
whole load of information that is relevant to different groups.
Because the Internet is so expensive (running a generator and paying for
bandwidth is expensive to people who live on less than one US$ a week)
we need to provide offline access to the content. Enter Forrest.
Now there are around 2000 pages of information in this CMS at present.
Some of of no interest to farmers, some are of no interest to school
teachers, some are of no interest to nurses etc. We don't want to go and
dump all 2000 pages on these (generally computer illiterate users) and
expect them to find what they want. Instead we want to create custom
publications for them that contain only the information they are
interested in.
So, we need an interface for our partially trained computer operator in
the village to use to create these publications for other Nigerian villages.
I just dont' currently get the benefit over just
a locationmap editor.
It's a GUI to the locationamp editor - (some) users need GUI's.
I guess I view folks using respositories for
all (e.g. **.xml) or at least a subset (*/sports/**.xml) of their
content rather than just cherry-picking (e.g.
/sports/august/08/story1.xml) one or two documents from different
locations.
You are assuming that the content in the source CMS is well ordered and
that there is no overlap between sections. For the first point, even in
the most strictly controlled CMS with the most rigid of processes in
place you will still find someone mis filing something. For the second
point materials on how to treat a sprained ankle are relevant to the
sports groups as well as the nurses, but how to treat a broken leg
requires different content for each group, yet it is likely the content
will be located in the same section of the repository.
My vision (possibly out of the scope of GSoC) is to have an intelligent
match generator. So the first time you drop a document it creates a one
to one match. Next time you drop one it creates a wild card match and
removes the original. When you drop in an excpetion to the rule it spots
it and places a one to one match in the right location.
Of course one should be able to drag and drop a folder too.
Here is a rough outline of how it should work.
Repository View
|
Repository Interface
|
-------------------
| | |
Lenya Daisy Slide
The Repository View is the actual View in Eclipse which shows the
documents available in that repository. This is where the user can
select the document to be included in the locationmap.
There's *the* document again. When I'm interested in integrating a
backend to Forrest I'm looking at, for example, all xml. Maybe all
xml (**.xml) getting matched from Slide/Xindice/Berkeley DB XML for
example. For this, if you're giving me a locationmap editor already,
how does the Repository View help?
It's a GUI to the locationamp editor - (some) users need GUI's. Using
this GUi the user need not understand how to compose the matchers.
Ross
