Xesam meta-meta-data spec needs attention.

Thu May 3 10:42:49 EEST 2007

2007/5/2, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
>
> On Wednesday 02 May 2007 21:59:15 Mikkel Kamstrup Erlandsen wrote:
> > 2007/5/2, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
> > > 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.

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?

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

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

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?

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.

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.

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.

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.

Sorry, I didn't mean to say that you offered a panic solution. I just meant
that we shouldn't rush things through...

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.

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

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070503/b4ed2af3/attachment.htm 