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

[Evgeny Egorochkin]

On Tuesday 05 June 2007 12:58:51 Mikkel Kamstrup Erlandsen wrote:
> > > 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.

In nepomuk DataSource contains the information about the plug-in/backend, 
which may correspond to several xesam sources. In xesam, we explicitly 
specify what source type we have and assign properties provided by the source 
for the specific file.

> 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 :-)

I just thought it was about time to document xesam sources and implications 
and in the meanwhile answer your question :)

--Evgeny