Xesam meta-meta-data spec needs attention.

[Evgeny Egorochkin]

On Saturday 05 May 2007 01:08:51 Mikkel Kamstrup Erlandsen wrote:

> I think that metadata constructs so complex that they require several files
> to be described are out of scope for XESAM. We wan't to create a common
> interface that everyone can implement. If you suddenly require that the
> implementation support arbitrarily complex RDF structures I think we narrow
> the would-be implementors down quite a bit.
>
> Another thing is that the search spec is not designed to query complex
> metadata structures anyway.
>
> I fear that we end up with an over engineered spec if we wan't to allow
> arbitrarily complex metadata. Basically I can't see the need to build
> metadata structs/classes. Take the example of a Java-file. It could have a
> metadata model where the class has methods and the methods have
> documentation and arguments and so on. It's all great, and you could do all
> sorts of fancy queries against it, but I honestly find it hard to believe
> that it is worth the effort. You can get almost as good functionality with
> the flat field proposal that was put out initially (fields still have
> parents).

The first revision of xesam is unlikely to contain anything complex for the 
reasons you mentioned as well as it'd delay xesam for quite a while.

Our discussion with Jamie was about extensibility/flexibility, a "what-if" 
scenario.

> I'm not saying that there aren't any cases where a complex metadata model
> is of great benefit, but do we need to encumber the whole xesam standard
> with that? I mean with the Java-class example above wouldn't that
> functionality be part of an IDE anyway? I would rarely wan't to search for
> argument types of a method from my general desktop search tool.

Many apps(e.g. Kate) already have search. Why bother? :)
I don't think there's any code browser capable of working with all popular 
languages.  Complex data model benefits apps which in turn benefit users. 
There's little direct benefit though.

> > This is an example of an actual RDF serialization + named graphs
> > extensions(which does support localization as suggested by Sebastian)
> >
> > @Prefix ......................  // 1-2 lines copied intact for all files
> > @Base ......................
> >
> > Mp3.Title
> >         is_a                    field;
> >         of_type         string;
> >         name            "Title"@EN;             // not sure I got intl
> > syntax right from the get go
> >         name            "Titel"@NL;             // but likely so
> >         description     "Mp3 title"
> >         ...
> >         comment         "example".
> >
> > Mp3.artist
> >         is_a                    field;
> >         of_type         string;
> >         has_parent      Content.Creator
> >         name            "Artist";
> >         description     "Mp3 artist";
> >         ...
> >         comment         "example".
>
> Thanks for the example. What is the name of the language you use here? I
> got lost in the debate somewhere :-)
> It looks simple and clean and I don't have anything against it as such.

It's a one of N3(Notation 3) syntax derivatives. You can think of it as 
RDF-XML(RDF minus XML) :)

TriG(http://sites.wiwiss.fu-berlin.de/suhl/bizer/TriG/Spec/) further tweaked 
by creating mappings xsd:integer ->xesam:integer, rdf:property->xesam:field 
etc and making xesam: default namespace
(that's what @prefix and @base are for)

> I'm still in favour of .desktop though - the main cause is simply that the
> .desktop is used everywhere already. Let's stick to one format I say.

I'd say RDF is used everywhere :P