2007/5/30, jamie <<a href="mailto:jamiemcc@blueyonder.co.uk">jamiemcc@blueyonder.co.uk</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, 2007-05-30 at 18:51 +0300, Evgeny Egorochkin wrote:<br>> Hi all,<br>><br>> I'd like you to take a look at the ontology sketch<br>> <a href="http://www.freedesktop.org/wiki/PhreedomDraft?action=AttachFile&do=view&target=viz.png">
http://www.freedesktop.org/wiki/PhreedomDraft?action=AttachFile&do=view&target=viz.png</a><br>><br>> It's not complete. Some fields/classes are dropped intentionally.<br>> I'd like to hear some feedback first.
<br><br><br>thanks for this<br><br>changes I would like:<br><br>1) my pref is for something a bit simpler with a lot of the intermediate<br>categories removed (IE Visual, Media, Message, Source cats)</blockquote><div><br>
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.
<br><br>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.
<br> - I think stuff like this is one of the big use cases for abstract categories like Media and Message.<br><br>Evgeny: I think Message<--IM (or ChatMessage or what ever) is missing in the onto?<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) The category User does not make sense. User metadata should be<br>applicable to all so best in content if you ask me</blockquote><div><br>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:
<br><br> 1) Cats are a way to create groupings of fields<br> 2) Cats are a way group the indexed objects<br></div><br>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).
<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">3) Content itself seems too file specific to be a top level parent of<br>all the entities. I think DC and User metadata should be there with
<br>maybe a FileContent object providing more file specific details</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">4) I dont like using one metadata name for several differing purposes.<br>EG Email should have an
Email.Sender and not a Content.Author (although<br>Email.Sender can subclass Content.Author or even better DC.Author)</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I would like to see DC metadata at the top with it being abstract and<br>most of the other metadata subclassing it. EG we would have
<br>Document.Author subclassing Dc.Creator etc.<br><br>Trying to share metadata names across categories tend to make it much<br>harder to read IMO hence better use of subclassing and unique names<br>should improve it.</blockquote>
<div><br>As stated earlier I tend to agree with you here. Mostly because having ambiguous field content is dangerous... <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Audio needs some Metadata and Contact should use the standard vCard spec<br>fields as this is what Evolution Data server uses.</blockquote><div><br>I think Audio was left blank to reduce clutter in the image...<br><br>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?
<br></div><br><br>Cheers,<br>Mikkel<br></div><br>