Development/Tutorials/Metadata/Nepomuk/ChatLogger

< Development‎ | Tutorials‎ | Metadata/Nepomuk
Revision as of 14:27, 8 February 2011 by VHanda (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Contents

Development/Tutorials/Metadata/Nepomuk/ResourceGenerator


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

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

In a simple chat logging system we would typically need to store who the message was from, to, its content, status ( read or unread ) and exact date and time as to when it was received.

This is perfect! 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.


KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal