[XESAM] Ontology sketch. Feedback needed. This time with attachment.
phreedom.stdin at gmail.com
Tue Jun 5 04:53:53 PDT 2007
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 :)
More information about the xdg