Xesam meta-meta-data spec needs attention.

[Mikkel Kamstrup Erlandsen]

2007/5/4, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
>
> On Friday 04 May 2007 14:31:21 jamie wrote:
> > On Fri, 2007-05-04 at 14:00 +0300, Evgeny Egorochkin wrote:
> > > 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
> >
> > this is doable (we do support this in tracker and plan on adding support
> > to desktop files for this)
> >
> > You would have a metadata type of struct
> > and have another field "children" that lists the child metadata names
> >
> > Each child metadata will have its own def
> >
> > Eg  for a struct type for Email:Address containg Contact:Name and
> > Contact:Email you would have:
> >
> >
> > [Contact:Name]
> > DisplayName=Contact:Name
> > Type=string
> >
> > [Contact:Email]
> > DisplayName=Contact:Email
> > Type=string
> >
> > [Email:Address]
> > DisplayName=Email:Address
> > Type=struct
> > Children=Contact:Name;Contact:Email;
>
> This apparently solves the storage issue for this particular case.
> However,
> there are several shortcomings:
> 1) Structures are not extensible.
>         *You cannot define generic structure for an OO language and
> subclass it if
> necessary.
>         *Applications can't add custom fields to existing structures.
> 2) Data retrieval.
> If you put the whole structure in a single property, you make it hard e.g.
> to
> use several  files to describe a single structure. Also, it is hard to
> interlink classes e.g. point to ancestor class(es).



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

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.


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

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.


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