[XESAM] Ontology sketch. Feedback needed.

[Mikkel Kamstrup Erlandsen]

2007/5/30, jamie <jamiemcc at blueyonder.co.uk>:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070531/c4e1f3d9/attachment.htm