[Xesam] Ontology snapshot

[Antoni Mylka]

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.

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.

Other pairs worth consideration:
representation vs. interpretation
or data vs. content
or data vs. information
or physicalEntity vs. contentEntity

or something along these lines ...

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.

Antoni Mylka
antoni.mylka at dfki.de