2007/6/9, Evgeny Egorochkin <[EMAIL PROTECTED]>:

Source attached. Cute picture:

http://www.freedesktop.org/wiki/PhreedomDraft?action=AttachFile&do=view&target=viz.png



Great work. This is really starting to look like something.

--------------
Design decisions proposed:

Split ontology into Xesam Core, Xesam Convenience and Xesam Mappings

Xesam Core expresses the full semantics of the ontology i.e. it is
self-sufficient and describes all the useful information we plan indexing.

Xesam Convenience contains semantically irrelevant fields which are
subchildren of Xesam Core fields and provide nothing except more
human-friendly names and descriptions.

Xesam Mappings provides mapping for external standards like EXIF and
vCard.
For each such standard a base set of fields and categories capturing the
most
relevant features of the standard is provided in Xesam Core.
The full standard or a more complete implementation is provided via Xesam
Mappings.
The reason: excessive complexity or multiple irrelevant features of the
standard.

Xesam Core is the primary goal for now. The rest will follow as the need
arises/time allows


Ok, I think this (onto split proposal) is a good idea to avoid *trying* to
create the all-encompassing onto in the first take.

My only gripe is that I don't like the word "Convenience", how about
"Extended" instead?

So +1 from me if we call Xesam Convenience Xesam Extended instead :-)


VCard compatibility:
It is not feasible to implement the full vcard functionality. The
following
simplifications are made:
* name is a single field


I guess we can split the name up in subfields (forname, surname, middlename)
in Xesam Extended or something..?

* postal addresses are single fields


This makes sense. It would take a lot of fields to model a
nationality-neutral postal address scheme.

* some obscure features are dropped like modem phone number for the sake of
simplicity


Good

New design limitations:
1) Source and Content hierarchies are kept separate, that is no Class can
inherit source and content at once
2) Each file is assigned at max one content and one source.


Good - as we all agreed on :-)

------------
Issues:

Maybe we need a better name for MailboxItem and ArchiveItem?


I think we should scrap the Item part of those words. This cat name is not
describing what the object *is* but what the object comes from. With the
Item postfixes it sounds like the object with Source=ArchiveItem comes from
an item withing an archive (fx a jpg in a pdf in a zip).

Still not decided on how to PIM stuff.


Could we rename Todo to Task instead then? Sounds less nerdy :-)

Fields on the Task cat could be Summary, Priority, DueDate. Stuff like a
Summary and Description can be derived from fields in the Content cat.

Need to revamp media ontology.

Can we count on backends being able to figure out list lengths? i.e. if we
have Software.depends relation, do we need Software.dependCount? I think
no.
Either we have a *count property for things we don't describe, or we have
a
list of things and no *count property.


Hmmm... This is a tricky case. The query language cannot handle this atm. -
Ie searching for all SourceCode items with more than 10 depencies fx -
unless the number of deps is explicitely stored in a field.

Should we elaborate comment stats for SourceCode along the way of text stats
or commentCharacterCount is sufficient?


It is sufficient for the only use case I can come up with. Finding
under-documented stuff. I think we should keep it at this.

Questions:

Afaik PDFs (and other office docs) can be password protected. Perhaps
isPassWordPretected should be moved to contents?

Is there any general field that names the origin of a file? Fx a the url of
a downloaded file?

You've added MediaList and AudioList. Would it not make sense to have a
generic List object? Fx a series of images or documents might form a
slideshow. Perhaps a better metaphor would be Collection. Fx. most IDEs has
a project-metaphor where a bunch of files is a part of a project. With the
collection metaphor we could model this.

Now I'm at it - why not a Project cat? It could be a subcat of my suggested
Collection cat. Projects have names, versions, etc... I have several
programs that install project files.

Does Audio not have any fields or is it just trimmed down for display
purposes?

Cheers,
Mikkel
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg

Reply via email to