On Wed, 2005-09-14 at 13:31, Elias Torres wrote: > The reason, why I'm not striving for lookup efficiency it's because I > wanted to leave it up to Lucene or in the IBM case to OmniFind search > engine to deal with the queries. I believe Lucene has a way to add > query terms so you can say posts with tag:apple and tag:farm, etc. > Plus of course, the added benefit of having tags for technorati to > consume in the rendered templates. I don't think that /tag/apple+farm > is something that Roller users are in desperate need of at this > moment, but I could be wrong.
I agree that adding the tags to the pages to be consumed by sites like Technorati makes sense, but should we really *rely* on that? technorati requires actual anchors (<a>) which some Roller users may not want on their weblogs, so we'd have to support a way for the tag data to be html embedded metadata that doesn't affect page display. A possible part of the problem with this approach is that to get all that tag metadata into users pages would require everyone to update their page templates. How would you propose to insert the tag data into user pages? Another point to note is that at BSC we have disabled the built-in Lucene search because it has problems, so instead we use our custom Sun Onesearch mechanism. At least in our case this would make your implementation harder to manage because we would then need to make further customizations to our search engine just to support tag specific searches. I would also disagree that the /tag/apple+farm functionality is something that Roller users don't want. At BSC we regularly get users asking why we don't provide a kind of blog directory which makes it easier for users to find weblogs. All that Roller has is a search and the main page, and neither of those provide a navigatable structure for browsing blogs. Searching is definitely the best way to find what you're looking for, but what if you aren't really looking for anything in specific? I like the idea that the TagServlet homepage could provide some fun ways for people to find blogs, like listing things like ... Most Recent Tags and Most Popular Tags kind of the way flickr does it (http://www.flickr.com/photos/tags/). Searching would have no way of doing that. > > Let's talk more to see what we should be concentrating on for this feature. > > > > > > > On Wed, 2005-09-14 at 12:25, Elias Torres wrote: > > > Allen, > > > > > > I was thinking of using the entryattribute table, what do you think? I > > > don't think that we want another table for every little feature. At > > > first I was thinking of something simple, like a "text" field a la > > > del.icio.us as another + in the settings section of the post that can > > > be edited by the user anytime. Maybe then using the Tag render plugin > > > for just rendering the tags and also making sure that Lucene indexes > > > the tags as well. I don't think we need to worry about the big content > > > or technorati style dashboards yet, but at least start collecting the > > > data. > > > > hmmm, it depends on how you want to use the entry attribute table. were > > you going to set a single attribute called "tags" which is a list of all > > the entry tags? or are you planning to do an attribute per tag? > > > > i agree that getting tag data is important, but if you can't use that tag > > data for something useful then what's the point? if we are going to do tag > > support then i'd at least like to see some way of finding tagged entries > > included in the first release. > > > > > > > > I do have a problem with the entryattribute table in general because > > > it's very limiting. For example, it's really cumbersome if I want to > > > store both the tag and the date it was inserted on. Even worse, if I > > > had another piece of metadata about that tagging to insert. It works > > > for MediaCast right now because you only have attributes about the > > > entry and not about the actualy entry metadata. I had mentioned to > > > Dave on IRC that since my day job is on Semantic Web stuff, maybe > > > making that table a more RDF-friendly table would be really cool for > > > Roller. > > > > this is murky water if you ask me. i think i like the fact that the > > entryattribute table is a simple hashtable of data attached to a weblog > > entry, that keeps it simple. if you need to relate complex data to an > > entry then it's probably best that you create a new table for that data. > > > > i am all for reuse of existing architecture as long as it works, but if it > > is going to inhibit our ability to effectively use the tags then i say > > forget the entryattribute table and go ahead and do whatever you need to do. > > > > i don't really know what you mean by RDF-friendly, so you'd have to > > elaborate more. > > > > Basically the entryid column should be a normal column that can take a > URI/URL and not just an entryid and maybe another column for entryid > so we can fetch quickly all of the triples associated with that entry. > > I can then do this: > > <entryid-1> <hasTagging> <tagging1> > <entryid-1> <hasTagging> <tagging2> > <tagging1> <dc:date> "2005-09-13" > <tagging1> <tag> "blogs" > <tagging2> <dc:date> "2005-09-15" > <tagging2> <tag> "farm" > > plus things like: > > <tagging1> <syn> "weblogs" > <tagging1> <syn> "blog" > ... > > Again, if we are going to bake Tags into the core, then the table you > mentioned would be best for the servlet to render entries. But for any > entryattribute/metadata, I think the RDF might be more flexible for > things like structuredblogging. I think you lost me on that first part. The entryid column of the entryattribute table is a foreign key relationship to the weblogentry table, so i don't see how you could change that. What is the purpose for tracking what date a specific tag was entered on? I would bet that 99% of entries would be tagged only once and all tags would be entered at the same time. I like the simplicity of your tagging approach via searching, but as I said above, I wonder if it's so simple that it's limiting. Your approach basically leaves everything up to the search engine which I believe we have less control over. -- Allen > > > -- Allen > > > > > > > > > > What does everyone think? Who else is using the entryattribute table > > > besides MediaCast? > > > > > > Elias > > > > > > On 9/14/05, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > > > Elias, > > > > > > > > I had actually began working on tag support and prototyped it back in > > > > July, but I didn't get much feedback/support on it so I focused on some > > > > other things instead. I still have some code that works if that would > > > > help. > > > > > > > > http://www.rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_WeblogTags > > > > > > > > It looks like I had also started a very simple design doc which you are > > > > welcome to elaborate on. To be honest I don't think adding tag support > > > > takes much code, but it will require a significant amount of design > > > > because it will require a lot of dynamic content on concievably large > > > > sets of data. > > > > > > > > I'm definitely looking forward to what you come up with, this would be a > > > > great addition to Roller. > > > > > > > > -- Allen > > > > > > > > > > > > Elias Torres wrote: > > > > > > > > >I have updated my patch to now work with DB2. Everything seems to be > > > > >working beautifully. > > > > > > > > > >http://torrez.us/2005/08/23/roller/patches/db2_derby.hibernate3.patch > > > > > > > > > >Regards, > > > > > > > > > >Elias > > > > > > > > > >PS> Now onto tagging. > > > > > > > > > >Heads up. I would like to add tagging to Roller, possibly using the > > > > >metadata table. I'll try to draft something up on the wiki. > > > > > > > > > >On 9/13/05, Elias Torres <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > >>Hi Everyone, > > > > >> > > > > >>After getting the nice upgrade to Hibernate 3 by Dave, I started > > > > >>working on testing Derby support first, then DB2. I only found a > > > > >>couple of issues with Derby so far, everything seems to run fine. > > > > >> > > > > >>Here's my patch: > > > > >>http://torrez.us/2005/08/23/roller/patches/derby_hibernate3.patch > > > > >> > > > > >>Basically, > > > > >> > > > > >>There was a getInt() that doesn't seem to work on strings for Derby, > > > > >>so I did this: > > > > >>- dbversion = rs.getInt(1); > > > > >>+ dbversion = Integer.parseInt(rs.getString(1)); > > > > >> > > > > >>The next one was a query in HibernateRefererManagerImpl.java which is > > > > >>not performed via Hibernate and there was a "limit" keyword which is > > > > >>not supported by Derby. I first tried the HSQL version, but Derby > > > > >>doesn't support TOP either. I added a check on the loop for max > > > > >>results, somebody please verify that this is ok. Thanks. > > > > >> > > > > >>Elias > > > > >> > > > > >>PS> Now onto DB2. > > > > >> > > > > >> > > > > >> > > > > > > > >
