[XESAM] Ontology snaphot. Important proposal.

[Evgeny Egorochkin]

On Sunday 17 June 2007 21:27:29 Mikkel Kamstrup Erlandsen wrote:
> 2007/6/17, Evgeny Egorochkin <phreedom.stdin at gmail.com>:
> > This time pretty picture contains only parts of the ontology I've been
> > actively changin since it just takes too much time to make nice layouts
> > :)
> >
> > http://www.freedesktop.org/wiki/PhreedomDraft?action=AttachFile&do=view&t
> >arget=viz-part.png --------------------
> > Proposal:
> >
> > While ontology is still not complete, it's structure is unlikely to
> > change much. It's quite hard to get it absolutely right in theory...
> >
> > So my proposal is to start implementing it. Whatever inconsistencies,
> > missing
> > fields, ambiguity or other problems we encounter will be resolved in the
> > process. This way, by the time xesam 1.0 spec is ready, so are actual
> > implementations.
>
> I think we need more documentation on the ontology. This includes:
>
>  - better description of each field and cat (just inlined in the rdfs for
> now, we can extract documentation programmatically)
>  - a document describing the ontology as a whole

I tried to document some stuff in my emails by giving detailed answers. Now 
who's going to dig it all and turn into something more human-friendly? :)

> On top of this we also need:
>  - data types for fields (fx integer, float, string, date, boolean)

Usually, it's evident, but some cases can be quite hard. Also we haven't 
decided on some issues like how to represent email.to,cc,bcc

>  - whether or not it is abstract

This will be one of the lastest things done due to obvious reasons.

>  - others?

Many problems will be evident during implementation.

I expect to provide one more snapshot which will be the basis for 
implementation. It's time to settle ideological issues. Practical ones will 
be resolved on the go.

> ---------------------
>
> > Controversies:
> >
> > Should we have file extension field?
>
> Yes, I think so.

ok

> Should we index folders just like other files?
>
>
> You mean that  we have the same fields on files and dirs (ie both share the
> File cat)? I think this could be ok if we add an isDirectory field or
> something.

I meant that should we include folders in the index at all? How is this 
useful?

> --------------------
>
> > Implemented support for multiple  filesystems, removable media indexing,
> > disk
> > images in files.
> >
> > This is accomplished by introducing FileSystem content type, which
> > represent a
> > generic filesystem.
> > For disk images, the Source of the filesystem is set to File.
> > For hdd partitions and removable media, Partition source is used. It lets
> > specify both device and uuid(e.g. to identify different usb sticks).

> Ok, maybe I'm overengeneering , but would it make sense to have
> Device<--Partition. This would allow us to potentially have mobiles, and
> other non-storage specific devices, in the onto.

I wish somebody would enlighten us on how all these things work in detail.
Seems like UUID is a property of *nix partitions, so identifying usb sticks 
formatted as FAT is out of question :/ 

It seems that indeed Partition should be replaced with BlockDevice and 
Partition is a good candidate for FileSystem child.

> Maybe we should keep the xesam core onto with Partition as the only child
> of Device (or maybe FileSystem is a better word for Partition then (the
> FileSystem cat could be renamed to DiskImage)), and leave options open for
> 3rd parties.
>

>  - Unix files also have a group (as addition to owner), maybe we should
> have a field for that

good idea

-- Evgeny