[Xesam] Ontology snapshot

[Mikkel Kamstrup Erlandsen]

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


Could be. Maybe just "Form" as you wrote yourself (unless that has other
implications I'm not aware of).

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070611/84320abb/attachment.htm