[Nepomuk] Review Request: Use nie:hasPart instead of nie:hasLogicalPart in m3u analyser

[Vishesh Handa]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102230/#review5502
-----------------------------------------------------------


1. Let the indexer add the nie:InformationElement type

I'm not too sure.

2. Let Nepomuk assume every local file is a nie:InformationElement anyway (actually this is what the file indexer already does so we might think about doing it in the Data Management Service as well)

No. Every file is not supposed to be a nie:InformationElement. AFAIK that was added a hack for 4.7 so that we don't break too many things.

3. Use nie:hasPart in the analyser.

I'm not too sure how to go about this. It seems as though nie:hasLogicalPart should accept nfo:DataObjects as well, cause the m3u file is just a text file that contains paths to other files. So, it "logically" contains them, not physically ( as in the case of Messages and attachments )

- Vishesh


On Aug. 5, 2011, 8:53 p.m., Sebastian Trueg wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102230/
> -----------------------------------------------------------
> 
> (Updated Aug. 5, 2011, 8:53 p.m.)
> 
> 
> Review request for Nepomuk and Strigi.
> 
> 
> Summary
> -------
> 
> The range of nie:hasLogicalPart is nie:InformationElement. As far as Nepomuk is concerned any local file is only a nfo:FileDataObject by itself. Thus, indexing m3u files fails with an invalid range error.
> Now there are basically three ways to solve this:
> 1. Let the indexer add the nie:InformationElement type
> 2. Let Nepomuk assume every local file is a nie:InformationElement anyway (actually this is what the file indexer already does so we might think about doing it in the Data Management Service as well)
> 3. Use nie:hasPart in the analyser.
> The latter is what this patch does. But actually I would rather like to think this through before pushing this. I cannot wrap my head around it: does the m3u file refer to the files on disk or the information elements inside the files?
> 
> 
> Diffs
> -----
> 
>   lib/lineanalyzers/m3ustreamanalyzer.cpp dacc15a 
> 
> Diff: http://git.reviewboard.kde.org/r/102230/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Sebastian
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20110808/7f097b69/attachment.html>