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