> I'm not totally clear on how this works though. It looks like this system
> allows for arbitrary nesting, but the maximum nesting level must be
> pre-defined. Also, it looks like it could be fairly hard to add nesting
> levels after there is already data in the FAQ system. I also see the
> potential both for required maximal nesting (i.e. *every* question must be
> at the same depth), and for flexible topic/question specific nesting
> levels (i.e. you could have some questions 3 levels deep, others 4, and
> maybe even a few 1 level deep).
Yes, once you define your semantic levels, modifying them is a bit hard.
But not too hard. It would be single update statement that changes
the parentID. Note that once a parentID changes, all of it's children
need the depth recalculated. A perfect use of a trigger. In general
you shouldn't be modifying the topology.
There is no contraint. Every question that is a parent of a Topic
must be at the same depth, but you can have another level that serves
the same semantic meaning of what a question is.
You CAN't do the following:
Stuff
--> TO DO Lists
--> Item
--> status
---> FAQ's
--> question
--> answer
---> HOW To's
--> topics
---> question
--> answer
and then do a select for all data segments at depth = 3 and expect them to
have the same semantic meaning. However, you could say all data segments
at depth = 3 AND parentID = x.
That's why I propose that we separate different semantic lists into
different databases. You don't have to. But we should decide up front
what we suggest the clients to do.
>
> The only real drawback I see to this scheme is it makes it harder to give
> names to the various nesting levels. That is, you can't really say,
> "level 2 is FAQs, level 3 is topics, and level 4 is questions," because
> there might be questions in level 2 also. Or in some cases, there may be
> nothing but questions in level 3, making the level 2 parent more
> topic-like than faq-like.
This is a way to organize data. You need a static definition
of how you organize data so that people can retrieve it systematically.
>
> All that said, I don't know exactly what sort of database schema would be
> needed to implement it. The table you suggested would probably work well,
> except I would probably eliminate the "depth" field, and add some sort of
> "type" field, or question/folder toggle, or something. Alternatively, you
> could make a whole other table for questions, but that would require
> making 2 selects to generate the question/folder list at any given level.
You could tag each dataSegment with a type, but doing raw selects (i.e.
from the command line of the given dbase), can be painful and tricky. Plus
it's redundant information.
Basically, by knowing the symntic structure of your hierarchy, you know
what things are based on their depth (and parentID if you combine multiple
oraganizational schemes in the same database).
The good news is that I implemented a similar system (called WORMS) with
swing with success. But the web side got painful
(but now I'm taking Turbine every day!), so we scraped the project.
>
> This sounds a lot like something that might be better off addressed by
> running two instances of Jyve/Turbine, rather than internally within
> Jyve? What do other people think?
I would think that if you have two different administrative groups, then
running two/multiple instances of Turbine is the right way to go. But if
I have 5 dbases (FAQ;s, To Dos, project lists, etc). Is it overkill to
have to set up that many different zones ?
>
>
> One last thing... There have been a couple questions on this list in the
> past about restricting access to certain projects/faqs. What do you all
> think of adding an (optional) access control list to each element within
> the Jyve system (both projects/faqs/topics/whatever replaces those, and
> questions)? I think role-level granularity, rather than visitor-level, is
> probably sufficient. Thoughts?
I need to think on this.
think. think. think.
thanks for the good feedback.
mike
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
