Re: [Fsedu-developers] semanticWiki code so far

[James Michael DuPont]

>>>>> "S11" == Stephen Compall <address@hidden> writes:

    >>>> "Mike" = James Michael DuPont <address@hidden> writes:
    Mike> I would like to be compatible with oddmuse. I will look into
    Mike> infinite monkey.  A reuable perl class would be good. I think
    Mike> that an abstract model is in order here. From that we can
    Mike> generate code to implement the model.

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

    Well, my idea is now of an application server. The application
    server provides an abstract model that is served to the display
    engine. The application server handles the database storage,
    referencial integrety. It can store the data in rdf, or in
    postgres. It is able to reject changes that are invalid. It
    handles security of the transation and authentication of the
    clients. The application server should be accessable from perl
    with very little pain. It does not have to be written in core in
    perl. I am looking into GNUE and what that can handle right now. 

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

    S11> Well, they are not really individualized -- except for the
    S11> people with permissions to edit the script.  

    But a good server will track the pages most visited by users. They
    will allow a customized viewpoint. 

    S11> I am also
    S11> thinking about restricting modification of the tags, but this
    S11> is probably just some paranoid instinct cropping up.

    Well in terms of tags, you should be able to import taglibs
    (ontologies in rdf) into the server. I think that authenication
    and rights management is a application server issue. We need a
    central way to handle this.

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

    Well the application server will be able to import new models
    online without being rebooted.

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

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

    Sure, you can attach attributes to a tag.

    I think you will have a structure like this :

    Classes : 
    Page 
    Paragraph
    Sentence
    Term
    
    Relationships : 
    Term -> Page
    Page -< Paragraph -< Sentence -< Term
    Term >-Synonym(and other wordnet relationships)-< Term

    Attributes :
    Format of the Text
    
    That is for the wiki specific structure. The wikipages could be
    converted to rdf that handles that. 

    Basically that will allow you to create pargraph objects, and put
    the sentences in them, (in order) and the put terms and words into
    them (in order). Each word could be a first level rdf object that
    would allow a wordnet connection. 
 

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

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

    Well If you want to start by extracting the Page into a class and
    making that standalone....

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

    S11> Sorry ... business logic?

    Business logic : Rights of users, Precedence of updates,
    Restrictions of the data.

    >> > 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.
    >> 
    Mike> ok. Dependancies.

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

    Ok, so you want to be able to define like a makefile of updates.

    >> > 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.
    >> 
    Mike> I dont think we need to make this in perl. We need to make it
    Mike> accessable via perl.

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

    This is the application server.

mike