[XESAM] Ontology snaphot. Important proposal.
phreedom.stdin at gmail.com
Sun Jun 17 12:01:20 PDT 2007
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.
> 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
I meant that should we include folders in the index at all? How is this
> > 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
More information about the xdg