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

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Tue Jun 5 02:58:51 PDT 2007


2007/6/5, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
>
> 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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070605/7bf634a0/attachment-0001.htm 


More information about the xdg mailing list