Development/Tutorials/Metadata/Nepomuk/ChatLogger

Development/Tutorials/Metadata/Nepomuk/ResourceGenerator

Languages: عربي | Asturianu | Català | Česky | Kaszëbsczi | Dansk | Deutsch | English | Esperanto | Español | Eesti | فارسی | Suomi | Français | Galego | Italiano | 日本語 | 한국어 | Norwegian | Polski | Português Brasileiro | Română | Русский | Svenska | Slovenčina | Slovenščina | српски | Türkçe | Tiếng Việt | Українська | 简体中文 | 繁體中文

Creating a ChatLogger using Nepomuk

Tutorial Series	Nepomuk
Previous
What's Next
Further Reading

Rough Basics

In Nepomuk, ontologies are very important. For a semi-decent analogy - An ontology is like a class specification. You get to define exactly which properties, sub-classes and super-classes a class has. Every object of that class, in Nepomuk terms, is called a Resource.

In the linked data world, properties are also a special kind of class. Unlike conventional programming languages where a property is limited to that class and its descendants. In linked data, each property has a domain and range, indicating which classes it can be mapped to. Properties can also be derived from to have sub-properties.

Use Case

The first thing one generally does when storing some information in a database is to decide what data should be stored. In the case of a chat logger, what we need is -

• From
• To
• Time stamp
• Message Content
• Status of the message

Additionally, we would require the database to be persistent and query-able. Nepomuk provides that.

Finding the correct Ontology

The first thing one generally needs to know when working on some Nepomuk related project, is how is the data going to be stored? To be specific - which ontology would be required?

Ontologies already exist for common use cases like Email, Messaging, Notes, etc. In the case of a chat logging system we would want to take a look at NMO - The Nepomuk Messaging Ontology. ( Add a link )

The easiest way to know the exact contents of the ontology is to read its trig file - Link. On inspection we realize that there exists several classes -

        nmo:Message
        /      \ 
       /        \
 nmo:Email   nmo:IMMessage

Here nmo:IMMessage is a sub class of nmo:Message. On further inspection of the properties of nmo:Message, we notice it has properties like nmo:messageTo, nmo:messageFrom, nmo:isRead, nmo:receivedDate, and nmo:plainTextMessageContent

These properties depict exactly what we need in the case of the chat logger. So we know exactly how we're going to store the data.

Implementation

Getting Started

Link the basic Nepomuk testing Template and explain parts of it

Creating a Resource

In Nepomuk everything is stored as a Resource.

Nepomuk::Resource

The most common way to create or manipulate a resource is using the Nepomuk::Resource class.

Show code

The next step would obviously be of adding the required properties

more code

If we look at the ontology specification - The nmo:toMessage property has a nco:Contact in it's range

   < exact line >

So we need to creates a separate Resource for each Contact. Suppose Bob and Mary are chatting.

Bob: Hi! Mary: Good Evening Bob.

Here we would need 2 resources of the type nco:Contact and 2 resources of type nmo:IMMessage ie one for each message.

< code to create a Contact >

< add contact info >

The Resource Generator

In our case ( chat logger ) we know exactly what kind of resources we want - nmo:IMMessage. So it would be a lot easier for us to generate C++ classes for them, so we don't have to use the cumbersome addProperty( uri, value ) method.

Show the CMake Code

Show the same code but using the Resource Generator

Checking if the data exists

After compiling and running our short program - We would want to check if the data actually exists in the Nepomuk Repository. The simplest way to do that would be using a sparql query

select ?r ?p ?o where { ?r a nmo:IMMessage . ?r ?p ?o. }

The query can be executed using either 'nepomukcmd' or by executing it in the nepomukshell.