2007/6/11, Evgeny Egorochkin &lt;<a href="mailto:phreedom.stdin@gmail.com">phreedom.stdin@gmail.com</a>&gt;:<div><span class="gmail_quote"></span><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:<br>&gt; Mikkel Kamstrup Erlandsen pisze:<br>&gt; &gt; In this setup I think &quot;source&quot; is a misleading word, but I can&#39;t think<br>&gt; &gt; of anything better right now (I think there must be at least 30C in the
<br>&gt; &gt; office, my brain is steaming)...<br>&gt;<br>&gt; I&#39;d rather go for DataObject vs. InformationElement<br>&gt; (this distinction will be adopted in NIE draft 5)<br>&gt;<br>&gt; The way I see the notion of a source, is that each and every piece of
<br>&gt; information on the desktop can be accessed with a simple hierarchy,<br>&gt; where we begin with some top-level entity (e.g. a HDD Partition) and<br>&gt; then go downwards by means of two alternating steps - interpretation and
<br>&gt; containment.<br>&gt;<br>&gt; A DataObject is interpreted as an InformationElement and then other<br>&gt; DataObjects are found inside this InformationElement which have their<br>&gt; own interpretations:<br>&gt;<br>
&gt; Examples<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a Desktop contains a<br>&gt; HDDPartition is interpreted as Filesystem which contains a<br>&gt; FileEntity&nbsp;&nbsp; is interpreted as a Folder which contains another<br>&gt; FileEntity&nbsp;&nbsp; is interpreted as a Mailbox which contains a
<br>&gt; MailboxItem&nbsp;&nbsp;is interpreted as a Message which contains an<br>&gt; Attachment&nbsp;&nbsp; is interpreted as an Archive which contains<br>&gt; a FileEntity is interpreted as a Document<br>&gt;<br>&gt; or...<br>&gt;<br>&gt; Modeling COM-Based access to an Outlook calendar (sorry for a M$ example )
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a Desktop contains a<br>&gt; PieceOfSoftware is interpreted as an Application which contains an<br>&gt; SoftwareService is interpreted as a Calendar which contains a<br>&gt; CalendarDataObject is interpreted as an Event which contains an
<br>&gt; Attachment which is interpreted as a PDFFile (a flyer for an event)<br>&gt;<br>&gt;<br>&gt; The left side is what is currently called &quot;Source&quot; in XESAM, the right<br>&gt; side is what is currently called &quot;Content&quot; in XESAM. I&#39;ve even drawn a
<br>&gt; picture:<br>&gt;<br>&gt; <a href="http://www.dfki.uni-kl.de/~mylka/interpretation-containment.png">http://www.dfki.uni-kl.de/~mylka/interpretation-containment.png</a><br>&gt;<br>&gt; The core of the fifth draft of NIE revolves around two classes and two
<br>&gt; properties:<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--------- hasPart -------|<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \|/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DataObject&nbsp;&nbsp;--------|&gt; InformationElement<br>&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /|\<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-------- isPartOf -------|<br>&gt;<br>&gt;<br>&gt; ------|&gt; means inheritance, each DataObject is in fact an<br>&gt; InformationElement even if there are no more detailed interpretations
<br>&gt;<br>&gt; There are no hasInterpretation properties because I assume that each<br>&gt; resource will have ONE interpretation, and this is better expressed with<br>&gt; a is-a relationship (rdf:type). Well, actually it&#39;s your idea.
<br><br>Actually there are often 2 interpretations. Remember Content.asText property?<br><br>One example: interpreting text as audio(text-to-speech that is) is e.g. to<br>estimate time it would take to read the speech you&#39;ve just written.
<br>(media.duration)<br><br>I&#39;m still trying to come up with a good case where we would need extra<br>interpretations.<br><br>Cases to consider: Trash (a folder with files and also trash container), Video<br>DVD(a complex media container vs filesystem).
<br><br>Sometimes this multiple interpretation issue is avoided by making SourceCode<br>inherit from TextFile.<br><br>&gt; This allows for arbitrary interpretations: a file may be a Mailbox, but<br>&gt; also a RemoteHostAddress mail be a Mailbox, a DBUS service may be a
<br>&gt; Mailbox... As far as content is concerned all of these are Mailboxes,<br>&gt; they have the same interpretations even if their representations differ.<br><br>Thank you for presentation. You are far better at this than me :)
<br><br>&gt; Other pairs worth consideration:<br>&gt; representation vs. interpretation<br>&gt; or data vs. content<br>&gt; or data vs. information<br>&gt; or physicalEntity vs. contentEntity<br>&gt;<br>&gt; or something along these lines ...
<br><br>We&#39;re dealing with form/essense duality here.<br><br>Actually I do quite like Content as a more down-to-earth name for essense, but<br>what to do with form?<br><br>Source doesn&#39;t fit at all.<br><br>Maybe StoredAs?
</blockquote><div><br>Could be. Maybe just &quot;Form&quot; as you wrote yourself (unless that has other implications I&#39;m not aware of).<br><br>Cheers,<br>Mikkel <br></div><br></div><br>