[Nepomuk] [KFileMetaDataWidget] Grouping of interconnected information

Sebastian Trueg trueg at kde.org
Thu Sep 16 10:49:27 CEST 2010 

I took some time on the train and here is one proposal that we could
discuss:

I started with the following issues that the display rules need to address:
input:
  * 1 resource or resource type
  * 1 or more properties (using multiple properties allows to merge
    them like with image dimensions or to combine information that
    matches into a readable expression)
  * value for each property (as Variant, ie. lists are supported)

output:
  * a Qt-style richt-text string with optional links (queries or other
    local or remote URLs)
  * how about pixmaps? icons should be easy to integrate...
  * how about a template system which allows to replace variables with
    values or query results. the latter would require a tool for query
    generation

rule registration:
  * supported type
  * supported property
  * optional: supported value type (in case of non-literal ranges)

rule selection:
  * be greedy
  * try to find the best matching rule via type and properties that are
    as specialized as posssible

The I drafted one random example trying to include the full syntax:
<rule>
  <resourceType uri=foobar />
  <resourceType uri=xyz />
  <propertyGroup>
    <property name=p1 uri=abc />
    <property name=p2 uri=def />
  </propertyGroup>
  <variable name="a" type=string>
    <propertyValue property=p1 />
  </variable>
  <variable name="b" type=uri>
    <propertyValue property=p2 />
  </variable>
  <query name="myquery">
    <sparql>select ?r where { ?r nao:hasTag <%r> . }</sparql>
  </query>
  <variable name="c" type=domain>
    <binding query="myquery" bindingName="r" />
  </variable>
  <query name="queryThatDependsOnAnotherVariable">
    <sparql>select ?r where { ?r <foobar> <%c> . }</sparql>
  </query>
  <query name="q1" queryFiles="true" queryFolders="true" limit="0"
         offset="0" fullTextScoring="false" fullTextScoringOrder="asc"
         flags="">
    <comparison
property="http://www.semanticdesktop.org/ontologies/2007/08/15/nao#hasTag"
comparator="=" inverted="false">
      <resource uri="%r"/>
    </comparison>
  </query>
  <variable name="d">
    <binding query="q1" bindingIndex=0 />
  </variable>
  <template>Something blabla &lt;a href="%b"&gt;%a&lt;/a&gt;</template>
  <icon name="nepomuk" />
</rule>

The generic fallback rule (the absence of resourceType and property uri
mean: no restriction, i.e. all apply):
<rule>
  <propertyGroup>
    <property name=p1 />
  </propertyGroup>
  <variable name="a"><propertyLabel property=p1 /></variable>
  <variable name="b"><propertyValue property=p1 /></variable>
  <template>%a: %b</template>
</rule>

Example 1: download location
<rule name="download location">
  <resourceType uri=nfo:FileDataObject />
  <propertyGroup>
    <property uri=ndo:copiedFrom name="copiedFrom" />
  </propertyGroup>
  <query name="referrerQuery"><sparql>select ?ref where { ?dl a
ndo:DownloadEvent . ?dl nuao:involces <%r> . ?dl ndo:referrer ?ref . }
limit 1</sparql></query>
  <variable name=refUrl type=uri>
    <binding query="referrerQuery" bindingName="ref" />
  </variable>
  <variable name=refUrl type=label>
    <binding query="referrerQuery" bindingName="ref" />
  </variable>
  <template i10l-context="blablabla blabla">Downloaded from &lt;a
href="%refUrl"&gt;%label&lt;/a&gt;</template>
  <template lang="de">Geladen von &lt;a
href="%refUrl"&gt;%label&lt;/a&gt;</template>
</rule>


A few facts:
* There is one special variable: %r which is always replaced by the
resource's URI.
* With a sparql or desktop query only the first binding is used.
* A variable can have an optional type. This is mostly useful to get
  the genericLabel for resources or specifically select the URI
  - uri - the resource URI - will be ignored for literal bindings
  By default all values are converted into strings creating pretty
  values for dates and times and number values. TODO: let
  Resosurce:genericLabel() extract the domain from http URLs?
* Use %% to include a percent character in the template.
* If a variable has no value (empty query results) the rule fails and
  then next is used
* What is a PropertyGroup? The idea is to support multiple properties
  in a single rule. But since a rule can also "merge" several
  properties' values we need a distinction between a group of
  properties that can be "merged" and properties that can all be
  handled by the rule. As an example a rule may provide the same
  formatting for property A and B which would be realized as 2
  propertyGroups. Another rule would take two properties as input and
  put them in a single template. This would be done using a single
  propertyGroup.
* The syntax for the queries is the same as created and parsed by
  Query::toString() and Query::fromString(). The only exception is the
  additional "name" attribute.
* Do we need if/then/else constructs? Answer: even if we do we can
  perfectly introduce them later on as variable constructs which allow
  to choose between other variables or constants.

Open Questions:
* How do we create query links? By specifying the nepomuksearch:/ URL
  directly? That would make dynamic queries harder. But how would we do
  dynamic queries anyway?
* Does the "icon" make sense? It would be displayed in front of the
  label or something.
* We could use some sort of rule weight to prioritize them in addition
  to the automatic priorization mentioned above
* Why XML and not RDF: 1. XML is simpler in this case. 2. I don't see
  the advantage of having the rules in the database (I might be
  mistaken though). 3. FIXME: check the RDF dialect again which allows
  to describe something like this but AFAIK without queries. ON THE
  OTHER HAND: If we had an RDF dialect we could 1. store rules with the
  ontologies, 2. query appropriate rules via SPARQL, 3. have a database
  that supports the formatting rule through a sparql extension...

Well, this is my braindump. Now please ask, comment, and discuss away. :)

Cheers,
Sebastian

On 09/14/2010 05:19 PM, Sebastian Trüg wrote:
> 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
>>
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>

More information about the Nepomuk mailing list