James Henstridge wrote: > >> 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. > > The relationships between metadata types wouldn't really affect this > UI though, right? The relationships would be provided by application > developers along with the metadata extraction tools for their file > types, right? > >
if its just in the api then its fine with me (user defined metadata wont have relationships then and only application defined ones will) >> 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) > > Really? From the description I give above, the relationships between > different metadata types form a directed graph. Taking the music > example again, consider the following set of relationship types: > 1. foo performed bar > 2. foo performed vocals on bar > 3. foo performed lead vocals on bar > > If I register that (2) is a subclass of (1) and (3) is a subclass of > (2), I want searches for relationship type (1) to pick up metadata of > types (1), (2) and (3). okay yes that makes sense - we need to recursively get all parent metadata types > > SQL systems don't generally deal with graphs particularly well (unless > they've got some extension to do so). So I was suggesting that a > flattened table be maintained as a cache which could map any > relationship type to all the relationship types reachable in the > graph. That way you can it is a single join (or subquery) to select > all the relevant metadata types. > > If you know a better way to do this efficiently without a flattened > table, that's great. yeah agree a flattened table would be best > > >> 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 > > Ideally this would be mostly invisible to users: their queries for > generic relationship types would just work, even if the metadata > extractors for particular file types produced more specialised types. > > It does mean that application authors who wish to introduce new types > of metadata need to think about how they relate to the existing types, > but that is necessary for the metadata to stay useful when doing > generic queries. yeah thanks that makes sense -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
