[Nepomuk] OSCAF and music live and videoclips

Andrew Lake jamboarder at gmail.com
Wed Apr 4 19:10:06 UTC 2012


I'm sorry Sebastian. I was clumsy in my response.

Your latest  proposal, as I understand it, includes five additional
clases - nmm:LiveMusicPerformance, nmm:LiveMusicPiece,
nmm:LiveMusicVideo, nmm:ConcertVideo and nmm:MusicVideoVideo.

With nmm:LivePerformance, nmm:Concert and nmm:MusicVideo, along with
multiple-typing, all the benefits I can think of that those five
additional classes provide would be satisfied with just these three
classes.  The example queries I provided was meant to support that
assertion (at least in part).  The point being that I thought the five
classes might not be needed.

Hope this helps,
Andrew

Sebastian Trug wrote:
> you did not really comment on my proposal though...
>
> On 04/04/2012 08:20 PM, Andrew Lake wrote:
>>
>> Yup, double typing is exactly what I had in mind. It cuts down on a
>> proliferation of new classes and more simply reflects what actually
>> happens in the real world - resources on the users computer can be of
>> multiple types (rdf:type has no maxCardinality that I can recall).
>> Applications already have to deal with this possibility.
>>
>> The query would be simple:
>> 1. If the user wants live performances of any type then use:
>>    ?r rdf:type nmm:LivePerformance
>> 2. If the user wants TV show live performances use:
>>    ?r rdf:type nmm:LivePerformance
>>    ?r rdf:type nmm:TVShow
>> 3. If the user wants Music Video live performances use:
>>    ?r rdf:type nmm:LivePerformance
>>    ?r rdf:type nmm:MusicVideo
>> 4. If the user wants Music live performances use:
>>    ?r rdf:type nmm:LivePerformance
>>    ?r rdf:type nmm:MusicPiece
>> 5. if the user wants a concert of any type use:
>>    ?r rdf:type nmm:Concert
>> 6. if the user wants a concert movie use:
>>    ?r rdf:type nmm:Concert
>>    ?r rdf:type nmm:Movie
>> 7. if the user wants a concert TV show use:
>>    ?r rdf:type nmm:Concert
>>    ?r rdf:type nmm:TVShow
>>
>> Even better, if nfo:Media is ever expanded to include new types such
>> as (Books, AudioBooks, Plays, Spoken Word, etc.) this live performance
>> ontology wouldn't need to be updated again.
>> I really think we can get all the benefits we need without introducing
>> media-specific live performance types.
>>
>> Hope this helps,
>> Andrew
>>
>> On Wed, Apr 4, 2012 at 10:49 AM, Sebastian Trüg <sebastian at trueg.de>
>> wrote:
>> > looks very nice indeed. Would you thus propose to double-type live
>> > performance videos with nmm:MusicVideo and nmm:LivePerformance?
>> >
>> > How about the attached layout instead.
>> >
>> > We simply derive the live video and audio from the same live base class.
>> > That way we can easily query all live performances, be it audio or
>> > video.
>> > Also I added an intermediate class nmm:MusicVideo and the badly named
>> > nmm:MusicVideoVideo which is supposed to be typical music videos as you
>> > get from performers for mtv and stuff.
>> > That way we can also easily query for videos that contain music in any
>> > form.
>> >
>> > What do you think?
>> >
>> > Cheers,
>> > Sebastian
>> >
>> > On 04/04/2012 07:26 PM, Andrew Lake wrote:
>> >> nmm:TVShow is a subclass of nfo:Media so yes, it should be okay to do
>> >> that. :-)
>> >>
>> >> peace and much respect,
>> >> Andrew
>> >>
>> >> On Wed, Apr 4, 2012 at 10:23 AM, Ignacio Serantes <kde at aynoa.net>
>> >> wrote:
>> >>> Assuming that nmm:TVShow could be used instead nfo:Media seems good
>> >>> for me
>> >>> :).
>> >>>
>> >>>
>> >>> On Wed, Apr 4, 2012 at 6:36 PM, Andrew Lake <jamboarder at gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> Thanks for taking the time to put this together Sebastian.
>> >>>>
>> >>>> I wonder if it would be possible to push a simpler class
>> >>>> nmm:LivePerformance up above the media type (audio/music/video).
>> >>>> Perhaps just subclassed from nfo:Media, since we could have audio or
>> >>>> video live performances.  Then perhaps we could just add the type to
>> >>>> any existing audio, music, video, tv show, etc. resource to indicate
>> >>>> it is a live performance.  A concert then is just a special type of
>> >>>> live performance that can have multiple live performances. It might
>> >>>> even have unique properties like location, numberOfPerformers,
>> >>>> tourStops, etc.
>> >>>>
>> >>>> Based on what you came up with and Ignacio's comments, I've attached
>> >>>> a
>> >>>> png that captures what I'm thinking might work.
>> >>>>
>> >>>> Hope this helps,
>> >>>> Andrew
>> >>>>
>> >>>> On Wed, Apr 4, 2012 at 4:41 AM, Ignacio Serantes <kde at aynoa.net>
>> >>>> wrote:
>> >>>>> In a second view I have some remarks:
>> >>>>>
>> >>>>> Why nmm:MusicVideo is related to nmm:LiveMusicPerformance? There are
>> >>>>> totally
>> >>>>> independent without any relation.
>> >>>>> 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.
>> >>>>> 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
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Best wishes,
>> >>> Ignacio
>> >>>
>> >>>
>> >>
>
>
>
>
> --
> Best wishes,
> Ignacio
>
>


More information about the Nepomuk mailing list