[MPRIS] User rating read-only

[Charles Brière]

On Wed, May 2, 2012 at 10:36 AM, mirsal <mirsal at mirsal.fr> wrote:

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

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

nao:rating or xesam:userRating,
nao:score or xesame:autoRating for example.

Charles

>
> _______________________________________________
> MPRIS mailing list
> MPRIS at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mpris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mpris/attachments/20120502/ea4e8dfd/attachment.htm>