[Nepomuk] Some questions regarding the DMS API

Jörg Ehrichs Joerg.Ehrichs at gmx.de
Sat Feb 11 22:23:23 UTC 2012


Hi everyone,

as I've adopted my program Conquirere to the new Nepomuk DMS system,
I've came across a few questions.

1. Ontology Member Wrapper classes
As the new API relies on the new SimpleResource also the automatically
generated ontology classes are changed with it.
Now it seems there are 2 different API available in this case.

One that uses Pointer ( as shown by Sebastians latest tv show
approach) and another one that uses references withing the member
wrapper.
What is now the way to go? I've found an old mailing list entry that
seem to have settled on the reference approach.

The nepomuk-simpleresource-rcgen from current git master produces the
same result.
Can I assume it stays this way? Currently I have added all the
generated header files to my repo, but this is really not a good thing
to do.

2. Again the wrapper stuff
The old nepomuk-rcgen did produce files like nfo.h/pimo.h/nie.h etc so
I can write stuff like resource.setProperty( NIE:title() "title") and
so on. The new nepomuk-simpleresource-rcgen does not produce these
files.
Does it mean, the right approach is to rely on the wrapper classes? so
I always have to write stuff like
Nepomuk::NIE::InformationElement(resource).setTitle("title") or will
the old way of producing this headerfile containing the url
abbreviation still be around?

3. Not able to change nie:url
I know the nie::url is used to identify duplicates and such thing. But
is it really necessary to forbid the changing of the nie:url property
via the DMS? I came across this, while I had to change a typing error
in a nfo:RemoteDataObject and I wanted to change the url. Is the only
approach to create a complete new resource, merge it with the old one
and then remove the old resource?

Other than these things, the new DMS system is really great. I could
remove absolutely any code that was trying to avoid duplicates and the
merging feature works great.
One nice API addition would be to add overloaded functions for
addProperty, setProperty removeProperty etc that take QUrl/QVariant
instead of the QList version. Most of the time I only want to change 1
resource and only one property of it.

Kind Regards,
Jörg Ehrichs


More information about the Nepomuk mailing list