[Nepomuk] OSCAF and music live and videoclips

Ignacio Serantes kde at aynoa.net
Mon Mar 26 09:06:39 UTC 2012 

On Fri, Mar 23, 2012 at 7:56 AM, Sebastian Trüg <sebastian at trueg.de> wrote:

> On 03/22/2012 09:29 PM, Ignacio Serantes wrote:
> > Hi,
> >
> > On Thu, Mar 22, 2012 at 6:59 PM, Sebastian Trüg <sebastian at trueg.de
> > <mailto:sebastian at trueg.de>> wrote:
> >
> >     On 03/22/2012 02:24 PM, Ignacio Serantes wrote:
> >     > Hi,
> >     >
> >     > I want to add to Nepomuk information from my library of music
> videos,
> >     > lives and concerts and I wonder how I could do this.
> >     >
> >     > This is the basic information for a music video stored in the file
> >     name:
> >     > [MV] Artist(s) - Song(s) (year).ext
> >     >
> >     > so next relations are required:
> >     > nmm:performer (1-n)
> >
> >     that we already have. but I suppose it would go on the actual
> >     nmm:MusicPiece
> >
> >
> > I don't think so because this music video could be a cover, or even a
> > parody, or maybe there is more than one version, and I talking about
> > cases I known and maybe there are others, so music video performer could
> > not be the same of the music piece.
>
> What I meant here is that the property would be attached to a
> nmm:MusicPiece instance which in turn would be linked from the video
> instance.
>
> Seems valid.


> >
> >     > nmm:musicPiece (1-n)
> >
> >     I imagine this would like a nmm:MusicPiece to the nmm:MusicVideo.
> Then I
> >     think it should be a subPropertyOf nie:hasLogicalPart.
> >
> >
> > I don't like so much the subProperty idea because I will need a join to
> > get data. With nmm:musicPiece I can build a query with a relation.
>
> I do not follow here. There is no difference as far as the query is
> concerned. The ontology would simply be cleaner and more correct.
>
>
You right, I don't understood you.


>  >
> >
> >     > and the next properties:
> >     > nie:contentCreated
> >
> >     that we have
> >
> >     > extra information, like album title, could be retrieved or stored
> >     > following nmm:performer or nmm:musicPiece. I don't know if there
> is a
> >     > music video with more than a song but there is no problem to have
> a n
> >     > cardinality.
> >     >
> >     > This is the basic information for a music live stored in the file
> >     name:
> >     > [LIVE] Artist(s) - Song(s) - Program - Date.ext
> >     >
> >     > so next relations are required:
> >     > nmm:performer (1-n)
> >     > nmm:musicPiece (1-n)
> >
> >     the same as above I suppose.
> >
> >     > nmm:tvshow (1-1)
> >
> >     why tvshow?
> >
> >
> >
> >     > extra information, like emission date must be stored in a
> nmm:TVShow
> >     > resource and a nmm:TVSeries resource must be created to.
> >
> >     what does live music have to do with tv shows?
> >
> >
> > Because music lives are performed in one place, basically in tv shows.
> > All of my lives are related to tv shows or are full concerts.
>
> Well, that is another thing then which I would model as the music video
> being part of the tv show, ideally with offsets.
>
> > This is an example live performed in South Korean show named Music
> > Core, http://www.youtube.com/watch?v=4CYiR8yt7-w, and I have over 700 of
> > this in my hard drive from this and other shows.
> >
> >
> >
> >     What you would do is introduce a new type nmm:LiveMusicVideo or
> >     something like that as a subclass of nfo:Video.
> >
> >     > This is the basic information for a concert stored in the file
> name:
> >     > [CONCERT] Artist(s) - Song(s) - Place - Date.ext
> >     >
> >     > nmm:performer (1-n)
> >     > nmm:musicPiece (1-n)
> >     >
> >     > and the next properties:
> >     > nie:contentCreated
> >     >
> >     > and in this case I need a property to store the location and maybe
> >     more
> >     > things, I have over ten concerts so I have not thought much about
> >     this :).
> >
> >     Should be fairly simple to add. Maybe it would make sense to again
> >     introduce a new sub-type to nmm:MusicPiece to differentiate between
> >     "normal" music files and concerts. The same is probably true for live
> >     recordings (without video).
> >
> >
> > This is related with covers and parodies and I think that this could be
> > easily solved with the genres like in audio files.
>
> genre is a very bad concept as it uses strings and is not semantic at
> all. Thus, sub-types are the solution.
>
> Yes, but it's simple and it's the method used actually in music files,
movies and tvshows. On the other side you can compare this information with
the information in the music files because are in the same domain. If you
use sub-types with music videos you need to translate this to music files.
Your suggestion is conceptually good but had a high cost because you need
to change many things, the basic one the all strigi indexers.


> >
> >     > There is other information relevant to me stored actually in tags,
> >     like
> >     > if performance is a cover or a special version or the country, but
> >     lets
> >     > begin with the basic.
> >
> >     interesting. Might make sense to look at the last.fm
> >     <http://last.fm> ontology here.
> >
> >
> > I don't know this ontology.
>
> I will have a look later.
>
> >
> >
> >     > The fact is seems like I need something like nmm:MusicLive,
> >     > nmm:MusicVideo and nmm:MusicConcert ontologies and I'm not sure if
> >     this
> >     > changes are possible.
> >
> >
> > So you suggest nmm:LiveMusicVideo and not nmm:MusicLive. Following this
> > logic proper names will be:
>
> Well, actually both since you can also have recordings of live music
> without video.
>
> > 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?
>
> Cheers,
> Sebastian
>
> >
> >     sure they are. We can always add stuff that makes sense. :)
> >
> >     Cheers,
> >     Sebastian
> >
> >     _______________________________________________
> >     Nepomuk mailing list
> >     Nepomuk at kde.org <mailto:Nepomuk at kde.org>
> >     https://mail.kde.org/mailman/listinfo/nepomuk
> >
> >
> >
> >
> > --
> > Best wishes,
> > Ignacio
> >
> >
> >
> >
> > _______________________________________________
> > Nepomuk mailing list
> > Nepomuk at kde.org
> > https://mail.kde.org/mailman/listinfo/nepomuk
> _______________________________________________
> 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/20120326/4693d165/attachment.html>

More information about the Nepomuk mailing list