[XESAM] Ontology snaphot. Important proposal.

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Sun Jun 17 11:27:29 PDT 2007

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&target=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

On top of this we also need:
 - data types for fields (fx integer, float, string, date, boolean)
 - whether or not it is abstract
 - others?

I'm available to answer your questions most of the time.
> jabber:phreedom at jabber.org
> Also, I'm still awaiting for clarification from Tracker on what categories
> you
> assign to files. If you want me to consider compatibility with your
> approach,
> at least I need to know what you want/need.
> ------------------
> Design decisions:
> Many containers support naming of contents. Fx email attachments have
> names.
> Some kinds of content can have a global name like "file://something", but
> only
> some. Also the trouble here is that
> while a zip file is addressed like "file://x.zip" its contents might be
> addressed like "zip://x.zip/document.odf"
> The only sensible way out of this seems to introduce both name property
> for
> container-local name(corresponds to file name) and url property for global
> addressing if it's possible at all.

Yes this makes sense to me.

> 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

> 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.

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.

> Changelog:
> * Content.contains is now a subproperty of Content.depends
> * Added Project class
> * Renamed ToDo to Task
> * Added Partition source with fields
> * Added FileSystem content class with fields
> * Removed User class and moved properties to Source
> * Added isEncrypted property to DataObject
> * Revamped media ontology

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070617/25feaad7/attachment-0001.htm 

More information about the xdg mailing list