• Skip to content
  • Skip to link menu
KDE API Reference
  • KDE API Reference
  • kdelibs API Reference
  • KDE Home
  • Contact Us
 

Nepomuk-Core

Classes
Nepomuk Data Management

Classes

class  Nepomuk2::ResourceWatcher
 

Basic Data Managment API

enum  Nepomuk2::RemovalFlag { Nepomuk2::NoRemovalFlags = 0, Nepomuk2::RemoveSubResoures = 1 }
 
KJob * Nepomuk2::addProperty (const QList< QUrl > &resources, const QUrl &property, const QVariantList &values, const KComponentData &component=KGlobal::mainComponent())
 
KJob * Nepomuk2::setProperty (const QList< QUrl > &resources, const QUrl &property, const QVariantList &values, const KComponentData &component=KGlobal::mainComponent())
 
KJob * Nepomuk2::removeProperty (const QList< QUrl > &resources, const QUrl &property, const QVariantList &values, const KComponentData &component=KGlobal::mainComponent())
 
KJob * Nepomuk2::removeProperties (const QList< QUrl > &resources, const QList< QUrl > &properties, const KComponentData &component=KGlobal::mainComponent())
 
CreateResourceJob * Nepomuk2::createResource (const QList< QUrl > &types, const QString &label, const QString &description, const KComponentData &component=KGlobal::mainComponent())
 
KJob * Nepomuk2::removeResources (const QList< QUrl > &resources, Nepomuk2::RemovalFlags flags=Nepomuk2::NoRemovalFlags, const KComponentData &component=KGlobal::mainComponent())
 

Advanced Data Managment API

enum  Nepomuk2::StoreIdentificationMode { Nepomuk2::IdentifyNew = 0, Nepomuk2::IdentifyNone = 2 }
 
enum  Nepomuk2::StoreResourcesFlag {
  Nepomuk2::NoStoreResourcesFlags = 0x0, Nepomuk2::OverwriteProperties = 0x1, Nepomuk2::LazyCardinalities = 0x2, Nepomuk2::OverwriteAllProperties = 0x4,
  Nepomuk2::MergeDuplicateResources = 0x8
}
 
enum  Nepomuk2::DescribeResourcesFlag { Nepomuk2::NoDescribeResourcesFlags = 0, Nepomuk2::ExcludeDiscardableData = 1, Nepomuk2::ExcludeRelatedResources = 2, Nepomuk2::AnonymizeNepomukUris = 4 }
 
KJob * Nepomuk2::removeDataByApplication (const QList< QUrl > &resources, Nepomuk2::RemovalFlags flags=Nepomuk2::NoRemovalFlags, const KComponentData &component=KGlobal::mainComponent())
 
KJob * Nepomuk2::removeDataByApplication (Nepomuk2::RemovalFlags flags=Nepomuk2::NoRemovalFlags, const KComponentData &component=KGlobal::mainComponent())
 
KJob * Nepomuk2::mergeResources (const QUrl &resource1, const QUrl &resource2, const KComponentData &component=KGlobal::mainComponent())
 
KJob * Nepomuk2::mergeResources (const QList< QUrl > &resources, const KComponentData &component=KGlobal::mainComponent())
 
StoreResourcesJob * Nepomuk2::storeResources (const Nepomuk2::SimpleResourceGraph &resources, Nepomuk2::StoreIdentificationMode identificationMode=Nepomuk2::IdentifyNew, Nepomuk2::StoreResourcesFlags flags=Nepomuk2::NoStoreResourcesFlags, const QHash< QUrl, QVariant > &additionalMetadata=QHash< QUrl, QVariant >(), const KComponentData &component=KGlobal::mainComponent())
 
KJob * Nepomuk2::importResources (const KUrl &url, Soprano::RdfSerialization serialization, const QString &userSerialization=QString(), StoreIdentificationMode identificationMode=IdentifyNew, StoreResourcesFlags flags=NoStoreResourcesFlags, const QHash< QUrl, QVariant > &additionalMetadata=QHash< QUrl, QVariant >(), const KComponentData &component=KGlobal::mainComponent())
 
DescribeResourcesJob * Nepomuk2::describeResources (const QList< QUrl > &resources, DescribeResourcesFlags flags=NoDescribeResourcesFlags, const QList< QUrl > &targetParties=QList< QUrl >())
 

Detailed Description

The basic Nepomuk data manipulation interface.

The Data Management API is the basic interface to manipulate data in Nepomuk. It provides methods to add, remove, change properties, add and remove resources, merge resources, integrate blobs of information, and retrieve resources according to certain criteria.

The data management API can be split into two groups: the basic and the advanced API. The basic API allows to modify properties and resources in a very straight-forward manner: add or set a property value, remove property values or whole properties, and so on. The advanced API on the other hand deals with more complicated situations mostly based on the fact that Nepomuk always remembers which application did what. Each of the methods has a parameter which states the calling component. This allows clients to for example only remove information that it actually created, making updates very easy.

Resource URIs

Most methods take a single or a list of resource URIs. Normally all resources in Nepomuk have a unique URI of the form nepomuk:/res/UUID where UUID is a randomly generated universal identifer. However, the data management service methods can handle a bit more than that. Any local file URL can be used where a resource URI is required. It will automatically be converted to the appropriate resource URI. The same is true for any URL with a protocol supported by KIO. These URLs will not be used as resource URIs but as values of the nie:url property.

Thus, when setting a property on a local file URL like file:///home/user/file.txt the property will actually be set on the resource corresponding to the local file. This resources has a resource URI of the form detailed above. Its nie:url property, however, will be set to file:///home/user/file.txt.

In addition to the above URL conversion local file paths are also supported. They will be converted to local file URLs and then treated the same way as explained above.

In general one should never create resource URIs manually. Instead use createResource() or storeResources() with an empty URI in the SimpleResource. The only exception are resources that have counterparts with URLs on the desktop like local files or web pages or the like.

Sub-Resources

Nepomuk has the concept of sub-resources. The basic idea of a sub-resource is that while it is a resource in itself, it does not make sense without its parent resource. The typical example would be contact details:

<nepomuk:/res/A> a nco:Contact ;
nco:fullname "Nepomuk Nasenbär" ;
nco:hasPostalAddress <nepomuk:/res/B> ;
nao:hasSubResource <nepomuk:/res/B> .
<nepomuk:/res/B> a nco:PostalAddress ;
nco:streetAddress "Nepomuk street 1" ;
[...] .

While in theory a nco:PostalAddress resource could live on its own it does not make much sense without the contact. Thus, it is marked as being the sub-resource of the nco:Contact.

Less obvious examples are contacts that are just created for indexing email senders or for indexing music files. These are contacts the user most likely does not have need for without the original data - the email or the music file. Thus, these contacts would also be marked as sub-resources of the email or music file.

This allows for nice cleanup when removing resources. The methods removeResources() and removeDataByApplication() allow to specify additional flags. One of these flags is RemoveSubResources. Specifying the flag results in the removal of sub-resources.

Resource Metadata

When thinking in Nepomuk terms all the information that is added is only data, not meta-data. (The file indexer which reads file meta-data to store it in Nepomuk also creates just data.) However, Nepomuk also maintains its own meta-data. For each resource the following properties are kept as meta-data:

  • nao:created - The creation date of the resource.
  • nao:lastModified - The last time the resource was modified. This includes the addition, removal, the change of properties, both with the resource as subject and as object.
  • nao:userVisible - A boolean property stating whether the resource should be shown to the user or not. This mostly applies to graphical user interfaces and is used automatically in the Nepomuk Query API.

This information is updated automatically and cannot be changed through the API (except for special cases used for syncing). But it can be queried at any time to be used for whatever purpose.

Resource Identification

Resource identification is an important issue in storeResources(). There are basically three ways to identify a resource:

  1. The trivial way to identify a resource is to provide the exact resource URI.
  2. The second, also rather trivial way to identify a resource is through its nie:url. This can be a local file URL or an http URL or anything else as decribed in Resource URIs.
  3. The last, most interesting way to identify a resource is through its properties and relations. This is what storeResources() does in Nepomuk2::IdentifyNew mode.

In general all properties with a literal range are considered identifying. This includes properties like nao:prefLabel, nie:title, nco:fullname, and so on. All properties with a non-literal range are considered non-identifying. However, there are exceptions to this rule. Some properties with literal ranges are non-identifying since they express the state of a resource or an opinion of a particular user.

Examples of properties like this include nao:numericRating, nie:comment, or nco:imStatus. On the other hand there are properties with non-literal ranges which are in fact identifying. Typical examples include rdf:type, nfo:hasHash, or nmm:performer.

To this end we make use of nrl:DefiningProperty and nrl:NonDefiningProperty. The former is used to mark specific properties as being identifying while the latter states that a property can change over time without actually chaning the identity of the resource.

In storeResources() two resources are considered being equal if all of their identifying properties match and they have at least one identifying propery in common. Matching identifying properties here means that there is no identifying property with a different value in the other resource.

Permissions in %Nepomuk

FIXME: define exactly how permissions are handled. By default all is private. Questions remaining:

  • Do we define permissions on the graph level?
  • What is the range of the permissions? nao:Party?
  • How do we define "public to all"?

Advanced Nepomuk Concepts

This section described advanced concepts in Nepomuk such as the data layout used throughout the database.

Named Graphs in Nepomuk

Nepomuk makes heavy use of named graphs or contexts when talking in terms of Soprano. Essentially the named graphs allow to group triples by adding a fourth node to a statement which can then be used like any other resource. In Nepomuk this mechanism is used to categorize triples and to store meta-data about them.

Nepomuk makes the distincion between four basic types of graphs:

  • nrl:Ontology - An ontology graph contains class and property definitions which are read by the ontology loader. Typically these ontologies come from the Shared-Desktop-Ontologies package installed on the system.
  • nrl:InstanceBase - The instance base is the "normal" graph type. All information added to Nepomuk by clients is stored in instance base graphs.
  • nrl:DiscardableInstanceBase - Being a sub-class of nrl:InstanceBase the discardable instance base also contains "normal" information. The only difference is that this information can be recreated at any time. Thus, it is seen as discardable and is, for example not taken into account in backups. Typical discardable information includes file meta-data created by the file indexer.
  • nrl:GraphMetadata - The graph meta-data graphs only contains meta-data about graphs. This includes the type of a graph, its creation date, and so on.

In addition to its type the following information is stored about each graph, and thus, about each triple in the graph:

  • nao:created - The creation date of the graph (and the triples within)
  • nao:maintainedBy - The application which triggered the creation of the graph. This is important for methods like removeDataByApplication().

Typically the information about one resource is scatterned over several graphs over time since every change to a resource leads to the creation of a new graph to save the creation date and the creating application.

The following example shows the result of indexing one local file:

<nepomuk:/ctx/b17ee4b5-ab8b-4fc5-bcc2-4bc25859cfa6> {
<nepomuk:/res/e02fe67e-7b69-4ea7-847e-ebe2d3623d5c>
nao:created “2011-05-20T11:23:45Z”^^xsd:dateTime ;
nao:lastModified “2011-05-20T11:23:45Z”^^xsd:dateTime ;
nie:contentSize "1286"^^xsd:int ;
nie:isPartOf <nepomuk:/res/80b4187c-9c40-4e98-9322-9ebcc10bd0bd> ;
nie:lastModified "2010-12-14T14:49:49Z"^^xsd:dateTime ;
nie:mimeType "text/plain"^^xsd:string ;
nie:plainTextContent "[...]"^^xsd:string ;
nie:url <file:
nfo:characterCount "1249"^^xsd:int ;
nfo:fileName "helloworld.txt"^^xsd:string ;
nfo:lineCount "37"^^xsd:int ;
nfo:wordCount "126"^^xsd:int ;
a nfo:PlainTextDocument, nfo:FileDataObject .
}
<nepomuk:/ctx/5cf7070e-e4f4-4a0f-8b9a-fe9d94187d82> {
<nepomuk:/ctx/5cf7070e-e4f4-4a0f-8b9a-fe9d94187d82>
a nrl:GraphMetadata ;
nrl:coreGraphMetadataFor <nepomuk:/ctx/b17ee4b5-ab8b-4fc5-bcc2-4bc25859cfa6> .
<nepomuk:/ctx/b17ee4b5-ab8b-4fc5-bcc2-4bc25859cfa6>
a nrl:DiscardableInstanceBase ;
nao:created "2011-05-04T09:46:11.724Z"^^xsd:dateTime ;
nao:maintainedBy <nepomuk:/res/someapp> .
}

Here one important thing is to be noted: the example contains two different last modification dates: nao:lastModified and nie:lastModified. nie:lastModified refers to the file on disk while nao:lastModified refers to the Nepomuk resource in the database.

Author
Sebastian Trueg trueg.nosp@m.@kde.nosp@m..org, Vishesh Handa handa.nosp@m..vis.nosp@m.h@gma.nosp@m.il.c.nosp@m.om

Enumeration Type Documentation

enum Nepomuk2::DescribeResourcesFlag

Flags to influence the result of describeResources().

See the documentation of describeResources() for details.

Enumerator
NoDescribeResourcesFlags 

No flags - default behaviour.

ExcludeDiscardableData 

Exclude discardable data, ie. data which can be re-generated.

ExcludeRelatedResources 

Exclude related resources, only include literal properties.

AnonymizeNepomukUris 

Replaces the resouce URIs which are specific to this instance of Nepomuk with blank nodes.

This only applies to exportResources()

Definition at line 394 of file datamanagement.h.

enum Nepomuk2::RemovalFlag

Flags to influence the behaviour of the data management methods removeResources() and removeDataByApplication().

Enumerator
NoRemovalFlags 

No flags - default behaviour.

RemoveSubResoures 

Remove sub resources of the resources specified in the parameters.

This will remove sub-resources that are not referenced by any resource that will not be deleted. See Sub-Resources for details.

Definition at line 235 of file datamanagement.h.

enum Nepomuk2::StoreIdentificationMode

The identification mode used by storeResources().

This states which given resources should be merged with existing ones that match.

Enumerator
IdentifyNew 

This is the default mode.

Only new resources without a resource URI are identified. All others are just saved with their given URI, provided the URI already exists.

IdentifyNone 

All resources are treated as new ones.

The only exception are those with a defined resource URI.

Definition at line 349 of file datamanagement.h.

enum Nepomuk2::StoreResourcesFlag

Flags to influence the behaviour of storeResources().

Enumerator
NoStoreResourcesFlags 

No flags - default behaviour.

OverwriteProperties 

By default storeResources() will only append data and fail if properties with cardinality 1 already have a value.

This flag changes the behaviour to force the new values instead.

LazyCardinalities 

When lazy cardinalities are enabled any value that would violate a cardinality restriction is simply dropped without throwing an error.

OverwriteAllProperties 

By default storeResources will only append data and fail if properties with cardinality 1 already have a value.

This flags changes the behaviour to force the new value and discards all the previous values. This also works for properties where the cardinality is not 1 It is useful when making large bulk changes

MergeDuplicateResources 

When this is enabled each SimpleResource will be checked to make sure a duplicate of it does not already exist in the SimpleResourceGraph.

If it does exist, then those SimpleResources are merged together.

Definition at line 362 of file datamanagement.h.

Function Documentation

KJob * Nepomuk2::addProperty ( const QList< QUrl > &  resources,
const QUrl &  property,
const QVariantList &  values,
const KComponentData &  component = KGlobal::mainComponent() 
)

Add one or more property values to one or more resources.

Adds property values in addition to the existing ones.

Parameters
resourcesThe resources to add the new property values to. See Resource URIs for details.
propertyThe property to be changed. This needs to be the URI of a known property. If the property has cardinality restrictions which would be violated by this operation it will fail.
valuesThe values to add. For each resource and each value a triple will be created.
componentThe calling component. Typically this is left to the default.

Definition at line 36 of file datamanagement.cpp.

Nepomuk2::CreateResourceJob * Nepomuk2::createResource ( const QList< QUrl > &  types,
const QString &  label,
const QString &  description,
const KComponentData &  component = KGlobal::mainComponent() 
)

Create a new resource.

Creates a new resource with the given types, label, and description and returns the new resource's URI.

Parameters
typesA list of RDF types that the new resource should have. These need to be the URIs of known RDF classes.
labelThe optional nao:prefLabel to be set.
descriptionThe optional nao:description to be set.
componentThe calling component. Typically this is left to the default.

Definition at line 85 of file datamanagement.cpp.

Nepomuk2::DescribeResourcesJob * Nepomuk2::describeResources ( const QList< QUrl > &  resources,
DescribeResourcesFlags  flags = NoDescribeResourcesFlags,
const QList< QUrl > &  targetParties = QList<QUrl>() 
)

Retrieve all information about a set of resources.

Different levels of detail are available when retrieving resources. These are modified through the flags where the following values are supported:

  • ExcludeDiscardableData - If this flag is enabled no discardable data will be returned. This means that any data that has been created through storeResources() using additional metadata including a graph type nrl:DiscardableInstanceBase is ignored. This includes for example all information the file indexer has created. Be aware that this might even mean that some of the requested resources are not returned at all since they only contain discardable information.
  • ExcludeRelatedResources - If this flag is enabled related resources are ignored, only properties with a literal value will be returned. The only exception are sub-resources which are treated as part of the resource itself. Typical examples of sub-resources are address details of a contact or the performer contact of a music track.

Related resources:

If the ExcludeRelatedResources flag is not specified related resources are returned as well. Related resoures are returned by including only their identifying properties. Resource Identification explains the usage of identifying properties in more detail.

Parameters
resourcesThe resources to describe. See Resource URIs for details.
flagsOptional flags to modify the data which is returned.
targetPartiesThis optional list can be used to specify the parties (nao:Party) which should receive the returned data. This will result in a filtering of the result according to configured permissions. Only data which is set as being public or readable by the specified parties is returned. See Permissions in Nepomuk for details. NOT IMPLEMENTED YET!

Definition at line 171 of file datamanagement.cpp.

KJob * Nepomuk2::importResources ( const KUrl &  url,
Soprano::RdfSerialization  serialization,
const QString &  userSerialization = QString(),
StoreIdentificationMode  identificationMode = IdentifyNew,
StoreResourcesFlags  flags = NoStoreResourcesFlags,
const QHash< QUrl, QVariant > &  additionalMetadata = QHash<QUrl, QVariant>(),
const KComponentData &  component = KGlobal::mainComponent() 
)

Import an RDF graph from a URL.

This is essentially the same method as storeResources() except that it uses a different method encoding the resources.

Parameters
urlThe url from which the graph should be loaded. This does not have to be local.
serializationThe RDF serialization used for the file. If Soprano::SerializationUnknown a crude automatic detection based on file extension is used.
userSerializationIf serialization is Soprano::SerializationUser this value is used. See Soprano::Parser for details.
identificationModeThis method can try hard to avoid duplicate resources by looking for already existing duplicates based on nrl:DefiningProperty. By default it only looks for duplicates of resources that do not have a resource URI (SimpleResource::uri()) defined. This behaviour can be changed with this parameter.
flagsAdditional flags to change the behaviour of the method.
additionalMetadataAdditional metadata for the added resources. This can include such details as the creator of the data or details on the method of data recovery. One typical usecase is that the file indexer uses (rdf:type, nrl:DiscardableInstanceBase) to state that the provided information can be recreated at any time. Only built-in types such as int, string, or url are supported.
componentThe calling component. Typically this is left to the default.

See Resource Identification for details on how resources are identified.

Definition at line 154 of file datamanagement.cpp.

KJob * Nepomuk2::mergeResources ( const QUrl &  resource1,
const QUrl &  resource2,
const KComponentData &  component = KGlobal::mainComponent() 
)

Merge two resources into one.

Parameters
resource1The first resource to merge. If both resources have conflicting properties like different values on a property with a cardinality restriction the values from resource1 take precedence. See Resource URIs for details.
resource2The resource to be merged into the first. See Resource URIs for details.
componentThe calling component. Typically this is left to the default.

Definition at line 125 of file datamanagement.cpp.

KJob * Nepomuk2::mergeResources ( const QList< QUrl > &  resources,
const KComponentData &  component = KGlobal::mainComponent() 
)

Merge multiple resources into one.

Parameters
resourcesThe list of resources to merge. If any resources have conflicting properties like different values on a property with a cardinality restriction the values from the first resource take precedence. See Resource URIs for details.
componentThe calling component. Typically this is left to the default.

Definition at line 135 of file datamanagement.cpp.

KJob* Nepomuk2::removeDataByApplication ( const QList< QUrl > &  resources,
Nepomuk2::RemovalFlags  flags = Nepomuk2::NoRemovalFlags,
const KComponentData &  component = KGlobal::mainComponent() 
)

Remove all information about resources from the database which has been created by a specific application.

Parameters
resourcesThe resources to remove the data from. See Resource URIs for details.
flagsOptional flags to change the detail of what should be removed. When specifying RemoveSubResources even sub-resources created by other applications are removed if they are not referenced by other resources anymore.
componentThe calling component. Only data created by this component is removed. Everything else is left untouched. Essential properties like nie:url are only removed if the entire resource is removed.
KJob* Nepomuk2::removeDataByApplication ( Nepomuk2::RemovalFlags  flags = Nepomuk2::NoRemovalFlags,
const KComponentData &  component = KGlobal::mainComponent() 
)

Remove all information created by a specific application.

Parameters
flagsOptional flags to change the detail of what should be removed. Here RemoveSubResources is a bit special as it only applies to resources that are removed completely and spans sub-resources created by other applications.
componentThe calling component. Only data created by this component is removed. Everything else is left untouched. Essential properties like nie:url are only removed if the entire resource is removed.
KJob * Nepomuk2::removeProperties ( const QList< QUrl > &  resources,
const QList< QUrl > &  properties,
const KComponentData &  component = KGlobal::mainComponent() 
)

Remove one or more properties from one or more resources.

Removes all values from all given properties from all given resources.

Parameters
resourcesThe resources to remove the properties from. See Resource URIs for details.
propertiesThe properties to be changed. These need to be the URIs of known properties. If one pf the properties has cardinality restrictions which would be violated by this operation it will fail.
componentThe calling component. Typically this is left to the default.

Definition at line 74 of file datamanagement.cpp.

KJob * Nepomuk2::removeProperty ( const QList< QUrl > &  resources,
const QUrl &  property,
const QVariantList &  values,
const KComponentData &  component = KGlobal::mainComponent() 
)

Remove values of a property from one or more resources.

Removes the given property values.

Parameters
resourcesThe resources to remove the property values from. See Resource URIs for details.
propertyThe property to be changed. This needs to be the URI of a known property. If the property has cardinality restrictions which would be violated by this operation it will fail.
valuesThe values to remove.
componentThe calling component. Typically this is left to the default.

Definition at line 61 of file datamanagement.cpp.

KJob* Nepomuk2::removeResources ( const QList< QUrl > &  resources,
Nepomuk2::RemovalFlags  flags = Nepomuk2::NoRemovalFlags,
const KComponentData &  component = KGlobal::mainComponent() 
)

Completely remove resources from the database.

Parameters
resourcesThe resources to remove. See Resource URIs for details.
flagsOptional flags to change the detail of what should be removed.
componentThe calling component. Typically this is left to the default.
KJob * Nepomuk2::setProperty ( const QList< QUrl > &  resources,
const QUrl &  property,
const QVariantList &  values,
const KComponentData &  component = KGlobal::mainComponent() 
)

Set the values of a property for one or more resources.

Sets property values overwriting/replacing the existing ones.

Parameters
resourcesThe resources to add the new property values to. See Resource URIs for details.
propertyThe property to be set. This needs to be the URI of a known property. If the property has cardinality restrictions which would be violated by this operation it will fail.
valuesThe values to set. For each resource and each value a triple will be created. Existing values will be overwritten.
componentThe calling component. Typically this is left to the default.

Definition at line 48 of file datamanagement.cpp.

Nepomuk2::StoreResourcesJob * Nepomuk2::storeResources ( const Nepomuk2::SimpleResourceGraph &  resources,
Nepomuk2::StoreIdentificationMode  identificationMode = Nepomuk2::IdentifyNew,
Nepomuk2::StoreResourcesFlags  flags = Nepomuk2::NoStoreResourcesFlags,
const QHash< QUrl, QVariant > &  additionalMetadata = QHash<QUrl, QVariant>(),
const KComponentData &  component = KGlobal::mainComponent() 
)

Store many resources at once.

This is the most powerful method of them all. It allows to store a whole set of resources in one go including creating new resources.

Parameters
resourcesThe resources to be merged. Blank nodes (URIs of the form _:xyz) will be converted into new URIs (unless the identificationMode allows to merge with an existing resource). See Resource URIs for details.
identificationModeThis method can try hard to avoid duplicate resources by looking for already existing duplicates based on nrl:DefiningProperty. By default it only looks for duplicates of resources that do not have a resource URI (SimpleResource::uri()) defined. This behaviour can be changed with this parameter.
flagsAdditional flags to change the behaviour of the method.
additionalMetadataAdditional metadata for the added resources. This can include such details as the creator of the data or details on the method of data recovery. One typical usecase is that the file indexer uses (rdf:type, nrl:DiscardableInstanceBase) to state that the provided information can be recreated at any time. Only built-in types such as int, string, or url are supported.
componentThe calling component. Typically this is left to the default.

See Resource Identification for details on how resources are identified.

Definition at line 144 of file datamanagement.cpp.

This file is part of the KDE documentation.
Documentation copyright © 1996-2014 The KDE developers.
Generated on Tue Oct 14 2014 22:48:09 by doxygen 1.8.7 written by Dimitri van Heesch, © 1997-2006

KDE's Doxygen guidelines are available online.

Nepomuk-Core

Skip menu "Nepomuk-Core"
  • Main Page
  • Namespace List
  • Namespace Members
  • Alphabetical List
  • Class List
  • Class Hierarchy
  • Class Members
  • File List
  • File Members
  • Modules
  • Related Pages

kdelibs API Reference

Skip menu "kdelibs API Reference"
  • DNSSD
  • Interfaces
  •   KHexEdit
  •   KMediaPlayer
  •   KSpeech
  •   KTextEditor
  • kconf_update
  • KDE3Support
  •   KUnitTest
  • KDECore
  • KDED
  • KDEsu
  • KDEUI
  • KDEWebKit
  • KDocTools
  • KFile
  • KHTML
  • KImgIO
  • KInit
  • kio
  • KIOSlave
  • KJS
  •   KJS-API
  • kjsembed
  •   WTF
  • KNewStuff
  • KParts
  • KPty
  • Kross
  • KUnitConversion
  • KUtils
  • Nepomuk
  • Nepomuk-Core
  • Nepomuk
  • Plasma
  • Solid
  • Sonnet
  • ThreadWeaver

Search



Report problems with this website to our bug tracking system.
Contact the specific authors with questions and comments about the page contents.

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