2007/6/5, Evgeny Egorochkin <<a href="mailto:phreedom.stdin@gmail.com">phreedom.stdin@gmail.com</a>>:<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>> 2007/6/5, Evgeny Egorochkin <<a href="mailto:phreedom.stdin@gmail.com">phreedom.stdin@gmail.com</a>>:<br>> > On Tuesday 05 June 2007 00:25:45 Mikkel Kamstrup Erlandsen wrote:
<br>> > > 2007/5/30, Evgeny Egorochkin <<a href="mailto:phreedom.stdin@gmail.com">phreedom.stdin@gmail.com</a>>:<br>> > > > Hi all,<br>> > > ><br>> > > > I'd like you to take a look at the ontology sketch
<br>> ><br>> > <a href="http://www.freedesktop.org/wiki/PhreedomDraft?action=AttachFile&do=view&t">http://www.freedesktop.org/wiki/PhreedomDraft?action=AttachFile&do=view&t</a><br>> ><br>
> > > >arget=viz.png<br>> > > ><br>> > > > It's not complete. Some fields/classes are dropped intentionally.<br>> > > > I'd like to hear some feedback first.<br>> > > >
<br>> > > > Points of interest:<br>> > > > *** Sources<br>> > > > *Source hierarchy<br>> > > > *Which properties belong to content and which to source?<br>> > >
<br>> > > I was just scanning through<br>> > > <a href="http://www.dfki.uni-kl.de/~mylka/nie.pdf">http://www.dfki.uni-kl.de/~mylka/nie.pdf</a><<br>> ><br>> > <a href="http://www.dfki.uni-kl.de/%7Emylka">
http://www.dfki.uni-kl.de/%7Emylka</a><br>> ><br>> > >/nie.pdf>. As far as I can read in Nepomuk DataSource does not derive<br>> ><br>> > from<br>> ><br>> > > DataObject. Also it states that a DataObject is something where you can
<br>> > > physically retrieve some bytes in some way or other. Taking this into<br>> > > account I don't think it makes sense to let User derive from DataObject<br>> > > either.<br>> > >
<br>> > > Personally I would prefer to have a field Category and a field Source,<br>> ><br>> > but<br>> ><br>> > > I know from IRC that this will cause trouble in some implementations,<br>
> ><br>> > but I<br>> ><br>> > > would like to have this stuff discussed on-the-record so to speak; so<br>> > > please chime in with your concerns regarding this.<br>> ><br>> > Nepomuks DataSource is absolutely different from Xesam sources.
<br>><br>> Unless that document is horribly outdated I can't se how. A DataSource<br>> designates the origin of some DataObject if I'm not mistaken. This was also<br>> the idea behind xesam sources.<br>
><br>> They might differ on the technical level but the idea behind them seems the<br>> 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'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>