2007/5/4, Evgeny Egorochkin <[EMAIL PROTECTED]>:
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
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
