[XESAM] Ontology sketch. Feedback needed. This time with attachment.
phreedom.stdin at gmail.com
Mon Jun 4 17:07:27 PDT 2007
On Tuesday 05 June 2007 02:18:21 Mikkel Kamstrup Erlandsen wrote:
> 2007/6/5, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
> > On Tuesday 05 June 2007 00:25:45 Mikkel Kamstrup Erlandsen wrote:
> > > 2007/5/30, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
> > > > 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
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 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-,
For example, local copy and content creation dates belong to Source and
Content respectively, while in NIE both belong to DataObject.
More information about the xdg