the advantage of the 5 classes is that no double-typing is needed. Thus, usage is simpler and more convenient. Also imho it is cleaner. From a usage point of view I see no problem in the additional classes.
On 04/04/2012 09:10 PM, Andrew Lake wrote: > 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 <[email protected]> >>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>> 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 >> >> > _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
