[Nepomuk] Re: NMM, music ratings and muzicbrainz ID

[Sebastian Trüg]

Hi Roman,

late reply due to holidays:

The clean solution would indeed be to create a pimo thing and attach all
information to that one. That would directly solve the problem of
handling music pieces without files.
Theoretically it would even be clean to duplicate the information like
composer and so on. After all there might be a difference between what
is stored in the file and what is actually "true". (Of course this
distinction is not important to most users.)

In the spirit of compatibility we could add additional domains to the
NMM properties and introduce new types to represent the "actual" music
pieces and not the data that is stored somewhere. Then the file could
also be double-typed for the simplest use case or it could link to the
"actual" music piece.
Here we could have a hierarchy again. Something like:

nmm:AudioSomething
  |- nmm:MusicTrack
  |- nmm:Interview
  |- nmm:....

where AudioSomething is a bad name but the class could (or should?) be a
subclass of pimo:Thing.

We actually have a quite similar problem with TV show information:
currently that is attached to the information element, too. Thus, not
allowing to have the same TV show in several files.

If we can come up with a good solution for audio files we could, maybe,
extend it to TV shows and movies.

Cheers,
Sebastian

On 12/24/2010 09:42 PM, Roman Evstifeev wrote:
> Hi list. I'm trying to resolve a problem of organizing user's music metadata.
> 
> Let's say i want o write an application, that will allow to keep track
> of user's music ratings, playcounts, tags and so on.
> 
> Problem number 1:
> User can have the same audio file in flac and in mp3 on the same machine
> In my app i want to allow user see all of them, and rate them as one -
> i.e. to rate music tracks, but not the files themselves.
> The point is - there should not be a situation, where two files,
> representing the same music track will have different ratings.
> nmm:MusicPiece is subclass of nie:InformationElement, and it is in
> domain of nfo:codec.
> So essentially i should have 2 MusicPieces (each having its own
> codec), and rate some other resource, which links to them both.
> 
> Possible solution (suggested by phreedom) :
> Declare a new Class. subclass of pimo:Thing, wich will represent a
> music track. (let's name it pimo:MyMusicPiece)
> Then create instance of it, rate it, and link it to the relevant
> MusicPieces as a pimo:groundingOccurence_s of that thing
> 
> but there is another problem:
> 
> Problem numer 2:
> There may not be a file at all.
> I want to allow user to have metadata about music, that is not
> represented by any local (or remotely accessible) file.
> (usecase: i have a vinyl disk on shelf, and want to share my opinion
> about it with friends (for ex. rating). i don't have any file.)
> I surely want to also keep general data about this music as: Artist,
> Title and possibly muzicbrainz ID.
> Currently nmm:musicBrainzTrackID property is in domain of nmm:MusicPiece
> This raises few questions:
> 1) Should nmm:MusicPiece(nie:InformationElement) have a relevant
> file(nie:DataObject?) at all?
> 
> If so, there is a Possible solution 1:
> i can make my pimo:MyMusicPiece instances also nmm:MusicPiece_s
> without them representing any particular file.
> Then i can apply properties such as nmm:musicBrainzTrackID, nmm:composer to it.
> 
> Possible solution 2:
> Create my own properties, resembling nmm:musicBrainzTrackID and
> nmm:composer, but in domain of my pimo:MyMusicPiece.
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>