[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fsedu-developers] semanticWiki code so far
From: |
James Michael DuPont |
Subject: |
Re: [Fsedu-developers] semanticWiki code so far |
Date: |
Mon, 3 Nov 2003 11:03:55 +0100 (CET) |
>>>>> "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