[Xesam] dumping NID3/NEXIF for NMM

Tue Jun 16 01:42:15 PDT 2009

Hi,

Yeah, feeling much better today, thanks Leo!

> Hi Urho,
>
> thanks for the flamy mail and being open.
> I hope you get to laugh at least once today!
>   
I sure hope so!
> I joyfully switch to a flaming answer, you haven't seen me flaming yet....
>   
Well, some flames every now and then are hopefully good. Let's just keep 
the flames modest and we'll probably burn the issues more quickly.
> I would say we agree that we continue to maintain both NID3, NEXIF, take 
> up NMM into the xesam/oscaf standardization track now, and we can give 
> feedback about NMM.
> Once all of us (not only you) clearly see that NMM is better than NID3 
> and NEXIF, we can think about dropping something.
>   
Sure, it needs to be common understanding, so bringing issues to the 
open is very important.
> I want to shed some light on the details of NID3 or NEXIF, I think your 
> arguments would be different if you knew them.
> NID3 is integrated with NCO - the artists are represented as contacts - 
> so they ARE integrated with the "semantic desktop".
> also Evgeny contributed to them, so saying "they would better never have 
> existed" is saying that we wasted our time, which I think we did not :-)
>   
I know Evgeny contributed to them, but also know that he wanted to do 
the things differently. You can see his approach in the xesam ontology.
http://www.xesam.org/main/XesamOntology95

What I did, was, I combined the ontologies and reshaped them into a less 
plain structure.

> we took standards that worked very well for the it industry for the last 
> years, this is the common process when designing an ontology: look for 
> existing standards and copy them.
>   
Which is not always the right choice. This is also obvious in the 
calendar ontology. You guys took the specs of ical too literally. Ivan 
is working on a proposal that drops all of the union classes and 
replaces them with a single superclass, which makes the ncal a nice and 
clean structure. I mean, ncal is for the most part really nice, but the 
drive to copy the ical exactly lead to those horrible union classes.

> Look, even the W3C people did  base their calendar ontology on the vCal 
> standard, do not shoot at this approach, it is a good one. Consider the 
> time it took to make MPEG7 (by the way, you may think about porting that 
> one to an ontology, at least partly, instead of rolling your own) - we 
> did consider this and say: invest time into what we need, not endless 
> standardization discussions that others did before you.
>   
Sure. And mpeg7 is also a very nice example on how nid3 is not a good idea.

Ok, let me put it this way, we can support tens of different 'copy' 
ontologies, as long as we also provide an abstraction ontology that 
makes the use of the data easy. Think about it. mpeg7 will have totally 
different names for the same fields that are in nid3, ogg ontology would 
also have different names and so forth. Now, for a media player, you 
have additional libraries (e.g. gstreamer) that handle the hassle of 
playback for you. You don't need to care about the format at all. Now, 
when you are showing the available music on an application window, you 
don't want to query for the metadata from different ontologies. You want 
one, that combines the most common features of various audio file types, 
various video file types and various image file types.

I was proposing much more detailed ontology previously, but Evgeny 
convinced me to drop as many properties as possible.

> It was a well-thought and good decision to start with something
> * simple
> * that works
> we looked at all the alternatives, and if we would have done as you say 
> (start from scratch) -  would have failed within the small 11mio eur 
> budget we had. (well, you get the idea...)
>   
Well, making a copy of id3 v 2 ontology should take one weekend at most.
> we have running code now in aperture.sf.net. it works. its fine.
>   

> we expected that someone would come later and fix our decision - so YES 
> - its good - we need to have NMM, but I want to see it working first 
> before I dump the existing stuff.
>   
Sure, we can keep the nid3, I have really nothing against keeping 
deprecated ontologies in repositories.
> we are talking about money here to change aperture, it will take some 
> time of our users to swallow this and I am not going to stand up the 
> heat of our existing userbase if I am not fully convinced of a new ontology.
>
>   
Well, you can keep the support of the old ontology as well.
> note: you never showed us NMM, so this time, I can happily flame back 
> and like to switch to the language I would use between gunnar and me in 
> our office:
> show your assets or shut ... .... up.
>
> googling for NMM, I find is this draft:
> http://xesam.org/main/Hackfest2008/nmm
> is this NMM?
>   
Well, this is the current git link:
http://git.gnome.org/cgit/tracker/tree/data/ontologies/38-nmm.ontology

> be precise, it has a good reason that the namespace is also the HTTP 
> address where I can download the ontology using HTTP to validate it.
> (the draft does not even mention where I can get the ontology via HTTP....)
>   
As you have read, the point of that page is to design the ontology. Once 
we agree that it's final, then we put it to proper location.
> currently you propose to rewrite aperture.sf.net with an ontology I 
> can't quite grasp, sorry, but this is not the way you are going to 
> convince me. This is also why the OSCAF part of our work is here: to 
> help establish a good documentation of what happens.
>   
I'm not proposing to do anything for a specific application. I'm saying 
that NID3 is a bad ontology and NMM is the way forward. NMM is not ready 
yet, but it should be polished together with the community.

> best and hope that your day is getting better,
> mine was just wasted by  a leaking roof and water in unpleasant places 
> of our flat,
> and the flat below, and soon: the flat below that....
>   
Oh my god. I'm terribly sorry to hear that. I hope the insurance handles 
any inconveniences for you and your family.

Peace ya all,
Urho

> Leo
>
> It was Urho Konttori who said at the right time 15.06.2009 15:59 the 
> following words:
>   
>> ext Leo Sauermann wrote:
>>     
>>> It was Urho Konttori who said at the right time 09.06.2009 10:17 the 
>>> following words:
>>>  
>>>       
>>>> I can be maintainer of NMM once we agree to include that in the 
>>>> official ontologies (and drop the NID3 and possibly even NEXIF while 
>>>> doing so). Also, by replacing the nid3, and nexif, we have 1 less 
>>>> ontology to get a maintainer for ;).
>>>>
>>>> Pros:
>>>> I designed that together with Evgeny Egorochkin and Mikael Ottela.
>>>> NMM is still not completely sanity tested and may still need quite a 
>>>> few changes, so I would be a good person to do that.
>>>>
>>>> Cons:
>>>> Quite busy until next autumn.
>>>>       
>>>>         
>>> I oppose to drop NID3 and NEXIF - they are quite sanity tested and 
>>> good because - they just copy ID3 and exif, two accepted industry 
>>> standards.   
>>>       
>> And how does NID3 handle WMA files? How about m4a files? how about ogg?
>>
>> It's really bad idea to start having format specific ontologies. It's 
>> like saying that we have a 'outlook' ontology and it should be fine 
>> for all 'outlook' type of apps, instead of having a messaging ontology.
>>
>>     
>>> If NMM is not finished and you have no time to improve it, we would 
>>> lose compabiltiy with aperture and the existing code when using NMM.
>>>   
>>>       
>> Well, NMM will be finished pretty soon. And cry me a river if someone 
>> looses support of a ontology that should never have existed.
>>
>>
>>     
>>> Once NMM can cover all that NID3 and NEXIF cover and is "sanity 
>>> proofed", we can discuss replacing NID3 and NEXIF, until then, I 
>>> would keep promoting that we maintin NID3 and NEXIF and fix bugs there.
>>>   
>>>       
>> There is also no need to cover all. EXIF is just wonderful format, but 
>> it is intended mostly to be used during opening of the particular 
>> image file so that barrel distortion, lens effects, lighting and so 
>> forth can be nicely corrected by software. Most of it is not intended 
>> for categorization/searching type of cases. Thus, NMM has much smaller 
>> subset of it. It also has the support for a subset of XMP, which is 
>> essentially suffering from the same problem. I agree that the image 
>> side will probably be need to be extended, but it's much better to 
>> have a subset that is definitely needed than a format that offers tons 
>> of unnecessary fields. The same applies to NID3, just in a smaller scale.
>>
>> Also, whereas nid3 is just a copy of the id3 to an ontology format, 
>> NMM has been designed for semantic desktop use.
>>
>>     
>>> Once both are fine, we can make a decision to drop one and 
>>> communicate it. Note that dropping something (=making someone elses 
>>> code break which was fine before) is usually something hated by 
>>> everyone in the process (=because you force people to invest into 
>>> something they could have for free if the change did not happen), so 
>>> I would not do this lightheartedly.
>>>   
>>>       
>> Sure, we can keep those alive and just say that they have been 
>> superceeded by NMM, please move over there. It's totally fine way of 
>> keeping the support and moving on.
>>     
>>> but good, we need more ontologies, I wrote you down as maintainer of NMM
>>>   
>>>       
>> Thanks!
>>
>> And sorry about the flamy email. This really has not been one of my 
>> better days and I do apologise for letting it show.
>>
>> Kind regards,
>> Urho
>>
>>
>>     
>>> best
>>> Leo
>>>
>>>  
>>>       
>>>> Kind regards,
>>>> Urho
>>>>
>>>> _______________________________________________
>>>> Xesam mailing list
>>>> Xesam at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/xesam
>>>>
>>>>       
>>>>         
>>>   
>>>       
>
>
>   