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
