Re: [Fsedu-developers] semanticWiki code so far

[Stephen Compall]

James Michael DuPont <address@hidden> writes:

> I would like to be compatible with oddmuse. I will look into
> infinite monkey.  A reuable perl class would be good. I think that
> an abstract model is in order here. From that we can generate code
> to implement the model.

The core is the wikilang->xhtml translation.  Around that, we can wrap
the action system (presuming we're going to tear up oddmuse, of
course) as the driver, with the callbacks for I/O in the overrides.  I
could randomly quote words in the last sentence for effect....

> > not really the content pages -- based on cookie data; this can be
> > done with a "custom directory" layout.
> 
> You mean sessions.

Well, they are not really individualized -- except for the people with
permissions to edit the script.  I am also thinking about restricting
modification of the tags, but this is probably just some paranoid
instinct cropping up.

About "edit the script": yes, I would like a PublicScript, or rather
something close to it (submit patches for instant approval &
application), even though it is not really required for the page
design I have in mind.  It's just interesting.

> > The biggest addition is that of a central "tags" database: named
> > tags attached to documents, with or without values.
> 
> Predicates in prolog, properties in rdf.

Why not keep it simple, and just say "<page> <something> true" in RDF?

> > I am painfully (again) learning perl (again).
> 
> If you need any help...

Today I learned references, modules, and classes.  I practiced by
creating a class, though I have not even gotten to inheritence in
perltoot yet.  Yum.

> > Finally, I need to be able to cache the pieces: the header must be
> > regenerated every time the tags db changes, 
> 
> I hope that the changes will go through the business logic application
> server.

Sorry ... business logic?

> > portal pages also need to be regenerated every time the tags
> > change, but content pages only need to be regenerated every time
> > their content or their *own* tags change.
> 
> ok. Dependancies.

The dependency specifics need to be defined by overrides, not in the
documents or tags themselves.  The way I'm thinking, anyway.

> > All of this can be done by designing the backend and frontend classes
> > correctly (give enough override hooks, that is), yet keeping the
> > "normal" Infinite Monkey behavior the same, and preferably adding a
> > tags daemon.
> 
> I dont think we need to make this in perl. We need to make it
> accessable via perl.

What do you mean by "this"?  After all, the only motive I have for
perl at this point is so I don't have to write the whole thing from
scratch -- and keep the current storage format.

--
Stephen Compall or s11 or sirian

The only two things that motivate me and that matter to me are revenge
and guilt.
                -- Elvis Costello

clandestine class struggle quiche Vickie Weaver fissionable Khaddafi
AIMSX 9705 Samford Road smuggle covert video PLO spy bullion Albright
FIPS140