Xesam meta-meta-data spec needs attention.
phreedom.stdin at gmail.com
Fri May 4 14:00:28 EEST 2007
On Thursday 03 May 2007 10:42:49 Mikkel Kamstrup Erlandsen wrote:
> > > > 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?
This is an incorrect comparison. Xesam provides what would be an equivalent of
XML Schema. Regular devs only do fill-in the blanks job on a simple template
with a human-readable doc and examples.
Nobody really have exaustive knowledge of any reasonably complex standards
just like no dev(even highly skilled) knows the libraries he's using.
> > 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...
.desktop doesn't allow classes for files. This can be replaced to a degree by
file:types. e.g. [compressed, lossless, audio] or [document,text,source code]
Missing are structures. As soon as we go further than generic metadata like
author and size, and try to extract document structure, we'll run into
troubles. An example: c++ sources with nested classes and their members. Too
many workarounds would be necessary for .desktop
I do realise that the first revision of xesam spec is not likely to go that
far. Nevertheless, I expect to hit .desktop limitations quite soon and don't
find it reasonable to reinvent the wheel(visualisation etc).
btw, is there any way to provide for localization in Notation-3 or Turtle RDF?
I can't seem to find any. The advantage of these syntaxes is that they are as
clean as .dekstop while remaning a fully-featured RDF syntax.
It could look like this:
> > 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 :-)
You are doing just fine at this moment :)
More information about the xdg