[Xesam] Ontology snapshot

[Evgeny Egorochkin]

On Sunday 10 June 2007 22:22:39 Mikkel Kamstrup Erlandsen wrote:
> > > > Xesam Core is the primary goal for now. The rest will follow as the
> > need
> > > > arises/time allows
> > >
> > > Ok, I think this (onto split proposal) is a good idea to avoid *trying*
> > to
> > > create the all-encompassing onto in the first take.
> > >
> > > My only gripe is that I don't like the word "Convenience", how about
> > > "Extended" instead?
> > >
> > > So +1 from me if we call Xesam Convenience Xesam Extended instead :-)
> >
> > I called it convenience because it's "semantically irrelevant" that is
> > you can
> > do everything with Xesam core, and xesam convenience is nothing more than
> > novice-understandable mapping of Xesam core.
>
> Ok, let's just call it "convenience" for now. The exact wording is not
> central at this point.

I was just trying to define the scope and order of works.

> Is there anything from your current draft that will be punted to
> convenience or mappings?

Hardly anything.

> > > > Issues:
> > > >
> > > > Maybe we need a better name for MailboxItem and ArchiveItem?
> > >
> > > I think we should scrap the Item part of those words. This cat name is
> >
> > not
> >
> > > describing what the object *is* but what the object comes from. With
> > > the Item postfixes it sounds like the object with Source=ArchiveItem
> > > comes
> >
> > from
> >
> > > an item withing an archive (fx a jpg in a pdf in a zip).
> >
> > We need to agree on a consistent Source naming.
> > Source-Source Item examples:
> > Filesystem      -File
> > Archive         -ArchiveItem
> > Email           -Attachment
> >
> > It seems resonable to adopt either:
> > * this is contained in a [Filesystem,Archive,Email]
> > * this is a [file, archiveitem, attachment]
> >
> > But not the both at the same time.
>
> Right. This is tricky. I  really think the "this comes from"-metaphor is
> the closes to the intention. The "this is a"-metaphor is already what
> categories imply.
>
> Because of this I also think that Mailbox is a better  source name than
> Email.

Here Email corresponds to Attachment. That is we are dealing with an 
Attachment that is contained in a Email.

> The Attachment is more subtle because in some way it does make sense 
> to say that "holiday1.jpg comes from an attachment", I can easily imagine
> several arguments against this metaphor but it is really not a clear cut
> case.

How about File vs FileSystem?


> > Still not decided on how to PIM stuff.
> >
> > > Could we rename Todo to Task instead then? Sounds less nerdy :-)
> >
> > This is the first time in my life someone calls Todo nerdy.
>
> About time someone broke it to you then :-) "Todo" *is* a geek term -
> atleast my wife never used it before she met me :-)

I don't recall if I ever called it differently. Perhaps I've always been a 
geek   8|

> > > Fields on the Task cat could be Summary, Priority, DueDate. Stuff like
> > > a Summary and Description can be derived from fields in the Content
> > > cat.
> >
> > There's a good reference: iCalendar. Have to strip many fields to make it
> > usable though.
> >
> > The problem with these PIM things is like this: We have 6 fields and 5
> > PIM classes. Each ones uses 5 fields out of 6, and each one uses a
> > different set.
>
> Eeek. Good that I'm not the ontology maintainer ;-P

Thanks for encouragement.

> > Questions:
> > > Afaik PDFs (and other office docs) can be password protected. Perhaps
> > > isPassWordPretected should be moved to contents?
> >
> > These are two different things. In case of ArchiveItem password
> > protection is
> > external to the file, provided by archiver. In case of documents, the
> > password protection is internal.
> >
> > ATM it seems like a good idea to implement it the same way as with
> > keywords.
> > Will think more about it of course.
>
> I'm affarid I can't see the probelm here. There might be different
> implementations behind the different password protection mechanisms, but
> all that we are interested in is whether or not the file is protected.

The problem here is that we'd better allow IsPP property assigned only when it 
makes sense. Most of content can't be PP. Not a big prolem, but clarity is 
still nice.

> > Basically Content already implements collection and container
> > functionality.
>
> You mean via the content.contains, links, depends fields? It might still be
> useful with some cats for this though - as I assume Content will be an
> abstract cat.

Exactly. Content won't be used directly. Different collection Cats will have 
limitations on what types of files they aggregate. This limitation is implied 
atm. Though RDFS allows to clearly state this.

My collection cats collect and aggregate mostly food though. But they are 
proficient at this. You can't hide anything from them :)

-- Evgeny