2007/6/11, Evgeny Egorochkin <<a href="mailto:phreedom.stdin@gmail.com">phreedom.stdin@gmail.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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: > > <a href="http://www.dfki.uni-kl.de/~mylka/interpretation-containment.png">http://www.dfki.uni-kl.de/~mylka/interpretation-containment.png</a> > > 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? </blockquote><div> Could be. Maybe just "Form" as you wrote yourself (unless that has other implications I'm not aware of). Cheers, Mikkel </div> </div>