[Nepomuk] OSCAF and music live and videoclips

Wed Apr 4 11:41:08 UTC 2012

In a second view I have some remarks:

   1. Why nmm:MusicVideo is related to nmm:LiveMusicPerformance? There are
   totally independent without any relation.
   2. nmm:MusicVideo must be related to many nmm:MusicPiece as
   nmm:LiveMusicPerformance. This is a very uncommon case but there is a few
   music video clips related to more than on song.
   3. I'm assuming a 0:n cardinality because I have several live
   performances related to a nmm:MusicPiece I don't own.

On Wed, Apr 4, 2012 at 10:40 AM, Sebastian Trüg <sebastian at trueg.de> wrote:

> Hi guys,
>
> I quickly drew little diagrams trying to summarize again. Please tell me
> what I missed:
>
> 1.png is the example of a concert which is split into live performances
> or certain music pieces. Still missing are the DataObject parts. There
> could be a filedataobject for all of them or only for the concert. in
> the latter case the rest would be embedded data objects or we need
> something new like "part of a dataobject".
> 2.png is the relationship between the classes.
>
> Cheers,
> Sebastian
>
> On 03/26/2012 12:15 PM, Ignacio Serantes wrote:
> >
> >
> > On Fri, Mar 23, 2012 at 5:48 PM, Andrew Lake <jamboarder at gmail.com
> > <mailto:jamboarder at gmail.com>> wrote:
> >
> >     On Thu, Mar 22, 2012 at 11:56 PM, Sebastian Trüg <sebastian at trueg.de
> >     <mailto: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 <mailto: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
> >
> >
> >
> >
> > _______________________________________________
> > Nepomuk mailing list
> > Nepomuk at kde.org
> > https://mail.kde.org/mailman/listinfo/nepomuk
>

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