2007/5/4, Evgeny Egorochkin &lt;<a href="mailto:phreedom.stdin@gmail.com">phreedom.stdin@gmail.com</a>&gt;:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Friday 04 May 2007 14:31:21 jamie wrote:<br>&gt; On Fri, 2007-05-04 at 14:00 +0300, Evgeny Egorochkin wrote:<br>&gt; &gt; Missing are structures. As soon as we go further than generic metadata<br>&gt; &gt; like author and size, and try to extract document structure, we&#39;ll run
<br>&gt; &gt; into troubles. An example: c++ sources with nested classes and their<br>&gt; &gt; members. Too many workarounds would be necessary for .desktop<br>&gt;<br>&gt; this is doable (we do support this in tracker and plan on adding support
<br>&gt; to desktop files for this)<br>&gt;<br>&gt; You would have a metadata type of struct<br>&gt; and have another field &quot;children&quot; that lists the child metadata names<br>&gt;<br>&gt; Each child metadata will have its own def
<br>&gt;<br>&gt; Eg&nbsp;&nbsp;for a struct type for Email:Address containg Contact:Name and<br>&gt; Contact:Email you would have:<br>&gt;<br>&gt;<br>&gt; [Contact:Name]<br>&gt; DisplayName=Contact:Name<br>&gt; Type=string<br>&gt;<br>
&gt; [Contact:Email]<br>&gt; DisplayName=Contact:Email<br>&gt; Type=string<br>&gt;<br>&gt; [Email:Address]<br>&gt; DisplayName=Email:Address<br>&gt; Type=struct<br>&gt; Children=Contact:Name;Contact:Email;<br><br>This apparently solves the storage issue for this particular case. However,
<br>there are several shortcomings:<br>1) Structures are not extensible.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*You cannot define generic structure for an OO language and subclass it if<br>necessary.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*Applications can&#39;t add custom fields to existing structures.
<br>2) Data retrieval.<br>If you put the whole structure in a single property, you make it hard e.g. to<br>use several&nbsp;&nbsp;files to describe a single structure. Also, it is hard to<br>interlink classes e.g. point to ancestor class(es).
</blockquote><div><br><br>I think that metadata constructs so complex that they require several files to be described are out of scope for XESAM. We wan&#39;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.
<br>&nbsp;</div>Another thing is that the search spec is not designed to query complex metadata structures anyway.<br><br>I fear that we end up with an over engineered spec if we wan&#39;t to allow arbitrarily complex metadata. Basically I can&#39;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&#39;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).
<br><br>I&#39;m not saying that there aren&#39;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&#39;t that functionality be part of an IDE anyway? I would rarely wan&#39;t to search for argument types of a method from my general desktop search tool.
<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>This is an example of an actual RDF serialization + named graphs<br>extensions(which does support localization as suggested by Sebastian)
<br><br>@Prefix ......................&nbsp;&nbsp;// 1-2 lines copied intact for all files<br>@Base ......................<br><br>Mp3.Title<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;is_a&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;field;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of_type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; string;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;Title&quot;@EN;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // not sure I got intl syntax right from the get go
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;Titel&quot;@NL;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // but likely so<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;description&nbsp;&nbsp;&nbsp;&nbsp; &quot;Mp3 title&quot;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;comment&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;example&quot;.<br><br>Mp3.artist<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;is_a&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;field;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of_type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; string;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;has_parent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Content.Creator<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&quot;Artist&quot;;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;description&nbsp;&nbsp;&nbsp;&nbsp; &quot;Mp3 artist&quot;;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;comment&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;example&quot;.
</blockquote><div><br>Thanks for the example. What is the name of the language you use here? I got lost in the debate somewhere :-) <br></div>It looks simple and clean and I don&#39;t have anything against it as such.<br>
<br>I&#39;m still in favour of .desktop though - the main cause is simply that the .desktop is used everywhere already. Let&#39;s stick to one format I say.<br></div><br><br>Cheers,<br>Mikkel<br>