2007/5/2, Evgeny Egorochkin <<a href="mailto:phreedom.stdin@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">phreedom.stdin@gmail.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Wednesday 02 May 2007 21:59:15 Mikkel Kamstrup Erlandsen wrote: > 2007/5/2, Evgeny Egorochkin <<a href="mailto:phreedom.stdin@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> phreedom.stdin@gmail.com</a>>: > > On Wednesday 02 May 2007 15:46:15 jamie wrote: > > > On Wed, 2007-05-02 at 14:13 +0200, Sebastian Trüg wrote: > > > > Hmm, so now you ignore RDF? > > > > Don't get me wrong, it is your project, so in the end it is your > > > > decision. I am just a little confused why we have this wiki page > > > > then. > > : > > :) > > : > > > Im too busy (until mid-may) to comment on the spec in much detail > > > > > > perhaps we can arrange an online discussion mid may to flesh this all > > > out > > > > > > I have a few concerns with the nature of the proposed desktop file > > > spec. > > > > > > I agree its important the desktop file should be easily convertible to > > > rdf but we do want to eliminate the complexity (and extra overhead of > > > rdf) as much as possible from it - that is the point of having the > > > desktop file. > > > > I think still this compexity issue is not an issue at all. The reason I > > think > > so is: > > 1) most of metametadata definitions will be provided by Xesam > > 2) code to parse this in the database will be written only once > > 3) If a dev needs an exotic field, somebody can help. It's not much of > > work. > > Don't underestimate where newcomer devs poke around. I clearly remember > myself a good while back poking around with some fancy gnome-vfs code, some > objects read as .desktop files, and even if I didn't know anything about > those at that time I could readily work with them. Who knows - if that had > been some obscure format (sorry I don't mean that rdf is obscure :-)) I > might have stopped there and might not have been here today... > > So even if most apps will use a helper lib don't forget that we should also > make it easy for people to poke around. Didn't we all start that way? There are RDF formats that are extremely newcomer-friendly. Nobody today complains when they see XML which looks no way better and nobody raises any "complexity" issues whenever XML is suggested as a representation. I don't see how RDF is worse in this aspect. Its representation is text-based and meta-meta spec except regexps can be figured out from just a couple example definitions. Newcomers are not dumb by any means.</blockquote><div> Oh,  I for sure complain about complex XML formats and believe me, many do. Take for instance XML Schema (just for one) do you know and appreciate the *full* spec? </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> So what is more important is flexibility, extensibility and compatibility. > > > Don't the .desktop-approach have that? Flexibility, no. There are many things which RDF and XML can do and .desktop can't.</blockquote><div> Yes, of course RDF can do a lot more that is the whole point :-) But can it do anything we need that we cannot do with .desktop files? I think it would be good to have some concrete cases of .desktop vs RDF approach (with different RDF syntaxes possibly). Also it would be useful to track down some concrete cases of what RDF could do that .desktop can't... </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Extensibility follows from flexibility. RDF has nice extras which we may want to use in the future. Compatibility. Do you have a tool to visualize ontology built using .desktop files? Do you have GUI editors?</blockquote><div> It should be pretty easy to write a tool to visualize the structure of the current proposal. GUI editors - if you mean syntax highlighting then yes.  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It might seem far-fetched, but it isn't so. The ontology is likely to contain ~100 fields. No less. And will grow. Maintaining it, and especially child/parent field relation gets really complex. I can feel it myself already being responsible for Strigi ontology. It is also useful for other devs in deciding which fields to use and understanding the consequences and implications. Visualization is a great help here, including those newcomers whom it'd help to grasp the ontology.</blockquote><div> Visualization could be a great help, yes. I could write a tool for that in an afternoon with Python and Cairo. It could do well in the xesam-tools package I'm writing atm. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> GUI editor is also a plus. I'm sure the spec will be getting more and more elaborate with more features added. Having some editor for all this mess is really handy, newcomers included. > Also, it is important to act fast, otherwise the goal of compatibility is > > > unattainable since much of the code gets written around metadata spec. > > Analyzers are written to extract data and feed in to the indexer in a > > specific > > format. It becomes a real problem if our projects do this in a different > > way. > > 100% right. This is a problem that is hard to address. The only solution is > just to not despair and just keep the train rolling, panic solutions are > deemed to end up disastrous at some point. I'm not offering a "panic" solution. Still such delays like till 14th and the preceding silence really bothers me and Strigi devs in general.</blockquote><div> Sorry, I didn't mean to say that you offered a panic solution. I just meant that we shouldn't rush things through... </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">There's already pressure to have something well-defined. You can extract meta-data from files just fine, but in what form to feed it to the index? I can only guess at this moment and if I guess wrong it means some dev has to spend considerable time doing corrections. By 14th I expect a significant drag on Strigi due to complete absense of the standard. Also, I don't think project leaders absolutely must get directly involved. They can delegate technical negotiations to their team members and only look at "snapshots" of the negotiations & provide feedback on key issues.</blockquote><div> Right. So project leaders, please consider sending stand-ins if you are caught in a tight spot. I just wonder - who am I gonna send :-) </div> Cheers, Mikkel </div>