[XESAM] Ontology sketch. Feedback needed. This time with attachment.

[Evgeny Egorochkin]

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 
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.

--Evgeny