After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 641248 - nmm:MusicPiece should derive from nfo:Audio
nmm:MusicPiece should derive from nfo:Audio
Status: RESOLVED NOTABUG
Product: tracker
Classification: Core
Component: Ontology
git master
Other Linux
: Normal normal
: ---
Assigned To: tracker-general
Jamie McCracken
Depends on:
Blocks:
 
 
Reported: 2011-02-02 15:00 UTC by Jussi Kukkonen
Modified: 2011-03-08 11:55 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
nmm:MusicPiece should derive from nfo:Audio (761 bytes, patch)
2011-02-02 15:00 UTC, Jussi Kukkonen 		rejected Details | Review

Description Jussi Kukkonen 2011-02-02 15:00:18 UTC 
Created attachment 179887 [details] [review]
nmm:MusicPiece should derive from nfo:Audio

Currently "nmm:MusicPiece" derives from "nfo:Media". I believe the superclass should be "nfo:Audio".


Also, all extractors have code like this:
	tracker_sparql_builder_predicate (metadata, "a");
	tracker_sparql_builder_object (metadata, "nmm:MusicPiece");
	tracker_sparql_builder_object (metadata, "nfo:Audio");


Both shouldn't be necessary... Ideally the type should probably be "MusicPiece" if any nmm properties (say artist) are found, and "Audio" otherwise.
Comment 1 Jussi Kukkonen 2011-02-03 15:41:46 UTC 
Oh, another thing:

There is no way to define "generic audio" -- e.g. podcasts -- so that it would be easy to search for even after this fix:
 * "?audio a nfo:Audio" will return video files as well.
 * "?audio a nmm:MusicPiece" will only return music files

Maybe there should be a nmm:Audio that is a subclass of nfo:Audio and superclass of nmm:MusicPiece? Alternatively we could just give up and say MusicPiece is for all audio... that's what everyone seems to do in practice.
Comment 2 Ivan Frade 2011-02-04 10:39:52 UTC 
We could do a hierarchy like this:

nfo:Media 
 \ nfo:Audio 
    \nmm:Audio -> To keep all the nmm properties now in nmm:MusicPiece
      \ nmm:MusicPiece
      \ nmm:Podcast
      \ nmm:AudioBook

But i am not sure it is useful at all. The problem with Podcast and Audiobook is that are impossible to distinguish in the filesystem (they just look like regular MP3). Or the application downloading those files put them in the right category or they will be considered MusicPieces.
Comment 3 Ivan Frade 2011-03-08 11:49:18 UTC 
The intention is to use nmm:MusicPiece for the non-technical data (what the user really cares) and let nfo:Audio for the technical details (like "gain", "rearChannel"...). 

Making nmm:MusicPiece subclass of nfo:Audio doesn't provide any practical difference with the current design. Note that the podcast issue is independent.
Comment 4 Ivan Frade 2011-03-08 11:55:43 UTC 
Review of attachment 179887 [details] [review]:

No need to change the ontology.