Projects/Nepomuk/ComponentOverview - Revision history

AnneW: Marked this version for translation

2012-12-13T16:07:26Z

Marked this version for translation

AnneW: Prepare for translation

2012-12-13T16:07:12Z

Prepare for translation

Vishesh: /* Nepomuk Components */ Added image

2012-08-24T11:25:42Z

‎Nepomuk Components: Added image

Vishesh: /* Ontologies */

2012-08-24T07:15:10Z

‎Ontologies

Vishesh: /* Nepomuk File Indexing Service */

2012-08-24T07:14:14Z

‎Nepomuk File Indexing Service

Vishesh: /* Nepomuk File Watch Service */

2012-08-24T07:13:25Z

‎Nepomuk File Watch Service

Vishesh: /* Nepomuk Storage Service */

2012-08-24T07:12:38Z

‎Nepomuk Storage Service

Vishesh: /* Nepomuk Storage Service */

2012-08-24T07:09:35Z

‎Nepomuk Storage Service

Vishesh: /* Nepomuk Service Stub */

2012-08-24T07:07:05Z

‎Nepomuk Service Stub

Vishesh: /* Soprano */ Typos

2012-08-08T12:56:17Z

‎Soprano: Typos

@@ Line 2: / Line 2: @@
 <translate>
-== Introducing Technical Terms ==
+== Introducing Technical Terms == <!--T:1-->
 The '''Nepomuk''' world uses some jargon which may be slightly intimidating to new comers. This page attempts to list down the commonly used '''Nepomuk''' development terms, and what they mean.
-=== Nepomuk ===
+=== Nepomuk === <!--T:3-->
 '''Nepomuk''' is actually an abbreviation for a very long and obtuse name. That however, does not really matter.
 '''Nepomuk''' is the underlying semantic technology that is used by KDE. It provides an API for software developers, and provides all the glue to index all of the file metadata. Whenever anyone is talking about using "semantic" technologies in KDE, they generally mean '''Nepomuk'''.
 It is the top-most component of the entire ''Semantic Stack''.
-=== Soprano ===
+=== Soprano === <!--T:7-->
 Soprano is a Qt abstraction over databases. It provides a friendly Qt-based API for accessing different RDF stores. It currently supports 3 database backends - Sesame, Redland and Virtuoso. The KDE Semantic Stack only works with Virtuoso. Soprano also provides additional features such as serializing, parsing rdf data, and a client server architecture that is heavily used in '''Nepomuk'''.
-=== Virtuoso ===
+=== Virtuoso === <!--T:9-->
 '''Virtuoso''' is the only supported RDF database in KDE. It's a very powerful database that powers massive projects such as dbpedia. It is currently controlled by OpenLink, and is available under commercial and an open source license.
 Internally, virtuoso may be looked at as a relational database, with some added RDF features.
-=== Strigi ===
+=== Strigi === <!--T:12-->
 The Strigi project is divided into 5 sub-projects, and can be used for a full file indexing framework. However, KDE only uses some parts of it. '''Nepomuk'''  uses the libstreams and libstream analyzer to pass it the filecontents. In returns it gives metadata about the file, which '''Nepomuk''' reads and then pushes into virtuoso.
-== Nepomuk Components ==
+== Nepomuk Components == <!--T:14-->
 [[File:NepomukSimpleArchitecture.png]]
 '''Nepomuk''' has been split into a number of components for stability reasons. Many of these components communicate with each other, using a combination of dbus and local sockets.
-=== Nepomuk Server ===
+=== Nepomuk Server === <!--T:17-->
 The Nepomuk server is the central process that is responsible for spawning and controlling all other nepomuk processes. In reality it is not a server since none the Nepomuk components actual connect to it, or try to communicate with it.
 On starting up, it checks if Nepomuk is enabled, and accordingly, either kills itself, or starts spawning the other nepomuk processes. All other nepomuk processes go by the name of 'nepomukservicestub'.
-=== Nepomuk Service Stub ===
+=== Nepomuk Service Stub === <!--T:20-->
 The <tt>nepomukservicestub</tt> is a generic process that is used to run any of the Nepomuk services. It reads the nepomuk service name as an argument, and loads the plugin for that service.
 <syntaxhighlight lang="bash">
 $ nepomukservicestub "nepomukfileindexer"
@@ Line 49: / Line 63: @@
 </syntaxhighlight>
-=== Nepomuk Storage Service ===
+=== Nepomuk Storage Service === <!--T:23-->
 The Storage Service is the central nepomuk service, on which all other services depend. This service is responsible for launching virtuoso, monitoring the ontologies. Recently the Nepomuk Query Service was merged into the storage service for performance reasons. So, now the storage service is also responsible for running queries.
 The Storage service also acts as a hard dependency for all other services. These services communicate with the storage service either via dbus or via a local socket.
 '''Relevant Code:''' nepomuk-core/services/storage
-=== Nepomuk File Watch Service ===
+=== Nepomuk File Watch Service === <!--T:27-->
 The File Watch service is responsible for hooking up to the kernel and listening for file move, deletion, and creation events. On receiving any of these events, it updates the metadata present in virtuoso. It is also responsible for calling the file indexer service to index new files.
 '''Relevant Code:''' nepomuk-core/services/filewatch/
-=== Nepomuk File Indexing Service ===
+=== Nepomuk File Indexing Service === <!--T:30-->
 The File Indexing service is responsible for indexing all the files. It relies on a helper process called <tt>nepomukindexer</tt> which actually performs the indexing and pushing to '''Nepomuk'''. This service merely schedules the indexing, and decides which files should be indexed.
 '''Relevant Code:''' nepomuk-core/services/fileindexer
-=== Ontologies ===
+=== Ontologies === <!--T:33-->
 Relational databases have database schemas which are fixed. RDF databases instead use ontologies which are less static. They define how the data should be stored in the database. The ontologies are provided by Shared Desktop Ontologies package, that is also maintained by the Nepomuk developers.
 [[Category:Documentation]]
 [[Category:Development]]
 [[Category:Tutorials]]
 </translate>

@@ Line 1: / Line 1: @@
-= Technical Terms =
+<languages />
-The Nepomuk world uses some jargon which may be slightly intimidating to new comers. This page attempts to list down the commonly used Nepomuk development terms, and what they mean.
+== Introducing Technical Terms ==
-== Nepomuk ==
+The '''Nepomuk''' world uses some jargon which may be slightly intimidating to new comers. This page attempts to list down the commonly used '''Nepomuk''' development terms, and what they mean.
-Nepomuk is actually an abbreviation for a very long and obtuse name. That however, does not really matter.
+=== Nepomuk ===
-Nepomuk is the underlying semantic technology that is used by KDE. It provides an API for software developers, and provides all the glue to index all of the file metadata. Whenever anyone is talking about using "semantic" technologies in KDE, they generally mean Nepomuk.
+'''Nepomuk''' is actually an abbreviation for a very long and obtuse name. That however, does not really matter.
-It is the top most component of the entire Semantic Stack.
+'''Nepomuk''' is the underlying semantic technology that is used by KDE. It provides an API for software developers, and provides all the glue to index all of the file metadata. Whenever anyone is talking about using "semantic" technologies in KDE, they generally mean '''Nepomuk'''.
-== Soprano ==
+It is the top-most component of the entire ''Semantic Stack''.
-Soprano is a Qt abstraction over databases. It provides a friendly Qt-based API for accessing different RDF stores. It currently supports 3 database backends - Sesame, Redland and Virtuoso. The KDE Semantic Stack only works with Virtuoso. Soprano also provides additional features such as serializing, parsing rdf data, and a client server architecture that is heavily used in Nepomuk.
+=== Soprano ===
-== Virtuoso ==
+Soprano is a Qt abstraction over databases. It provides a friendly Qt-based API for accessing different RDF stores. It currently supports 3 database backends - Sesame, Redland and Virtuoso. The KDE Semantic Stack only works with Virtuoso. Soprano also provides additional features such as serializing, parsing rdf data, and a client server architecture that is heavily used in '''Nepomuk'''.
-Virtuoso is the only supported RDF database in KDE. It's a very powerful database that powers massive projects such as dbpedia. It is currently controlled by OpenLink, and is available under commercial and an open source license.
+=== Virtuoso ===
 Internally, virtuoso may be looked at as a relational database, with some added RDF features.
-== Strigi ==
+=== Strigi ===
-The Strigi project is divided into 5 sub-projects, and can be used for a full file indexing framework. However, KDE only uses some parts of it. Nepomuk  uses the libstreams and libstream analyzer to pass it the filecontents. In returns it gives metadata about the file, which Nepomuk reads and then pushes into virtuoso.
+The Strigi project is divided into 5 sub-projects, and can be used for a full file indexing framework. However, KDE only uses some parts of it. '''Nepomuk'''  uses the libstreams and libstream analyzer to pass it the filecontents. In returns it gives metadata about the file, which '''Nepomuk''' reads and then pushes into virtuoso.
-= Nepomuk Components =
+== Nepomuk Components ==
 [[File:NepomukSimpleArchitecture.png]]
-Nepomuk has been split into a number of component for stability reasons. Many of these components communicate with each other, using a combination of dbus and local sockets.
+'''Nepomuk''' has been split into a number of components for stability reasons. Many of these components communicate with each other, using a combination of dbus and local sockets.
-== Nepomuk Server ==
+=== Nepomuk Server ===
 The Nepomuk server is the central process that is responsible for spawning and controlling all other nepomuk processes. In reality it is not a server since none the Nepomuk components actual connect to it, or try to communicate with it.
@@ Line 37: / Line 40: @@
 On starting up, it checks if Nepomuk is enabled, and accordingly, either kills itself, or starts spawning the other nepomuk processes. All other nepomuk processes go by the name of 'nepomukservicestub'.
-== Nepomuk Service Stub ==
+=== Nepomuk Service Stub ===
-The <code>nepomukservicestub</code> is a generic process that is used to run any of the Nepomuk services. It reads the nepomuk service name as an argument, and loads the plugin for that service.
+The <tt>nepomukservicestub</tt> is a generic process that is used to run any of the Nepomuk services. It reads the nepomuk service name as an argument, and loads the plugin for that service.
 <syntaxhighlight lang="bash">
@@ Line 46: / Line 49: @@
 </syntaxhighlight>
-== Nepomuk Storage Service ==
+=== Nepomuk Storage Service ===
 The Storage Service is the central nepomuk service, on which all other services depend. This service is responsible for launching virtuoso, monitoring the ontologies. Recently the Nepomuk Query Service was merged into the storage service for performance reasons. So, now the storage service is also responsible for running queries.
@@ Line 54: / Line 57: @@
 '''Relevant Code:''' nepomuk-core/services/storage
-== Nepomuk File Watch Service ==
+=== Nepomuk File Watch Service ===
 The File Watch service is responsible for hooking up to the kernel and listening for file move, deletion, and creation events. On receiving any of these events, it updates the metadata present in virtuoso. It is also responsible for calling the file indexer service to index new files.
@@ Line 60: / Line 63: @@
 '''Relevant Code:''' nepomuk-core/services/filewatch/
-== Nepomuk File Indexing Service ==
+=== Nepomuk File Indexing Service ===
-The File Indexing service is responsible for indexing all the files. It relies on a helper process called <code>nepomukindexer</code> which actually performs the indexing and pushing to Nepomuk. This service merely schedules the indexing, and decides which files should be indexed.
+The File Indexing service is responsible for indexing all the files. It relies on a helper process called <tt>nepomukindexer</tt> which actually performs the indexing and pushing to '''Nepomuk'''. This service merely schedules the indexing, and decides which files should be indexed.
 '''Relevant Code:''' nepomuk-core/services/fileindexer
-== Ontologies ==
+=== Ontologies ===
 Relational databases have database schemas which are fixed. RDF databases instead use ontologies which are less static. They define how the data should be stored in the database. The ontologies are provided by Shared Desktop Ontologies package, that is also maintained by the Nepomuk developers.

← Older revision		Revision as of 11:25, 24 August 2012
Line 26:		Line 26:

	= Nepomuk Components =		= Nepomuk Components =
		+
		+	[[File:NepomukSimpleArchitecture.png]]

	Nepomuk has been split into a number of component for stability reasons. Many of these components communicate with each other, using a combination of dbus and local sockets.		Nepomuk has been split into a number of component for stability reasons. Many of these components communicate with each other, using a combination of dbus and local sockets.

← Older revision		Revision as of 07:15, 24 August 2012
Line 66:		Line 66:
	== Ontologies ==		== Ontologies ==

−	Relational databases have database schemas which are fixed. RDF databases instead use ontologies which are less static. They define how the data should be stored in the database.	+	Relational databases have database schemas which are fixed. RDF databases instead use ontologies which are less static. They define how the data should be stored in the database. The ontologies are provided by Shared Desktop Ontologies package, that is also maintained by the Nepomuk developers.

@@ Line 60: / Line 60: @@
 == Nepomuk File Indexing Service ==
-The File Indexing service is responsible for indexing all the files. It relies on a helper process called 'nepomukindexer' which actually performs the indexing and pushing to Nepomuk. This service merely schedules and the indexing, and decides which files should be indexed.
+The File Indexing service is responsible for indexing all the files. It relies on a helper process called <code>nepomukindexer</code> which actually performs the indexing and pushing to Nepomuk. This service merely schedules the indexing, and decides which files should be indexed.
 == Ontologies ==
 Relational databases have database schemas which are fixed. RDF databases instead use ontologies which are less static. They define how the data should be stored in the database.

← Older revision		Revision as of 07:13, 24 August 2012
Line 55:		Line 55:

	The File Watch service is responsible for hooking up to the kernel and listening for file move, deletion, and creation events. On receiving any of these events, it updates the metadata present in virtuoso. It is also responsible for calling the file indexer service to index new files.		The File Watch service is responsible for hooking up to the kernel and listening for file move, deletion, and creation events. On receiving any of these events, it updates the metadata present in virtuoso. It is also responsible for calling the file indexer service to index new files.
		+
		+	'''Relevant Code:''' nepomuk-core/services/filewatch/

	== Nepomuk File Indexing Service ==		== Nepomuk File Indexing Service ==

@@ Line 46: / Line 46: @@
 == Nepomuk Storage Service ==
-The Storage Service is the central nepomuk service, on which all other services depend. This service is responsible for launching virtuoso, monitoring the ontologies, and answering queries.
+The Storage Service is the central nepomuk service, on which all other services depend. This service is responsible for launching virtuoso, monitoring the ontologies. Recently the Nepomuk Query Service was merged into the storage service for performance reasons. So, now the storage service is also responsible for running queries.
-All the other services communicate with the storage service, either via dbus or via a local socket.
+The Storage service acts as a hard dependency for all other services. These services communicate with the storage service either via dbus or via a local socket.
 == Nepomuk File Watch Service ==