[Nepomuk] [KFileMetaDataWidget] Grouping of interconnected information

[Matthias Fuchs]

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