请参见Nepomuk资源产生.

[edit] Nepomuk资源类产生器

Nepomuk::Resource提供了一个办法，可以用QUrl对象来辨识属性以及辨识Nepomuk::Variant，同时还提供读写功能。但这不是个太好的办法，开发人员要在代码里写死属性URL，要么用Soprano's onto2vocabularyclass工具来生成词汇（Vocabulary）的名字空间。

最简单的办法就是用资源产生器来生成包装类，用包装类来读写各个属性。properties.

这里的想法就是：每个RDF类都对应一个Nepomuk::Resource子类，以他来对RDF类的各个领域属性提供存取方法。

[edit] 使用CMake

Nepomuk提供了CMake的宏定义，可以用它来使用资源生成器。KDE 4.4已经定义了nepomuk_add_ontology_classes的宏。对KDE 4.3，我们还的用playground的macro_add_ontology_classes宏.

语法很简单，和添加一系列资源文件的宏定义差不多:

NEPOMUK_ADD_ONTOLOGY_CLASSES(<sources-var>
         [FAST]
         [ONTOLOGIES] <onto-file1> [<onto-file2> ...]
         [CLASSES <classname1> [<classname2> ...]]
         [VISIBILITY <visibility-name>]
       )

如果对regen参数使用了FAST选项--fast意味着资源类不会基于Nepomuk::Resource产生而是基于一些自定义类，其中不做任何检查，只是把数据写到Nepomuk(hence the name fast)。

CLASSES参数是可选项，在那些不必生成所有本体类的情况下，这个参数指定那些要生成的类(RDF类名)。如果省略的话，会生成本体中所有的的类。

VISIBILITY参数是可选项，只能用在非－FAST的模式下。把GCC的可视性设为可以让产生的类可以在导出的公共API中使用。<visibility-name>用于生成导出宏的名字和导出文件。这样，使用"VISIBILITY foobar"时，包含文件"foobar_export.h"要定义FOOBAR_EXPORT。

[edit] 案例

include(NepomukAddOntologyClasses)
 
set(SRCS [...])
 
nepomuk_add_ontology_classes(SRCS ONTOLOGIES ontology.trig)
 
kde4_add_executable(foobar ${SRCS})
target_link_libraries(foobar
  nepomuk
)