[Nepomuk] OSCAF and music live and videoclips

[Sebastian Trüg]

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.

> 
>     > 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.

> 
> 
>     > 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.

> 
>     > 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