2007/5/30, jamie <[EMAIL PROTECTED]>:
On Wed, 2007-05-30 at 18:51 +0300, Evgeny Egorochkin wrote:
> Hi all,
>
> I'd like you to take a look at the ontology sketch
>
http://www.freedesktop.org/wiki/PhreedomDraft?action=AttachFile&do=view&target=viz.png
>
> It's not complete. Some fields/classes are dropped intentionally.
> I'd like to hear some feedback first.
thanks for this
changes I would like:
1) my pref is for something a bit simpler with a lot of the intermediate
categories removed (IE Visual, Media, Message, Source cats)
Is there any specific reason for this? We shouldn't create abstractions just
because we can, I give you that, but I don't think Evgenys proposal is
needlessly complicated (in fact I don't think it is complex at all). Having
groupings like Message<--{Email,IM} makes good sense to me.
Fx. if I want I create a myCommunicationsCentre app that showed me all
communications-related material then I would just show all recent stuff from
the Message cat in the default view. If some new means of communicating pops
up (fx Message<--RadioTranscription) mCC would handle that without me having
to do anything.
- I think stuff like this is one of the big use cases for abstract
categories like Media and Message.
Evgeny: I think Message<--IM (or ChatMessage or what ever) is missing in the
onto?
2) The category User does not make sense. User metadata should be
applicable to all so best in content if you ask me
I think you are partially right. As I see it there are two notions of
categories that is a bit intermixed in the current proposal. Namely:
1) Cats are a way to create groupings of fields
2) Cats are a way group the indexed objects
In the context of (1) the current proposal makes good sense with linking the
rating,keywords,usageIntensity and such to the User cat. I do think that we
should keep (2) as the prime objective for having categories. Because of
this I think these fields should belong to the highest object in the
hierarchy (Content or DataObject).
3) Content itself seems too file specific to be a top level parent of
all the entities. I think DC and User metadata should be there with
maybe a FileContent object providing more file specific details
So you are saying that we should have the most basic element have DC and
User metadata? I partly agree. I don't think all DC fields need to go on the
most basic level, but I'm not I'm not going to loose sleep over it.
4) I dont like using one metadata name for several differing purposes.
EG Email should have an Email.Sender and not a Content.Author (although
Email.Sender can subclass Content.Author or even better DC.Author)
Yeah, I have mixed feelings about this too. On the one hand I think it is
good sense on the other hand I think it may be dangerous having the fields
mean different things on different objects.
I would like to see DC metadata at the top with it being abstract and
most of the other metadata subclassing it. EG we would have
Document.Author subclassing Dc.Creator etc.
Trying to share metadata names across categories tend to make it much
harder to read IMO hence better use of subclassing and unique names
should improve it.
As stated earlier I tend to agree with you here. Mostly because having
ambiguous field content is dangerous...
Audio needs some Metadata and Contact should use the standard vCard spec
fields as this is what Evolution Data server uses.
I think Audio was left blank to reduce clutter in the image...
On vCard, I think this is a good idea, but how does this fare with 3rd party
extensions to the fields in the Contact category? Fx. how would a skype
client install skype-specific contact fields and have them integrated
smoothly in the search results in the Contact cat?
Cheers,
Mikkel
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
