2007/6/5, 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 Tuesday 05 June 2007 02:18:21 Mikkel Kamstrup Erlandsen wrote:<br>&gt; 2007/6/5, Evgeny Egorochkin &lt;<a href="mailto:phreedom.stdin@gmail.com">phreedom.stdin@gmail.com</a>&gt;:<br>&gt; &gt; On Tuesday 05 June 2007 00:25:45 Mikkel Kamstrup Erlandsen wrote:
<br>&gt; &gt; &gt; 2007/5/30, Evgeny Egorochkin &lt;<a href="mailto:phreedom.stdin@gmail.com">phreedom.stdin@gmail.com</a>&gt;:<br>&gt; &gt; &gt; &gt; Hi all,<br>&gt; &gt; &gt; &gt;<br>&gt; &gt; &gt; &gt; I&#39;d like you to take a look at the ontology sketch
<br>&gt; &gt;<br>&gt; &gt; <a href="http://www.freedesktop.org/wiki/PhreedomDraft?action=AttachFile&amp;do=view&amp;t">http://www.freedesktop.org/wiki/PhreedomDraft?action=AttachFile&amp;do=view&amp;t</a><br>&gt; &gt;<br>
&gt; &gt; &gt; &gt;arget=viz.png<br>&gt; &gt; &gt; &gt;<br>&gt; &gt; &gt; &gt; It&#39;s not complete. Some fields/classes are dropped intentionally.<br>&gt; &gt; &gt; &gt; I&#39;d like to hear some feedback first.<br>&gt; &gt; &gt; &gt;
<br>&gt; &gt; &gt; &gt; Points of interest:<br>&gt; &gt; &gt; &gt; *** Sources<br>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *Source hierarchy<br>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; *Which properties belong to content and which to source?<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; I was just&nbsp;&nbsp;scanning through<br>&gt; &gt; &gt; <a href="http://www.dfki.uni-kl.de/~mylka/nie.pdf">http://www.dfki.uni-kl.de/~mylka/nie.pdf</a>&lt;<br>&gt; &gt;<br>&gt; &gt; <a href="http://www.dfki.uni-kl.de/%7Emylka">
http://www.dfki.uni-kl.de/%7Emylka</a><br>&gt; &gt;<br>&gt; &gt; &gt;/nie.pdf&gt;. As far as I can read in Nepomuk DataSource does not derive<br>&gt; &gt;<br>&gt; &gt; from<br>&gt; &gt;<br>&gt; &gt; &gt; DataObject. Also it states that a DataObject is something where you can
<br>&gt; &gt; &gt; physically retrieve some bytes in some way or other. Taking this into<br>&gt; &gt; &gt; account I don&#39;t think it makes sense to let User derive from DataObject<br>&gt; &gt; &gt; either.<br>&gt; &gt; &gt;
<br>&gt; &gt; &gt; Personally I would prefer to have a field Category and a field Source,<br>&gt; &gt;<br>&gt; &gt; but<br>&gt; &gt;<br>&gt; &gt; &gt; I know from IRC that this will cause trouble in some implementations,<br>
&gt; &gt;<br>&gt; &gt; but I<br>&gt; &gt;<br>&gt; &gt; &gt; would like to have this stuff discussed on-the-record so to speak; so<br>&gt; &gt; &gt; please chime in with your concerns regarding this.<br>&gt; &gt;<br>&gt; &gt; Nepomuks DataSource is absolutely different from Xesam sources.
<br>&gt;<br>&gt; Unless that document is horribly outdated I can&#39;t se how. A DataSource<br>&gt; designates the origin of some DataObject if I&#39;m not mistaken. This was also<br>&gt; the idea behind xesam sources.<br>
&gt;<br>&gt; They might differ on the technical level but the idea behind them seems the<br>&gt; same, or is there something i miss?<br><br>AFAIK DataSource was intended to store properties of specific data<br>storage/extraction plug-ins. Usually many files will point to a single
<br>DataSource object.<br><br>In xesam Sources approach lets us assign and expect source-specific properties<br>to files like compressedSize and compressionAlgo for archive contents or<br>attachment encoding type(base64 etc) for email attachments.
<br><br>That is by knowing the source type, we know what fields to expect, besides the<br>fact that explicit source type knowledge is useful as-is for presentation to<br>the user.<br><br>The more sources and the more exotic sources we have, the more benefits we get
<br>from structuring the source hierarchy and source-specific fields. Not going<br>to repeat the long list of benefits of structuring the ontology I posted when<br>we discussed explicit category-field bindings.<br><br>We get these benefits with absolutely no extra overhead implementation-,
<br>storage-, performance-wise.<br><br>For example, local copy and content creation dates belong to Source and<br>Content respectively, while in NIE both belong to DataObject.</blockquote><div><br>Ah, ok, I see how they differ in concepts, but they are still quite related. In Nepo a DataSource contains the information about the source in xesam it would contain what the source of an actual object is.
<br><br>I was not trying to imply that a Source shouldn&#39;t be able to imply which fields are available on a given object. Just that I would like a field Category and a field Source that both imply a set of fields. I think we might agree to a great extend :-)
<br></div><br></div>Cheers,<br>Mikkel<br>