[Xesam] Ontology snapshot

[Evgeny Egorochkin]

On Monday 11 June 2007 20:46:57 Dave Cridland wrote:
> On Mon Jun 11 12:29:10 2007, Mikkel Kamstrup Erlandsen wrote:
> > - Filesystem : The object data is stored on the fs
>
> This one I understand. But does it count only if it's a local
> filesystem? Or only one that's mounted?

This will be clarified shortly.

> > - Archive : The object data is contained in an archive
> > - Mailbox : The object data has been extracted from a mailbox
>
> A mailbox - the file sort - is an archive of mail messages - really
> there's nothing more to one than that. I'm sure that someone,
> somewhere, has used tar as a mailbox format - with some careful
> fiddling, it's probably quite a good one.

Not always. There are mailboxes like remote IMAP4 one etc. Also Mailbox lets 
you set some extra properties to Emails it contains as compared to archive.

> > - Attachment : The data of this object is stored as an email
> > attachment
>
> Mind you, an attachment is just a part of a message that the MUA
> decided not to display inline.

So do we. It is up to indexers which parts of the message they define as 
attachments.

> Functionally, there's no difference 
> otherwise. I'm not entirely sure what the distinction is between this
> and mailbox, though.

Mailbox contains Emails. And Email contains Attachments. They are quite 
different.

> > The metaphor is "the content of this object is stored in".
>
> Immediately stored in?

Yes.

> What happens if I send you a file attached to a message in a mbox
> format mailbox I've included in a tar.gz via email, and your search
> finds that - what's the source set to, and do I care?

Example: email in a *.eml file with an archive attached contaning a document 
results in 3 objects:
(File, Email)
(Attachment, Archive)
(ArchiveItem,Document)

I agree that saying that Document in this example is located in an Archive is 
quite misleading. But where do you stop going up in the chain?  Is it located 
in a file or an email?

The point of Xesam is searching for information, and upon your request GUI can 
show you how the file was found e.g. show you the whole source chain.

The intent of sources is to record how we retrieved a particular file and 
store source-specific information e.g. plaintext file can have isEncrypted 
property only if it is in an archive that provides encryption.

> Maybe it's just me, but I think maybe this sort of thing gets left
> for a bit, until you guys have figured out what it is you need, here.
> Getting the basics working in an extensible way is much, much more
> interesting.
>
> Dave.

-- Evgeny