Difference between revisions of "Programming project"
Jump to navigation
Jump to search
m (→data storage) |
m (→data storage) |
||
Line 36: | Line 36: | ||
* [[server-storage interface]] | * [[server-storage interface]] | ||
* [[storage authentication]] | * [[storage authentication]] | ||
− | |||
---- | ---- | ||
Revision as of 18:09, 13 September 2011
The software shall run on GNU/Linux systems having a broadband connection to the internet.
Contents
Preparation
- write down the concept in this wiki (IN PROGRESS)
- write very simple, elementary prototypes of client, server and storage (IN PROGRESS)
- search for other developers (IN PROGRESS)
- make a list of skills needed for this project (TODO)
- create communication and development infrastructure (TODO)
- learn from existing ontology editors (DONE)
Architecture / Specification
Overview
Essentially we have a 3-tier architecture:
- A storage backend consisting of one database (beginning with the single database backend project), or a network of of appropriately synchronized distributed database nodes (later).
- Server nodes access the data on storage nodes through a fixed interface (server-storage interface). We envisage having both one server node and one storage node on the same machine, since this might be necessary for performance reasons.
- Clients access the server nodes through a fixed interface (client-server interface). A client may consist of a webserver being accessed by a webbrowser, or a commandline client, or other clients. (The webserver may also allow for providing public resources, such as html tables to be included into websites.)
- Users can choose their preferred interface.
data storage
Currently the storage is being implemented as a single database backend.
Only later we will switch the storage (everything behind the fixed server-storage interface) to a distributed network of storage nodes.
How are data stored?
- knowledge representation model
- data model
- database
- distributed storage
- server-storage interface
- storage authentication
object logics
The tasks of the server include:
- communication with clients via client-server interface
- access verification (identification, authentication, access rights)
- k-object editing and input validation
- group logics, spatial and temporal logics
- k-class hierarchy logics
- topic hierarchy logics
- communication with storage layer via server-storage interface
- data retrieval with 'intelligent' caching (e.g. of query results)
- handling of storage data change events for data in use by a client
- inter-server trust network
- user messaging and other communication functions
- object clipboard functions
- user preferences management
client access
For now we envisage two clients:
- a minimalist command line client with text console
- a full featured AJAX webapplication client with graphical interface having these featues
- search and edit k-classes, k-instances and k-relations
- user customizable
- 3 different complexity levels (simple, medium, advanced)
- virtual connection through periodic polling
Other clients (in particular for mobile devices) are possible later.