[Nepomuk] OSCAF and music live and videoclips

Ignacio Serantes kde at aynoa.net
Thu Mar 22 20:29:49 UTC 2012


Hi,

On Thu, Mar 22, 2012 at 6:59 PM, Sebastian Trüg <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.

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


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

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.


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

I don't know this ontology.


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

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.

>
> sure they are. We can always add stuff that makes sense. :)
>
> Cheers,
> Sebastian
>
> _______________________________________________
> 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/20120322/51135da2/attachment.html>


More information about the Nepomuk mailing list