[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 :)
> 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,
> 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
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
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
> assign to files. If you want me to consider compatibility with your
> at least I need to know what you want/need.
> Design decisions:
> Many containers support naming of contents. Fx email attachments have
> Some kinds of content can have a global name like "file://something", but
> 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
> 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.
> 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,
> 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
> * 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...
More information about the xdg