Re: ITagProvider

["Kevin Kubasik" <kevin kubasik net>]

On 9/28/07, Joe Shaw <joe joeshaw org> wrote:
> Hi,
>
> On 9/28/07, Kevin Kubasik <kevin kubasik net> wrote:
> > Its important to realize that my focus is not on the implementation of
> > a backend to store this information, but to provide a generic way for
> > us to include 'tag' information from a variety of sources.
>
> Often you can't separate implementation details from the list of use
> cases, though.
Yeah, to a large extent were stuck =/
>
> Originally I wanted to do tags solely using extended attributes on
> files.  There are some definite advantages to this, like the ability
> to maintain tags when files are copied around.  But this decentralized
> model does not lend itself to doing, for instance, tag clouds.
> There's no way to get a list of all possible tags in a decentralized
> model without walking the entire file system tree -- obviously a
> non-starter.
Yeah, that was actually my first thought, since it just seemed like
the most fitting solution, as the tags would actually be with the
files.
>
> So before worrying about parent-child tag relationships too much,
> start off simple and refine the design as you go along.  What do you
> anticipate the uses for tagging on the user side?  What uses would a
> programmer want for tags, and how might this API look?  How do
> different (broad) implementation strategies fit into this?  No doubt
> you'll have to make compromises somewhere.
Hmmm... well, the dream solution is always nautilus getting a slick
tagging ui, problem is, I'm not really a slick-ui-writer guy. However,
with the beagle plugin already in thunderbird, theres potential for
integration there. Downside is there have been attempts at a universal
tagging library, what i would really love (in an ideal world) is if we
crafted events through the indexservice, meaning that while we could
offer a way to work against the tags from the BeagleClient API, you
wouldn't have to implement it. However, for tag querying/listing, we
would probably require a native API.

The specifics of how much of this were going to make beagle
responsible for (is beagle almost like a 'tagging adapter'? do we want
to provide complete bi-directional support? or do we encourage people
to work through the provider that we are using as a backend?) I have a
strong feeling that in the end were going to end up with a sqlite
database that we are maintaing and working against, which isn't the
end of the world, I would just prefer that instead of Beagle trying to
provide a robust tagging api, we just integrate it into our search
intelligently, and treat it as a property.

That being said, until the querying component works successfully, I
really don't want to get to excited about the other direction.
>
> > Also if anyone knows of a smart way to take a bunch of
> > internally-mapped Uri's and merge them with the existing result sets,
> > I'm still getting some frustration on that point, while I've figured
> > out the functional steps that the bitarray's serve (as in where to put
> > one when I want to search an index etc) once I've run the query to
> > fill/populate it, I'm not really sure of what I can do with a
> > LuceneBitArray or BetterBitArray. Anyways, I'm sure I'll eventually
> > get it, but help would save some painful slow debugging time.
>
> I'm not totally sure what you're trying to do here, but I would
> suggest (a) keeping the primary storage of tags totally separate from
> the index and (b) dealing only with real ("external") URIs and pushing
> changes out to the tag DB as needed.  That would probably require some
> additional events or something to be added to the FSQ.

Well, the problem here is, I really don't want us to be tied to one
index, or one backend. I would think (and I could be wrong here) that
once we have merged the results from a backend, we could add any Uri's
that were tagged with one of the query words. The key point here is to
have a universal tagging store that transcends our backend system. I
think I might be misunderstanding, but its not the storage of the
tags, its that a tag query has 2 defining functions (in my view, im
open to a different interpretation)
1)  If an item has a tag, that tag should appear as a property (to the
client). I think this means we need to catch Hits before they are
returned and add another property (when appropriate)

2) If a query matches a tag, then all of the tags Uri's should be
returned, this is where I'm getting really caught, because I can't
quite figure out how to take a pretty outside Uri and get a complete
Hit back.

I'm not really sure where that wires into the FSQ and more than the
other queryables.

>
> Or, if you're feeling particularly adventurous, rewrite the FSQ.
> That's the biggest consumer of memory at this point and has problems
> like being unable to search by parent directories.  I've described the
> issues with it in more detail in a previous email, I believe. :)

I seem to remember something about that. Its probably overkill right
now, with the slew of new features, but I am curious about it from a
design standpoint.
>
> Joe
>


-- 
Cheers,
Kevin Kubasik
http://kubasik.net/blog