[Xesam] Ontology snapshot

[Evgeny Egorochkin]

On Monday 11 June 2007 17:19:08 Antoni Mylka wrote:
> Mikkel Kamstrup Erlandsen pisze:
> > In this setup I think "source" is a misleading word, but I can't think
> > of anything better right now (I think there must be at least 30C in the
> > office, my brain is steaming)...
>
> I'd rather go for DataObject vs. InformationElement
> (this distinction will be adopted in NIE draft 5)
>
> The way I see the notion of a source, is that each and every piece of
> information on the desktop can be accessed with a simple hierarchy,
> where we begin with some top-level entity (e.g. a HDD Partition) and
> then go downwards by means of two alternating steps - interpretation and
> containment.
>
> A DataObject is interpreted as an InformationElement and then other
> DataObjects are found inside this InformationElement which have their
> own interpretations:
>
> Examples
>                               a Desktop contains a
> HDDPartition is interpreted as Filesystem which contains a
> FileEntity   is interpreted as a Folder which contains another
> FileEntity   is interpreted as a Mailbox which contains a
> MailboxItem  is interpreted as a Message which contains an
> Attachment   is interpreted as an Archive which contains
> a FileEntity is interpreted as a Document
>
> or...
>
> Modeling COM-Based access to an Outlook calendar (sorry for a M$ example )
>                                     a Desktop contains a
> PieceOfSoftware is interpreted as an Application which contains an
> SoftwareService is interpreted as a Calendar which contains a
> CalendarDataObject is interpreted as an Event which contains an
> Attachment which is interpreted as a PDFFile (a flyer for an event)
>
>
> The left side is what is currently called "Source" in XESAM, the right
> side is what is currently called "Content" in XESAM. I've even drawn a
> picture:
>
> http://www.dfki.uni-kl.de/~mylka/interpretation-containment.png
>
> The core of the fifth draft of NIE revolves around two classes and two
> properties:
>
>                      --------- hasPart -------|
>                     \|/                       |
>                 DataObject  --------|> InformationElement
>
>                      |                       /|\
>
>                      -------- isPartOf -------|
>
>
> ------|> means inheritance, each DataObject is in fact an
> InformationElement even if there are no more detailed interpretations
>
> There are no hasInterpretation properties because I assume that each
> resource will have ONE interpretation, and this is better expressed with
> a is-a relationship (rdf:type). Well, actually it's your idea.

Actually there are often 2 interpretations. Remember Content.asText property?

One example: interpreting text as audio(text-to-speech that is) is e.g. to 
estimate time it would take to read the speech you've just written.
(media.duration)

I'm still trying to come up with a good case where we would need extra 
interpretations.

Cases to consider: Trash (a folder with files and also trash container), Video 
DVD(a complex media container vs filesystem).

Sometimes this multiple interpretation issue is avoided by making SourceCode 
inherit from TextFile.

> This allows for arbitrary interpretations: a file may be a Mailbox, but
> also a RemoteHostAddress mail be a Mailbox, a DBUS service may be a
> Mailbox... As far as content is concerned all of these are Mailboxes,
> they have the same interpretations even if their representations differ.

Thank you for presentation. You are far better at this than me :)

> Other pairs worth consideration:
> representation vs. interpretation
> or data vs. content
> or data vs. information
> or physicalEntity vs. contentEntity
>
> or something along these lines ...

We're dealing with form/essense duality here.

Actually I do quite like Content as a more down-to-earth name for essense, but 
what to do with form?

Source doesn't fit at all.

Maybe StoredAs?

> the term 'source' is misleading indeed. Evgeny has already written some
> time ago that it took him quite a while to understand what Aperture
> DataSources are, now it took me even more to understand what Xesam
> sources are. I find it a great idea though (kudos to Evgeny). With this
> concept it is possible to build a tree that would begin with "Desktop"
> and contain all information on a desktop. The containment relations
> would represent the "physical" structure of those resources, the
> interpretations will represent the content, that will be treated the
> same regardless of where it is.

-- Evgeny