[Xesam] dumping NID3/NEXIF for NMM

[Evgeny Egorochkin]

On 16 июня 2009 16:48:45 Antoni Mylka wrote:
[snip]

> Could you please write a more detailed explanation of what you think is
> "bad" with NID3. I would imagine something along the lines of [1]. And
> why is it better to do the same stuff with NMM rather than adding some
> classes/properties to NID3.
>
> In my experience it's easier to discuss use cases like
> - it's possible/impossible to express this/that
> - this/that can be expressed in more than one way which may lead to
> inconsistencies
> - having data expressed with this ontology it is possible/impossible to
> implement this/that functionality
> - this/that is a plain typo in the rdfs file with the ontology
> - this/that part of the documentation is misleading

Some of specific issues are documented in my recent email and on the draft 
page.

> It's difficult to discuss aesthetics.

In our cases aesthetics are about sanity, extensibility, functionality, 
efficiency etc ;)

> Also note that it will be difficult to keep things stable once we start
> adding classes like "Song", "Artist", "Movie" etc. Originally NIE was
> about things that can be directly extracted from the bits/bytes without
> any heuristics/NLP/image understanding/speech recognition etc.

The difference between Audio class and Music class is that not all music is 
strictly an audio stream and audio stream can be eg a podcast or something. So 
this separation does make sense. How to implement it is another matter.
As to heuristics, there are lots of very unambiguous ways to identify content 
such as CDDB, MusicBrainz.

> In Nepomuk this assumption defined the scope of NIE and the border
> between NIE and NAO/PIMO. I'm not saying that this dogma is to be upheld
> at all cost, but keeping it will keep the development focused. Otherwise
> we will have to solve issues whether an avi file with the Madonna's
> "Frozen" clip is a movie, or whether an mp3 with the recording of the
> Great B-Minor Mass can be called a "Song". At least I'd suggest to keep
> "Song" and "AudioTrack" in separate ontologies.

But this is exactly what we intended. We wanted to move all technical stuff 
such as pixel format into NFO, and implement separate Photo, Music etc classes 
to store composers, exposure settings and similar data. Someone else might 
want to add eg Painting class but it's none of our concern because we capture 
the stuff essential to us using NIE/NFO.

> I'll try to take a closer look at the NMM git url you've given and
> return with some more focused feedback.

I'm afraid it's not in shape yet, but the ideas and issues are spelled out 
quite clearly already.


-- Evgeny