[Nepomuk] [KFileMetaDataWidget] Grouping of interconnected information

[Sebastian Trüg]

Actually I only meant the rule thing, not the whole
resource-visualization plugin stuff. So in the end the goal is "only" to
come up with a way to describe the points I outlined using XML or some
other format. Then we need to parse that and implement a generator which
should be fairly easy.
Thus, all in all the problematic part is the rule format.

Cheers,
Sebastian

On 09/14/2010 05:08 PM, Matthias Fuchs wrote:
> Looks really complex, I guess this is over my knowledge of most Nepomuk 
> Ontologies -- thus also what could be an requirement.
> 
> You mentioned one of your tries. Do you think that future tries would involve 
> less code, e.g. looking at the bibtex example?
> Because that example really outlines that either using C++ is not that useful 
> for this task -- too code needed, e.g. subclassing -- or maybe a system 
> depending on something different should be used.
> 
> In that case I am afraid that I'm not really useful in drafting such system 
> that would really work and be efficient. I guess I could implement support for 
> some ontologies once it is drafted but I suppose this would be the easiest 
> part anyway.
> 
> Am Montag 13 September 2010, 09:53:36 schrieb Sebastian Trüg:
>> Hi Matthias,
>>
>> thanks for putting the problem out there.
>> So far most of the information we have on files are legacy key/value
>> pairs with literal values like file size, image dimensions, title, and
>> so on. And even resource values like artists and albums could simply be
>> handled by displaying the corresponding resource's label. But as more
>> and more elaborate information enters Nepomuk this solution does not
>> work anymore.
>> The first time this happened (download locations) I create an ugly hack
>> which queries the download event for details like the download and the
>> referrer URL. This is of course a bad solution since we cannot create a
>> special case for all types of information we could encounter.
>> Thus, the idea is in fact to create a rule system.
>>
>> Such a rule system would consist of rules (who would have thought) which
>> convert a property into something displayable. As input it needs more
>> than just the value which is obvious. But I think it even needs more
>> than the property and the value since we have rather generic properties
>> like "creator" which are used in all kinds of situations. A typical
>> example are audio files where "creator" is used for the artist. Thus,
>> the rule needs to know the type of the subject in order to decide
>> whether to use "artist" or "author" or the generic "creator".
>> Thus, one rule needs at least the following input:
>>  * The resource type (maybe even a list of types of the resource
>>    itself?)
>>  * The property
>>  * The value
>> Based on this information the rule should be able to
>>  * Add fixed text (maybe even rich-text formatted)
>>  * Add links (to other resources and web URLs and even to queries)
>>  [* Define actions?]
>>
>> I already tried this at least once. And in playground[1] you can find a
>> very bad first version of such a rule system.
>> So we need to come up with a much better system and syntax as the one I
>> drafted in playground. An idea is to use XML since it is easy to parse.
>> But writing and reading it can be a pain.
>>
>> Thus - ideas and comments please.
>>
>> Cheers,
>> Sebastian
>>
>> [1]
>> http://websvn.kde.org/trunk/playground/base/nepomuk-kde/resource-visualizat
>> ion/ and
>> http://websvn.kde.org/trunk/playground/base/nepomuk-kde/resource-visualizat
>> ion/sample.rules?view=markup
>>
>> On 09/10/2010 11:50 PM, Matthias Fuchs wrote:
>>> Hi,
>>>
>>> I discussed a problem on irc and sebastian trueg mentioned that I should
>>> also write on it here.
>>>
>>> The problem is that there is no graphical representation of information
>>> that is interconnected.
>>>
>>> Take NFO::hashAlgorithm and NFO::hashValue as example. At the moment both
>>> are displayed in their own line and there is no visual link between
>>> them. Now if more algorithms and values were added it would get a little
>>> complicated for the user to associate the correct values with the
>>> algorithms.
>>>
>>> Ideally both would be displayed in one line, e.g. "SHA1 hash:
>>> 325e69d24514f7b26834a93ad260f3024127714b".
>>>
>>>
>>> Though this solution would most likely not apply to other information
>>> that should also be graphically grouped. Sebastian mentioned that he
>>> tried to create a solution for this once with having an xml file and
>>> another time with a custom format.
>>>
>>> So as he put it there is a need for a rule system to graphically
>>> represent the information.
>>>
>>>
>>>
>>> PS.: Grouping information graphically would also the advantage of making
>>> information easier hideable/collapsible.
>>> PPS.: I created a bug report for this
>>> https://bugs.kde.org/show_bug.cgi?id=250819
>>>
>>> _______________________________________________
>>> Nepomuk mailing list
>>> Nepomuk at kde.org
>>> https://mail.kde.org/mailman/listinfo/nepomuk
>>
>> _______________________________________________
>> Nepomuk mailing list
>> Nepomuk at kde.org
>> https://mail.kde.org/mailman/listinfo/nepomuk
> 
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>