[Nepomuk] OSCAF and music live and videoclips

[Andrew Lake]

On Fri, Mar 23, 2012 at 11:58 AM, Sebastian Trüg <trueg at kde.org> wrote:
> On 03/23/2012 05:48 PM, Andrew Lake wrote:
>> So these videos are basically performances of a particular MusicPiece.
>> Hmm, what about a property sort of like nmm:performanceOf ?  So any
>> nfo:Video could be a performance of a particular nmm:MusicPiece.  You
>> might even be able to link different nmm:MusicPiece or even nfo:Audio
>> in the same way. So maybe a domain of nfo:Media?
>
> nfo:Media's comment refers to audio and visual content. In fact a video
> could also be a performance of a play, ie. a piece of literature. So we
> could go a little wider here or widen the scope of nfo:Media to written
> media.
> ...
>
> Following my line of thinking above having a performer on a book does
> not make much sense. But your point is still valid so maybe we need
> another intermediate class which groups audio, visual, and written
> media. Hm, and what about paintings?

Hmm... I wonder if the domain could just be nfo:Media but the range be
something that covers multiple art forms. Just a thought. I'm pretty
open to either expanding nfo:Media or defining a new intermediate
class (though the former might be a little less disruptive).

>
>> For a portion of a video (tvshow, concert, etc.) that has the
>> performance of a particular music piece, I could see value in a
>> nmm:VideoPart type or something similar that has unique begining and
>> end properties of a video resource.  Then nmm:performanceOf could be
>> used as a property of nmm:VideoPart.
>
> AFAICR that is pretty much the original idea. The part would be
> nie:partOf the original video and its nie:DataObject type something
> embedded. So I am all for this.

Cool.

>
>> I think that would cover most of the basic semantics and allow the
>> userspace semantics (titling, tagging, etc.) handle the rest.  My
>> reluctance to introducing new types comes down to this: If the new
>> type doesn't have a bunch of unique properties then there really isn't
>> much semantics being introduced and the new type is little more than a
>> tag - which is just as searchable, groupable and far more flexible.
>
> But way less semantic'ish. :P
>
> ...
> In fact I am not a fan of tags at all. Their performance is waaaay worse
> than types, there is no hierarchy, and no way to perform any inference.

Well it's kind of a trade off I think.  For subtypes with no unique
properties that are all one level below from the supertype, I'm not
sure I see a great deal of benefit. Absent these subtypes in the
ontology, the resources would still be set to the (super)type so
there's no loss of benefit from type inference.  Any other inferential
benefit in terms of distinction and equality is just as easily served
by value inference (or value inference paired with type inference
available using the existing ontology). However, I certainly agree
that once you introduce unique subtype properties or get much beyond
one level below the supertype, tags are almost immediately
insufficient.

The trade-off from an application design/development perspective
(well, at least from my perspective) is that we need relatively stable
ontologies for interoperability and to keep features working across
releases (of both app and platform). Additionally, whether these
one-level-down-with-no-unique-property subtypes are implemented using
tags or sub-classes don't look a great deal different to the user: All
that matters to the user is that there is some subset of a type that
share something in common.  Whereas I can design for tags once, I have
to design for types every time a new type emerges or changes.  So for
these one-level-down-with-no-unique-property subtypes, it's a lot of
work for not a lot of measurable benefit to the user.

Additionally, each user may maintain their own conception for how
their data is meaningful to them.  That conception may even change
over time.  Tags, however inadequate, provide for some level of
natural "ontology development" that can only occur at run-time, not at
design-time.

Once I see some unique properties or a type hierarchy more than
one-level deep, it'll certainly be clearer to me what the semantic
benefits are over tags.

>
>
> This is a fun discussion as I like both topics: media and ontologies.

Indeed! :-)

Gather your stones and let 'em hurl.  Nah seriously,

Peace and much respect,
Andrew