James Henstridge wrote: > On 24/10/06, Jamie McCracken <[EMAIL PROTECTED]> wrote: >> Ross Burton wrote: >> > On Tue, 2006-10-24 at 23:26 +0800, James Henstridge wrote: >> >> I think that the idea Ross is trying to get across here is that rather >> >> than having a flat namespace of metadata types, you want to have >> >> relationships between the metadata types (metadata about metadata). >> > >> > [snip] >> > >> > Yes, thanks James for explaining clearly what I was trying to say. :) >> >> I have been thinking of allowimg all metadata to be registered with an >> optional hardcoded dublin core type(1) so we could use maybe >> "dc.creator" that would search all metadata registered against that type. >> >> You would not be able to get/set the value of any of the dc types >> obviously as they would potentially point to more than one metadata. >> >> Would that satisfy you Ross? >> >> (1) http://dublincore.org/documents/1999/07/02/dces/ > > If it was specific to dublin core, and only had one level of > specialisation, then it would only be of limited use.
it would be limited - but is that a bad thing? Im planning to add extensible metadata support to tracker-search-tool but I need it to be easy for users to add new metadata. Having a simple window which allows you to define the name, type (indexable string, string, numeric or date) and class (a dropdown combo of the 13 or so DC types) should give us a good balance. I would be worried about anything more complicated. That said for the application api I could be more open. > > If we ignore the implicit inverse relationship issue, you really want > a table that contains "property type foo is a subclass of the property > type bar". For the case of two properties being equivalent, we can > represent that with two relationships: > * foo is a subclass of bar > * bar is a subclass of foo yes thats easy to do > > Of course, using a table like this is not going to be fast when doing > SQL queries. So you probably want to have a flattened version that > can be used to map from a property to all its subclasses (usually > including itself, to make the SQL easier). Such a flattened table is > pretty easy to maintain with database triggers or in the application > code that updates the metadata type relation table. We shouldn't need a flattened table as the two metadatatype tables would be properly indexed so joins would be fast (especially with sqlite) Technically there's no problem here for me to implement this, my only concern is keeping it KISS and simple for users/apps to use without too much complication It would be nice to see some examples of said relationships and how they would differ from one limited to dublin core roots. -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
