[XESAM] Ontology snaphot. Important proposal.

[Mikkel Kamstrup Erlandsen]

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

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


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