2007/6/11, Evgeny Egorochkin <[EMAIL PROTECTED]>:
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
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
