[Nepomuk] Some questions regarding the DMS API

[Sebastian Trüg]

On 02/11/2012 11:23 PM, Jörg Ehrichs wrote:
> 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.

My TV show code actually uses classes generated from the latest
nepomuk-simpleresource-rcgen which creates sub-classes of
SimpleResource. The old way is not available anymore.

> 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?

No, the new rcgen should produce sub-classes of SimpleResource as
mentioned above. This is an excerpt from the tv show code:

Nepomuk::NCO::Contact contact;
contact.setFullname(guestStar);
episodeRes.addActor(contact.uri());
episodeRes.addProperty(NAO::hasSubResource(), contact.uri());

> 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?

We discussed this on IRC. Is this solved now? You can change the nie:url
via DMS' setProperty method.

> 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.

Good point. The DBus api already has that for scripting.

Care to make a patch? :P

Cheers,
Sebastian