I don't think I know all the details of "Dave's plugin proposal", is that what you had described with using the entryattribute table and Lucene search?
My personal preference is to do something more elaborate and functional than the solution that requires using the Lucene search. I just believe that solution would prove to be of limited use. So I would vote for the solution that includes more of a dashboard. Note that I don't necessarily think my code/implementation is the right way to do it yet, I merely offered that as a proof of concept. -- Allen On Fri, 2005-09-16 at 09:36, Elias Torres wrote: > I have not written this as a proposal. But I have a basic question > since we have options of how to implement this. Should we implement > this as a plugin using Dave's plugin proposal with your tag table? or > just using your code + dashboard integration + tag presentation > servlet? > > Elias > > On 9/15/05, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > Elias, > > > > here's the code I was talking about. i took a little time this afternoon > > updating it to roller 2.0, so you should be able to just unpackage the > > files in a roller 2.0 workspace and do the build. you have to add the > > custom db tables manually ... they are in metadata/database/roller_tags.sql > > > > http://blogs.sun.com/roller/resources/gconf/roller-tags.tar.gz > > > > cheers. > > > > -- Allen > > > > > > On Wed, 2005-09-14 at 19:36, Allen Gilliland wrote: > > > On Wed, 2005-09-14 at 16:12, Elias Torres wrote: > > > > On 9/14/05, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > > > > 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. > > > > > > > > > > > > > Sorry, I didn't mean to rely on technorati for searching but that it > > > > would be a side benefit of having tags like with Lance's plugin except > > > > the tags are not stored in the text but in the db. > > > > > > > > > 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? > > > > > > > > > > > > > That's for technorati to consume only and for users who want to > > > > display their data. However, the approach would be to enhance the > > > > search engine by extracting this other piece of metadata at indexing > > > > time and adding UI to search to reflect this new option. > > > > > > gotcha. i think i confused this part a bit. i agree that making the > > > search engine tag smart would be very useful and would provide a pretty > > > easy way for us to make use of tagged entries. but again, why stop > > > there? the functionality this would provide is fairly limited. what > > > about rss feeds? would the search engine be able to offer up an rss feed > > > of the last 50 entries tagged with "apple" and "farm"? this is something > > > that i would love to see our tagging support be capable of. > > > > > > > > > > > > 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. > > > > > > > > > > > > > Right. > > > > > > > > > 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. > > > > > > > > I wholeheartedly agree with this part. You are correct that we need a > > > > better dashboard. The first version of our internal deployment had a > > > > lot more in this regard. We have a special frontpage once you've > > > > logged in that includes things like recent comments to your entries, > > > > recent entries for quick editing and a huge query that found the most > > > > recent threads you've participated and links to the posts and > > > > comments. But this will be scrapped when we move to 2.0 so we have to > > > > start fresh. I did not want to put that burden on Roller, so I was > > > > thinking a separate application to do that for performance. We also > > > > have a ton of stats on users per country, number of blogs and number > > > > of entries, postings per month, etc for everyone in the company to > > > > see. > > > > > > ahhh ... i think this is exactly what Roller needs! i think that a way > > > to find/sort/view entries via tags would be the most important and usable > > > component of a Roller dashboard. i also think we could use a simple > > > directory which just lists all weblogs and provides some ways to break > > > 'em down ... i.e. Newest Weblogs or Japanese Weblogs, etc. > > > > > > basically, i think Roller needs a nice dashboard that allows users to > > > find weblogs and entries in any way that seems useful. tagging seems > > > like a good way to do this. > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > Agreed. > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > This was just an example. Although it'd be nice to track tag usage and > > > > the tag date would be more accurate than the post date. I've done some > > > > studies on that. > > > > > > > > http://torrez.us/archives/2005/07/13/364 > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > Thanks and you are right regarding my intent to leave it to search > > > > engine to solve the problem (I'm not the first one to think that. > > > > *cough* Google). In our case we have a young product called OmniFind > > > > with a lot of flexibility so we wanted to try that because we are not > > > > committers to Roller and right now we are dealing on a patch per patch > > > > basis. However, I wouldn't mind taking your code and putting it back > > > > into Roller 2.0 use the table the way you have proposed and work out a > > > > way to "introduce" tags in the frontpage as a patch. At least, the > > > > most popular tags for starters and maybe even subscribe via Atom/RSS. > > > > We can then use the tag data and still feed it to our search engine > > > > and experiment there somemore. What do you think? > > > > > > i think that sounds great. i'll gather up the code i have and send it > > > over tomorrow morning. > > > > > > -- Allen > > > > > > > > > > > > > > -------------------------------------- > > > > Speaking of search engines, we need a way to register a plugin to hook > > > > on the save events of posts and comments w/o having to patch our local > > > > build except by adding a new plugin in the configuration. Things like > > > > settings (mediacast) are directly hard-coded into the jsp and rest of > > > > the code. We'd rather not do that, since it would be hard to maintain. > > > > > > > > Regards, > > > > > > > > Elias > > > > > > >
