---------- Forwarded message ----------
From: Nagarjuna G <nagarjun@gnow...>
Date: Fri, Mar 19, 2010 at 8:00 AM
Subject: Release Candidate of GNOWSYS and gnowsys-mode
Gnowledge lab team is happy to announce the release of GNOWSYS and
This is the first major release of GNOWSYS and gnowsys-mode (An Emacs
major mode as an UI for GNOWSYS) as a release candidate 1. If no more
bugs are reported/fixed in the coming two months, v 1.0 will be
released in May 2010.
This release is a major overhaul of the last stable release 0.62 (June
2006). After this GNOWSYS has been completely rewritten. The major
changes are summarized below:
+ The storage uses postgresql and not ZOPE object database (ZODB).
+ Full version control of data and metadata is implemented making it
a multiuser collaboration through the web, as well as through an
Emacs client. (A major mode of GNU Emacs called gnowsys-mode has
been developed as a client to work collaboratively through
Internet without using an Internet browser.)
+ It is scalable and faster than all the earlier versions.
+ It is standardized for use as a triple (RDF) store. (In the next
release Ontologies can be published and managed collaboratively.)
+ Graphs are drawn automatically for each node in SVG with
+ RDF export in N3 notation is implemented.
+ Basic ontology editing is possible through the Emacs client:
* A brief Introduction about GNOWSYS
GNOWSYS (Gnowledge Networking and Organizing System) is a triple
store (RDF) for representing knowledge networks and its dynamics.
** The Structure of the Network Memory
The network construction uses the following principles:
1. The memory in GNOWSYS is a set of nodes with all nodes with a
unique NID (Node ID). The NID with the address locator gives
rise to a unique URI in the cyberspace.
2. Every node links with the neighborhood nodes through two kinds
of mediating nodes: attributes and relations. Thus every node
can be represented as a frame.
3. Every node is described by neighborhood.
4. The network can be obtained as a graph by merging the
neighborhood of all the nodes.
5. The set of all attributes and relations is the full set of
knowledge represented in the network.
6. Each attribute or relation constitutes one RDF triple.
7. Search and query operations give the list of SSID (SnapShot ID)
whose neighborhood contains the searched value.
8. The value space is linked to the nodes via named links making
most results of queries meaningful.
9. The representation of network memory can be completely encoded
in any of the RDF languages.
** The Dynamics (change management) of the Network Memory
1. Insertion of new nodes changes the neighborhood of the nodes
concerned, and such changes can be tracked by holding the
snapshots of the node's neighborhood at each instance of change.
2. Being a collaborative space, the system records who did what
change and at what time.
3. Delinking is the preferred way of removing data elements from
the network, and no node can be removed without prior removal of
the links the node may have with others.
4. Each Node's neighborhood at a given time becomes the state space
of the node.
5. Changing state of nodes can be recorded persistently as process
nodes that record the prior-state and post-state of the nodes