[Nepomuk] OSCAF and music live and videoclips

[Ignacio Serantes]

On Fri, Mar 23, 2012 at 5:48 PM, Andrew Lake <jamboarder at gmail.com> wrote:

> On Thu, Mar 22, 2012 at 11:56 PM, Sebastian Trüg <sebastian at trueg.de>
> wrote:
> >
> >> nmm:LiveMusicVideo, nmm:ConcertMusicVideo and, maybe,
> >> nmm:VideoMusicVideo :?. I'm not strong in English names so for me is
> >> good if I could store the information I want.
> >
> > Let's get Banganrang into the mix. What do you think, Andrew?
> >
>
> Thanks for the cc Sebastian. :-)
>
> I was also looking for a way to basically link videos to music. How
> far can we go to solving this without introducing new types?
>
> So these videos are basically performances of a particular MusicPiece.
> Hmm, what about a property sort of like nmm:performanceOf ?  So any
> nfo:Video could be a performance of a particular nmm:MusicPiece.  You
> might even be able to link different nmm:MusicPiece or even nfo:Audio
> in the same way. So maybe a domain of nfo:Media?
>
> I can see the value of changing the domain of nmm:performer to
> nfo:Media since I can imagine several kinds of media beyond
> nmm:MusicPiece that have performers (audio books, spoken word, live
> concerts, poetry, stand up comedy shows, etc.).
>
> For a portion of a video (tvshow, concert, etc.) that has the
> performance of a particular music piece, I could see value in a
> nmm:VideoPart type or something similar that has unique begining and
> end properties of a video resource.  Then nmm:performanceOf could be
> used as a property of nmm:VideoPart.
>

I don't think in this part but sounds interesting because you could search
for videos related to a music piece even in a full concert DVD.

>
> I think that would cover most of the basic semantics and allow the
> userspace semantics (titling, tagging, etc.) handle the rest.  My
> reluctance to introducing new types comes down to this: If the new
> type doesn't have a bunch of unique properties then there really isn't
> much semantics being introduced and the new type is little more than a
> tag - which is just as searchable, groupable and far more flexible.
> While I'm not a huge fan of pushing stuff up to the userspace, it has
> value in that it keeps the core ontology relatively stable (a blessing
> for app developers).  It also provides a great deal of flexibility by
> allowing new use-cases to emerge.  My view has been to first try
> solving the problem with tags for a while and then if/when a
> consistent pattern starts to emerge, then we can talk about if it
> makes sense to update the ontology.
>
> Anyway, that's how I'm seeing it from the Bangarang side.  Hope this
> is helpful and please feel free to throw stones in this general
> direction. :-)
>
> peace and much respect,
> Andrew
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>

As this discussions is really interesting I suggest other point to discuss,
the nmm:MusicAlbum. I think there are three main problems here:

   1. Cover: Nepomuk looks for a cover.* file in the music album folder but
   extract that information from Nepomuk will be a better solution. The
   solution used with TV series seems valid here.
   2. Performer: actually there is no method to obtain an album performer
   except reading performer's tracks. This is a problem with a collaborations
   albums where performer tracks has more than one performer. Amarok has a
   manual method to select if an album is a "various artist" or not and I
   think this is a good solution.
   3. Multidisc albums: there is a problem managing total tracks in this
   case, we need a method to store total tracks and total tracks per disc.

And the same discussed to link music tracks with videos must be apply here
because there is music album releases with an associated DVD or BluRay.


-- 
Best wishes,
Ignacio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20120326/b7ef216e/attachment-0001.html>