<br><br><div class="gmail_quote">On Wed, May 2, 2012 at 10:36 AM, mirsal <span dir="ltr"><<a href="mailto:mirsal@mirsal.fr" target="_blank">mirsal@mirsal.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, 2012-05-02 at 10:07 -0400, Charles Brière wrote:<br>
> On Wed, May 2, 2012 at 7:26 AM, Alex Merry <<a href="mailto:kde@randomguy3.me.uk">kde@randomguy3.me.uk</a>> wrote:<br>
><br>
> > On 02/05/12 11:43, mirsal wrote:<br>
> ><br>
> >> However, rating a track might not be the same thing as simply replacing<br>
> >> the 'userRating' metadata entry (media players might want to mix manual<br>
> >> and algorithmic rating or have multiple sources of rating, see:<br>
</div>> >> <a href="https://gitorious.org/xdg-**specs/xdg-specs/blobs/master/**" target="_blank">https://gitorious.org/xdg-**specs/xdg-specs/blobs/master/**</a><br>
> >> specifications/FMPSpecs/**specification.txt<<a href="https://gitorious.org/xdg-specs/xdg-specs/blobs/master/specifications/FMPSpecs/specification.txt" target="_blank">https://gitorious.org/xdg-specs/xdg-specs/blobs/master/specifications/FMPSpecs/specification.txt</a>>)<br>
<div class="im">> >><br>
> >> It might then be a good idea to handle rating separately, perhaps by<br>
> >> using specific a method for that purpose.<br>
> >><br>
> ><br>
> > Well, media players can do what they want with the value they receive;<br>
> > client should never assume with the MPRIS2 interface that asking the media<br>
> > player to set a value (eg: when seeking) will actually cause that value to<br>
> > be set. They should be listening to the PropertiesChanged signal instead.<br>
> ><br>
> > I think userRating is fairly clearly "the rating that the user has given<br>
> > this track". Xesam also has an autoRating element. I guess we could<br>
> > define values based on FMP as well.<br>
> ><br>
> > We have a more general issue with metadata, which is that Xesam is dead[1]<br>
> > (long live Nepomuk[2]). The Xesam spec is no longer available online,<br>
> > except some old versions on the Wayback Machine. I don't know what we want<br>
> > to do about this; we don't want to break compatibility, but there is not<br>
> > really a reference available for adding more "standard" elements (which was<br>
> > the original point of using Xesam). I guess we can add mpris: elements as<br>
> > and when we feel they are needed, though[4].<br>
> ><br>
> > I should point out that I don't think using Nepomuk is sensible for our<br>
> > purposes, as that is an RDF ontology not really suited for a metadata list<br>
> > like we have.<br>
> ><br>
> > Alex<br>
> ><br>
> ><br>
> ><br>
</div>> > [1]: <a href="http://trueg.wordpress.com/**2009/04/29/xesam_vs_nepomuk/" target="_blank">http://trueg.wordpress.com/**2009/04/29/xesam_vs_nepomuk/</a><<a href="http://trueg.wordpress.com/2009/04/29/xesam_vs_nepomuk/" target="_blank">http://trueg.wordpress.com/2009/04/29/xesam_vs_nepomuk/</a>><br>
> > [2]: <a href="http://www.semanticdesktop." target="_blank">http://www.semanticdesktop.</a>**org/ontologies/<<a href="http://www.semanticdesktop.org/ontologies/" target="_blank">http://www.semanticdesktop.org/ontologies/</a>><br>
> > [3]: <a href="http://web.archive.org/web/**20081012050951/http://xesam.**" target="_blank">http://web.archive.org/web/**20081012050951/http://xesam.**</a><br>
> > org/main/XesamOntology90<<a href="http://web.archive.org/web/20081012050951/http://xesam.org/main/XesamOntology90" target="_blank">http://web.archive.org/web/20081012050951/http://xesam.org/main/XesamOntology90</a>><br>
> > [4]: <a href="http://freedesktop.org/wiki/**Specifications/mpris-spec/**metadata" target="_blank">http://freedesktop.org/wiki/**Specifications/mpris-spec/**metadata</a><<a href="http://freedesktop.org/wiki/Specifications/mpris-spec/metadata" target="_blank">http://freedesktop.org/wiki/Specifications/mpris-spec/metadata</a>><br>
<div class="im">><br>
><br>
> Would their be a problem using only Nepomuk's terms, not everything around<br>
> it? At least their would be accessible documentation on what form of data<br>
> needs to be passed. Those which would create type issues could keep the<br>
> mpris: instead for compatibility (and maybe add a new Nepomuk way).<br>
<br>
</div>Yes, it would break backwards compatibility with previous MPRIS2<br>
implementations, which is the main issue raised by the deprecation of<br>
xesam, whichever solution we adopt (except of course if we do not change<br>
the metadata recommendations but only add missing tags in the mpris:<br>
namespace as Alex suggested ).<br>
<br>
Best,<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
mirsal<br></font></span></blockquote><div><br></div><div>My question was much like if there would be a problem having both, keeping xesam for compatibility and moving on with Nepomuk by keeping the same structure, but adding the possibility to use either </div>
<div><br></div><div>nao:rating or xesam:userRating, </div><div>nao:score or xesame:autoRating for example.</div><div><br></div><div>Charles</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888">
</font></span><br>_______________________________________________<br>
MPRIS mailing list<br>
<a href="mailto:MPRIS@lists.freedesktop.org">MPRIS@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mpris" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mpris</a><br>
<br></blockquote></div><br>