[Nepomuk] Re: How to detect new/removed tags from a Soprano::Statement?

Sebastian Trüg trueg at kde.org
Tue Feb 22 14:47:37 CET 2011


On 02/22/2011 11:48 AM, Christian Mollekopf wrote:
> On Tuesday 22 February 2011 11:28:35 Sebastian Trüg wrote:
>> Hi Chris,
>>
>> On 02/19/2011 01:39 PM, Christian Mollekopf wrote:
>>> On Saturday 19 February 2011 13:02:20 Vishesh Handa wrote:
>>>> The method Laura described is the correct one as of now. Though, we
>>>> would prefer it if you didn't use it. The reason is that you get
>>>> notified for all the statements that have been added/removed - and
>>>> those can be quite a lot.
>>>>
>>>> Especially if files or emails are being indexed. That causes the entire
>>>> system to slow down. I had to monitor everything for Nepomuk
>>>> synchronization, and it caused Nepomuk to slow down so much that in 4.6
>>>> RC1, I finally had to disable it!
>>>>
>>>> We are working on a better way for you to watch changes in the Nepomuk
>>>> Repository. The current API that I have planned is something like this -
>>>>
>>>> ResourceWatcher * watcher = SomeObject->watchType(
>>>> Nepomuk::Vocabulary::NAO::Tag() );
>>>
>>> what is SomeObject?
>>>
>>>> watcher would have its own statementAdded() and statementRemoved()
>>>> signals which would only give you those statements. I was even thinking
>>>> of watching by property.
>>>
>>> Yes, that would be good.
>>>
>>>> Would this solve your use case? Any comments on the API? None of this
>>>> has been implemented so feel free to comment - we can change anything
>>>> at this point.
>>>
>>> I have three usecases.
>>>
>>> Usecase1:
>>> Updating things like TagClouds where I need a signal when a new item of a
>>> certain type (i.e. Tag) is added/removed to/from the repository. For this
>>> the watchType with an added/removed signal for the concerned item would
>>> solve my problems.
>>>
>>> Usecase2:
>>> I filter a QAbstractItemModel based on the PIMO:isRelated property.
>>> So here I need a signal with the Resource and the changed isRelated
>>> property.
>>>
>>> Usecase3:
>>> When I display an item in an editor where I show some Nepomuk properties,
>>> I need a signal only for this exact resource.
>>>
>>> I'd like a similar api like the akonadi::monitor:
>>>
>>>
>>>
>>> //acts as a filter on the emitted signals for object type
>>> ResourceWatcher::watchType(Nepomuk::Vocabulary::NAO::Tag(), bool enable =
>>> true);
>>>
>>> //If set emits only signals for the explicitly watched resources
>>> ResourceWatcher::watchResource(const Nepomuk::Resource &, bool enable =
>>> true);
>>>
>>> //acts as a filter on the emitted signals for predicate
>>> ResourceWatcher::watchProperty(Nepomuk::Vocabulary::PIMO::isRelated(),
>>> bool enable = true);
>>>
>>> Usecase1:
>>> watcher->watchType(Nepomuk::Vocabulary::NAO::Tag() );
>>>
>>> Usecase2:
>>> watcher->watchType(Nepomuk::Vocabulary::NAO::Topic() );
>>> watcher->watchProperty(Nepomuk::Vocabulary::PIMO::isRelated());
>>
>> So here you want to be notified of changes that involve the properly
>> pimo:isRelated and a subject of type pimo:Topic? In other words:
>> whenever a property pimo:isRelated is added to or removed from a
>> resource that has the type pimo:topic you want to be notified?
>>
> Basically yes, although It would be possible to make the group of monitored 
> resources smaller.
> 
> I have an akonadi model filled with items, and I filter those items based on the 
> nepomuk topic. So I need to emit dataChanged for the correct item if the topic 
> has changed, so the filter is reevaluated.
> So I don't actually need to be notified for all resources in the storage but 
> only a group of items. Maybe we could limit the resources by a custom mimetype 
> or so?
> 
> So far I do not set any mimetype on the resources I create, but this might be 
> something which should be done?

mimetypes are not the way to go. We only filter by type.
So a watcher would allow to specify a set of resources, a set of
properties, and a set of types where the following combinations make sense:

1. Only resources are set:
   Signals about property changes of the configured resources and
   deletion of the resources.
2. Resources and properties are set:
   Signals about property changes of the configured resources and the
   configured properties.
3. Only properties are set:
   Signals for any property change that involves the configured
   properties.
4. Only types are set:
   Signals about newly created or deleted resources of any of the
   configured types.
   (Possible variant via flag or whatever: Signals about property
   changes for any resource of any of the configured types.)
5. Types and properties set:
   Signals about property changes for any of the configured properties
   on any resource of any of the configured types.

IMHO other combinations do not really make sense.

Is this enough? Is something missing?

Cheers,
Sebastian

>>> Usecase3:
>>> watcher->watchResource(res, true);
>>> //and maybe filtering for only the properties which im interested in
>>>
>>> I think that would keep us quite flexible and would be exactly what I'm
>>> looking for.
>>>
>>> Cheers,
>>>
>>> Chris
>>>
>>>> On Fri, Feb 18, 2011 at 5:25 PM, Laura Dragan <aprilush at gmail.com> wrote:
>>>>> On Thursday 17 February 2011 16:32:45 Christian Mollekopf wrote:
>>>>>> Hey Laura,
>>>>>>
>>>>>> On Thursday 17 February 2011 14:10:58 Laura Dragan wrote:
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> On Thursday 17 February 2011 01:14:02 Christian Mollekopf wrote:
>>>>>>>> hi,
>>>>>>>>
>>>>>>>> Does anybody know how I can detect when a new Tag was added/removed
>>>>>>>> to/from Nepomuk? I.e. to update a Tag Cloud.
>>>>>>>
>>>>>>> do you need to update the tag cloud if any resource is tagged outside
>>>>>
>>>>> your
>>>>>
>>>>>>> app, or just inside your app?
>>>>>>
>>>>>> I'd like to update it whenever new tags are available, not only from
>>>>>
>>>>> within my
>>>>>
>>>>>> app.
>>>>>>
>>>>>>> In SemNotes for instance the tag cloud is built only with the tags
>>>>>>> used
>>>>>
>>>>> on
>>>>>
>>>>>>> the notes - you can find that code on gitorious.
>>>>>>>
>>>>>>> A long time ago I wrote a plasmoid that built the tagcloud for the
>>>>>
>>>>> entire
>>>>>
>>>>>>> desktop (not sure if it's in playground or not), and that one was
>>>>>>> listening to statementsAdded and statementsRemoved from the model,
>>>>>>> but
>>>>>
>>>>> I
>>>>>
>>>>>>> took the easy path and rebuilt the cloud every time instead of just
>>>>>>> updating it. It worked ok with up to 30 tags, without visible delays
>>>>>
>>>>> from
>>>>>
>>>>>>> all the repository querying.
>>>>>>>
>>>>>>>> Currently I listen to the statementAdded/statementRemoved signals
>>>>>>>> of
>>>>>
>>>>> the
>>>>>
>>>>>>>> Soprano::Model, and I can also detect if an Item gets a new Tag,
>>>>>>>> but
>>>>>
>>>>> I
>>>>>
>>>>>>>> don't know how I can see from the Statement when a new Tag was
>>>>>
>>>>> created
>>>>>
>>>>>>>> or a Tag was deleted.
>>>>>>>
>>>>>>> I think you can use the signals
>>>>>>>
>>>>>>> void statementAdded( const Soprano::Statement &statement)
>>>>>>> void statementRemoved( const Soprano::Statement &statement)
>>>>>>>
>>>>>>> to look into the statements that are affected with the functions:
>>>>>>> subject(), predicate() and object().
>>>>>>
>>>>>> Thats what I'm trying to do, but I don't get what indicates that a tag
>>>>>> is
>>>>>
>>>>> new
>>>>>
>>>>>> to the Nepomuk system (or that a tag was removed).
>>>>>
>>>>> I'd do that by checking if the statement added or removed has the
>>>>> predicate "rdf:type" and the object "nao:Tag". The subject of the
>>>>> statement is then the uri of the tag that was created or deleted.
>>>>>
>>>>> Laura
>>>>>
>>>>>> Thanks for your help,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>> Hope this helps
>>>>>>> Laura
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Chris
> 
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
> 


More information about the Nepomuk mailing list