Please ask development related questions in the KDE Community Forum.
Development/Tutorials/Metadata/Nepomuk/ResourceGenerator
Languages: عربي | Asturianu | Català | Česky | Kaszëbsczi | Dansk | Deutsch | English | Esperanto | Español | فارسی | Suomi | Français | Galego | Italiano | 日本語 | 한국어 | Norwegian | Polski | Português Brasileiro | Română | Русский | Svenska | Slovenščina | српски | Українська | 简体中文 | 繁體中文
| Tutorial Series | Nepomuk |
| Prerequisites | Introduction to RDF and Ontologies |
| What's Next | Advanced Queries in Nepomuk |
| Further Reading | Resource Handling with Nepomuk, The Nepomuk Resource Generator (KDE API Dox) |
[edit] The Nepomuk Resource Class Generator
Nepomuk::Resource provides methods to set and retrieve properties using a QUrl object identifying the property and a Nepomuk::Variant as the value. This is not very convenient as one has either to hard code property URIs or generate Vocabulary namespaces using Soprano's onto2vocabularyclass tool.
It is easier to simply use the resource generator to generate wrapper classes that provide convenience methods to set and get properties.
The idea is that for each RDF class a corresponding Nepomuk::Resource subclass is generated which provides getter and setting methods for all properties in the domain of that particular RDF class.
[edit] Usage in CMake
The resource generator is best used through the CMake macro provided by Nepomuk. KDE 4.4 already ships the macro nepomuk_add_ontology_classes. For KDE 4.3 one has to use the macro_add_ontology_classes in playground.
The syntax is fairly simple and similar to the macro for adding ui files to a list of sources:
NEPOMUK_ADD_ONTOLOGY_CLASSES(<sources-var>
[FAST]
[ONTOLOGIES] <onto-file1> [<onto-file2> ...]
[CLASSES <classname1> [<classname2> ...]]
[VISIBILITY <visibility-name>]
)
If FAST is specified the rcgen parameter --fast will be used which results in resource classes not based on Nepomuk::Resource but on a custom class which does not perform any checks and simply writes the data to Nepomuk (hence the name fast).
The optional CLASSES parameter allows to specify the classes to be generated (RDF class names) in case one does not want all classes in the ontologies to be generated. If omitted all classes in the ontology files will be generated.
The optional VISIBILITY parameter can only be used in non-fast mode and allows to set the gcc visibility to make the generated classes usable in a publically exported API. The <visibility-name> is used to create the name of the export macro and the export include file. Thus, when using "VISIBILITY foobar" include file "foobar_export.h" needs to define FOOBAR_EXPORT.
[edit] Example
include(NepomukAddOntologyClasses)
set(SRCS [...])
nepomuk_add_ontology_classes(SRCS ONTOLOGIES ontology.trig)
kde4_add_executable(foobar ${SRCS})
target_link_libraries(foobar
nepomuk
)
