On Tue, Aug 16, 2011 at 12:26 PM, Philip Van Hoof <[email protected]> wrote: > On Tue, 2011-08-16 at 11:26 +0300, Ivan Frade wrote: >> Hi! >> >> On 8/15/11, Sam Thursfield <[email protected]> wrote: >> > Hi! >> > >> > A lot of people these days have CDs stored as one big .FLAC file, with >> > a .CUE sheet listing the offset of each actual track. To get Tracker >> > to recognise these requires some sort of ontology addition to express >> > the track offsets. As far as I can see, the best solution is the >> > following: each logical track is a nmm:MusicPiece resource with its >> > nie:uri pointing to the one .FLAC file, and a new >> > nfo:audioContainerOffset property that specifies the offset in samples >> > of the track into its file. >> >> What about adding an anchor/parameters in the URI? Somehow those >> positions in the stream sound like "anchors" in a URL. >> >> As a norm, is not good to encode information in the URI but in this >> case could make sense. > > It's even necessary in this case, as nie:url is a Inverse Functional > Property, meaning that it must be unique.
I did like the idea of the URL with a fragment, but now I realise how much extra data the FS miner attaches when it adds nie:FileDataObject information - it seems wrong for the tracks of a larger file to also have type FileDataObject (necessary to set nie:url) but not have any of the useful file-specific metadata that the FS miner would attach (because we create the tracks as part of the preupdate). It now seems more "correct" to me to make the tracks have no nie:url, but relate them to the container file with nie:isStoredAs and add a nmm:containerOffset propery which gives the time offset in the container. Is this logical? Sam _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
