You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Elias Torres <el...@torrez.us> on 2006/09/12 00:10:31 UTC
Tagging support in Roller
Hi Guys,
We initially implemented a tagging function into Roller 2.0 (at IBM) but
that really never made it into core because of my lack of effort in
completing a few things that Allen had suggested before it was
functional enough. I replied to his feedback answering some of the
concerns (which I didn't think were major) [1], but I never got a direct
reply to my email. We would like to move to 3.0+ but we can't until
tagging is in place.
There's the big decision to whether we support either categories or tags
or both. I'm fine with supporting both as long as we can disable either
one or none in the UI through roller.properties.
I'm willing to code it in any specific way and don't have a set way in
mind. I'm fine with use Lucene as Ian Kellen had suggested long time ago
for performance and use the db just as a persistent storage. I'll very
through and make sure there's a tab for the tag cloud, feeds and proper
methods in beans, velocity models, etc.
Thanks,
Elias
[1] http://www.nabble.com/Re%3A-Evalutating-tag-support-p3972587s12275.html
Re: Tagging support in Roller
Posted by Elias Torres <el...@torrez.us>.
Allen Gilliland wrote:
>
>
> Elias Torres wrote:
>> I replied to your good comments and updated the wiki. Could we discuss
>> making the 3.1 branch and moving 3.0 branch to trunk?
>
> yeah, but lets talk about that in a different thread so we don't get
> mixed up. i have a couple more comments below ...
>
>
>>
>> -Elias
>>
>> Allen Gilliland wrote:
>>>
>
> *snip*
>
>>>>
>>>>> getAllTags() - how? this could return thousands of results
>>>> This is for tcloud (I forgot to mention that the return is not TagData
>>>> but TagCloudEntry (a pair of tagname and count)).
>>>>
>>>>> getAllTags(WebsiteData website) - again, how? why?
>>>> Website cloud of entry tags.
>>> doesn't that make it of even greater concern? i would still expect a
>>> decent sized site to have thousands of unique tags and then to get an
>>> aggregate count of each of those tags to return in this method would be
>>> a lot of data.
>>>
>>> i don't have a problem with this as long as the results can be limited
>>> some how.
>>>
>>>
>>
>> ok. I have been thinking of having a table
>>
>> create table websitetagcloud {
>> id
>> websiteid
>> name
>> count
>> };
>>
>> so we can return this data quickly and we can do some limits here such
>> as only tags with count > 1 or something like that. I've updated the
>> Wiki page with this and other changes.
>
> i like that idea. i'm not sure it's a 'cloud', its more of a tagcount
> or tagaggregate which is likely to be used to create the cloud. i
> actually see even more opportunity to extract relevant tag data into
> this table.
>
> would it also make sense to put the date in this table? that way a the
> tag count could be time sensitive, so you could restrict the set to tags
> used in a certain timeframe, like tags used within the last hour. it
> would also be cool to do counts given various timeframes, so a dayCnt,
> weekCnt, monthCnt, totalCnt. that way you could track what tags are
> popular for a given day or week. of course the downside to that is you
> have to worry about reseting those cnts :/
+1 although I wouldn't necessarily keep dayCnt in the table instead we
could convert the day, week, month to an integer and leave it in the
store, then for any given week for example, we just query 'WHERE
mode=week(or enum) and value=50' so we don't have to reset anything ever.
create table websitetagcloud {
id
websiteid
name
count
mode
value
};
Just brainstorming, but there might be better ways to do this in SQL. My
question is how to do this in Hibernate. For example:
WeblogEntryTagData.getTagSet();
In FolderData, you have private setTagSet and added
add/removeBookmark(). However, can't I always do this according to the
Hibernate Docs
WeblogEntryTagData.getTagSet().add(bookmarkData);
Anyways, I'm just trying to figure out how "manage" the aggregate table
using hibernate.
>
> is there any other aggregate data which could be useful in this table?
>
>
Not top of my head, but good idea on the time ranges, this could
definitely help a lot in regards to tag limits and very fresh "useful" data.
>>
>>>>> getTagsOrderByCount(WebsiteData website, int count) - ok, for cloud?
>>>> I guess we don't need a hottags for a specific site and could probably
>>>> be done with getAllTags(WebsiteData)
>>>>
>>>>> getTagsOrderByCount(int count) - ditch, just use method above
>>>> This is used for HotTags for the entire site.
>>> all of the ones where i said 'ditch, just use method above' i was trying
>>> to suggest that we only need the 1 method signature and if it accepts a
>>> website then that param is optional. so if the website is non-null then
>>> the results are restricted to the website, otherwise they apply to the
>>> site as a whole.
>>
>> I understood your suggestion and I'm taking it, I was just clarifying
>> the difference between the two calls.
>>
>>> that just cuts down on the number of methods and in all likelihood the
>>> implementation of getTagsOrderByCount(count) would have been just to
>>> call getTagsOrderByCount(null, count), so why have the extra method
>>> signature in the manager interface.
>>>
>>>
>>
>> +1
>>
>>>>> removeTag(String id) - ok, also need removeTag(tag)
>>>> +1
>>>>
>>>>> findTags(WebsiteData website, String pattern, int maxResults) - ok
>>>>> findTags(String pattern, int maxResults) - ditch, just use method
>>>>> above
>>>> +1
>>>>
>>>>> also, i think every method needs to have a 'limit' parameter to limit
>>>>> the result set and the maxResults should be configurable at the site
>>>>> wide level so that we can prevent methods provided to users from
>>>>> returning overly large result sets.
>>>> Could we use pagers instead? Limits feel too artificial for me and we
>>>> could be cutting out important information all of the time.
>>> Yes we can, although our concept of a pager isn't like an iterator where
>>> you want walk through the results one chunk at a time. it only gives a
>>> view of a portion of an overall collection and provides a standard way
>>> to link to alternate views of the collection. I'm not sure if that fits
>>> with what you are expecting to do.
>>>
>>>
>>
>> I think for somethings like getting hottest tags a pager would work,
>> since we can retrieve just the first page. Pagers will definitely be
>> useful when display entries for a specific tag, since that number is
>> unbounded. However, for tag cloud, not sure pagers would help much,
>> caching will be our friend.
>
> yep.
>
> -- Allen
>
>
>>
>>>>> none of the methods reference username, so that makes me think we
>>>>> don't
>>>>> really need the username associated with a tag.
>>>> My thoughts on username were for the case you want type-ahead on *your*
>>>> tags and not just a specific weblog. I think a personal tagcloud would
>>>> be nice. Disclaimer: I can't believe I'm asking for all these clouds
>>>> when in reality I'm not a big fan of them, but oh well. I guess
>>>> username
>>>> is important if more than one blog author exists, should we know who
>>>> entered which tag?
>>> That makes sense and I would think we definitely would want to do that.
>>> However, maybe the reference should be to user id then, since that is
>>> the primary key for a user. The problem with username is that it's not
>>> the primary key of the user table, and I believe that at some point we
>>> expect that users should be allowed to change their username.
>>
>> +1 fixed on the wiki.
>>
>>>
>>>>> the getAllTags() methods bother me a bit because i would think that on
>>>>> any site that gets a reasonable amount of usage those methods would
>>>>> return enormous result sets. what do we need them for anyways?
>>>> clouds. Would paging resolve the concern?
>>> yes, paging could help. Dave and I discussed but never implemented any
>>> restriction on pagers. Some pagers have natural boundries, like entries
>>> in a day, but the pager of the weblogs recent entries does not and it
>>> should.
>>>
>>> this would be another example of where a site owner should be allowed to
>>> restrict tag paging to a certain limit so that users can't abuse the
>>> data they are given access to.
>>
>> Definitely.
>>
>>> -- Allen
>>>
>>>
>>>>> everything else sounds about right, although it would be nice to see a
>>>>> bit more info about what methods we think are needed in the site and
>>>>> page models.
>>>> I'll give that more thinking later today.
>>>>
>>>>> -- Allen
>>>>>
>>>>>
>>>>> Elias Torres wrote:
>>>>>> I have updated the proposal on the wiki page for tagging. Please
>>>>>> comment/delete/change/add/etc to it. I'll be glad to discuss and
>>>>>> improve it.
>>>>>>
>>>>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_WeblogTags
>>>>>>
>>>>>> -Elias
>>>>>>
>>>>>> On 9/11/06, Elias Torres <el...@torrez.us> wrote:
>>>>>>> Hi Guys,
>>>>>>>
>>>>>>> We initially implemented a tagging function into Roller 2.0 (at
>>>>>>> IBM) but
>>>>>>> that really never made it into core because of my lack of effort in
>>>>>>> completing a few things that Allen had suggested before it was
>>>>>>> functional enough. I replied to his feedback answering some of the
>>>>>>> concerns (which I didn't think were major) [1], but I never got a
>>>>>>> direct
>>>>>>> reply to my email. We would like to move to 3.0+ but we can't until
>>>>>>> tagging is in place.
>>>>>>>
>>>>>>> There's the big decision to whether we support either categories or
>>>>>>> tags
>>>>>>> or both. I'm fine with supporting both as long as we can disable
>>>>>>> either
>>>>>>> one or none in the UI through roller.properties.
>>>>>>>
>>>>>>> I'm willing to code it in any specific way and don't have a set
>>>>>>> way in
>>>>>>> mind. I'm fine with use Lucene as Ian Kellen had suggested long
>>>>>>> time ago
>>>>>>> for performance and use the db just as a persistent storage. I'll
>>>>>>> very
>>>>>>> through and make sure there's a tab for the tag cloud, feeds and
>>>>>>> proper
>>>>>>> methods in beans, velocity models, etc.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Elias
>>>>>>>
>>>>>>> [1]
>>>>>>> http://www.nabble.com/Re%3A-Evalutating-tag-support-p3972587s12275.html
>>>>>>>
>>>>>>>
>>>>>>>
>
Re: Tagging support in Roller
Posted by Allen Gilliland <al...@sun.com>.
Elias Torres wrote:
> I replied to your good comments and updated the wiki. Could we discuss
> making the 3.1 branch and moving 3.0 branch to trunk?
yeah, but lets talk about that in a different thread so we don't get
mixed up. i have a couple more comments below ...
>
> -Elias
>
> Allen Gilliland wrote:
>>
*snip*
>>>
>>>> getAllTags() - how? this could return thousands of results
>>> This is for tcloud (I forgot to mention that the return is not TagData
>>> but TagCloudEntry (a pair of tagname and count)).
>>>
>>>> getAllTags(WebsiteData website) - again, how? why?
>>> Website cloud of entry tags.
>> doesn't that make it of even greater concern? i would still expect a
>> decent sized site to have thousands of unique tags and then to get an
>> aggregate count of each of those tags to return in this method would be
>> a lot of data.
>>
>> i don't have a problem with this as long as the results can be limited
>> some how.
>>
>>
>
> ok. I have been thinking of having a table
>
> create table websitetagcloud {
> id
> websiteid
> name
> count
> };
>
> so we can return this data quickly and we can do some limits here such
> as only tags with count > 1 or something like that. I've updated the
> Wiki page with this and other changes.
i like that idea. i'm not sure it's a 'cloud', its more of a tagcount
or tagaggregate which is likely to be used to create the cloud. i
actually see even more opportunity to extract relevant tag data into
this table.
would it also make sense to put the date in this table? that way a the
tag count could be time sensitive, so you could restrict the set to tags
used in a certain timeframe, like tags used within the last hour. it
would also be cool to do counts given various timeframes, so a dayCnt,
weekCnt, monthCnt, totalCnt. that way you could track what tags are
popular for a given day or week. of course the downside to that is you
have to worry about reseting those cnts :/
is there any other aggregate data which could be useful in this table?
>
>>>> getTagsOrderByCount(WebsiteData website, int count) - ok, for cloud?
>>> I guess we don't need a hottags for a specific site and could probably
>>> be done with getAllTags(WebsiteData)
>>>
>>>> getTagsOrderByCount(int count) - ditch, just use method above
>>> This is used for HotTags for the entire site.
>> all of the ones where i said 'ditch, just use method above' i was trying
>> to suggest that we only need the 1 method signature and if it accepts a
>> website then that param is optional. so if the website is non-null then
>> the results are restricted to the website, otherwise they apply to the
>> site as a whole.
>
> I understood your suggestion and I'm taking it, I was just clarifying
> the difference between the two calls.
>
>> that just cuts down on the number of methods and in all likelihood the
>> implementation of getTagsOrderByCount(count) would have been just to
>> call getTagsOrderByCount(null, count), so why have the extra method
>> signature in the manager interface.
>>
>>
>
> +1
>
>>>> removeTag(String id) - ok, also need removeTag(tag)
>>> +1
>>>
>>>> findTags(WebsiteData website, String pattern, int maxResults) - ok
>>>> findTags(String pattern, int maxResults) - ditch, just use method above
>>> +1
>>>
>>>> also, i think every method needs to have a 'limit' parameter to limit
>>>> the result set and the maxResults should be configurable at the site
>>>> wide level so that we can prevent methods provided to users from
>>>> returning overly large result sets.
>>> Could we use pagers instead? Limits feel too artificial for me and we
>>> could be cutting out important information all of the time.
>> Yes we can, although our concept of a pager isn't like an iterator where
>> you want walk through the results one chunk at a time. it only gives a
>> view of a portion of an overall collection and provides a standard way
>> to link to alternate views of the collection. I'm not sure if that fits
>> with what you are expecting to do.
>>
>>
>
> I think for somethings like getting hottest tags a pager would work,
> since we can retrieve just the first page. Pagers will definitely be
> useful when display entries for a specific tag, since that number is
> unbounded. However, for tag cloud, not sure pagers would help much,
> caching will be our friend.
yep.
-- Allen
>
>>>> none of the methods reference username, so that makes me think we don't
>>>> really need the username associated with a tag.
>>> My thoughts on username were for the case you want type-ahead on *your*
>>> tags and not just a specific weblog. I think a personal tagcloud would
>>> be nice. Disclaimer: I can't believe I'm asking for all these clouds
>>> when in reality I'm not a big fan of them, but oh well. I guess username
>>> is important if more than one blog author exists, should we know who
>>> entered which tag?
>> That makes sense and I would think we definitely would want to do that.
>> However, maybe the reference should be to user id then, since that is
>> the primary key for a user. The problem with username is that it's not
>> the primary key of the user table, and I believe that at some point we
>> expect that users should be allowed to change their username.
>
> +1 fixed on the wiki.
>
>>
>>>> the getAllTags() methods bother me a bit because i would think that on
>>>> any site that gets a reasonable amount of usage those methods would
>>>> return enormous result sets. what do we need them for anyways?
>>> clouds. Would paging resolve the concern?
>> yes, paging could help. Dave and I discussed but never implemented any
>> restriction on pagers. Some pagers have natural boundries, like entries
>> in a day, but the pager of the weblogs recent entries does not and it
>> should.
>>
>> this would be another example of where a site owner should be allowed to
>> restrict tag paging to a certain limit so that users can't abuse the
>> data they are given access to.
>
> Definitely.
>
>> -- Allen
>>
>>
>>>> everything else sounds about right, although it would be nice to see a
>>>> bit more info about what methods we think are needed in the site and
>>>> page models.
>>> I'll give that more thinking later today.
>>>
>>>> -- Allen
>>>>
>>>>
>>>> Elias Torres wrote:
>>>>> I have updated the proposal on the wiki page for tagging. Please
>>>>> comment/delete/change/add/etc to it. I'll be glad to discuss and
>>>>> improve it.
>>>>>
>>>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_WeblogTags
>>>>>
>>>>> -Elias
>>>>>
>>>>> On 9/11/06, Elias Torres <el...@torrez.us> wrote:
>>>>>> Hi Guys,
>>>>>>
>>>>>> We initially implemented a tagging function into Roller 2.0 (at
>>>>>> IBM) but
>>>>>> that really never made it into core because of my lack of effort in
>>>>>> completing a few things that Allen had suggested before it was
>>>>>> functional enough. I replied to his feedback answering some of the
>>>>>> concerns (which I didn't think were major) [1], but I never got a
>>>>>> direct
>>>>>> reply to my email. We would like to move to 3.0+ but we can't until
>>>>>> tagging is in place.
>>>>>>
>>>>>> There's the big decision to whether we support either categories or
>>>>>> tags
>>>>>> or both. I'm fine with supporting both as long as we can disable
>>>>>> either
>>>>>> one or none in the UI through roller.properties.
>>>>>>
>>>>>> I'm willing to code it in any specific way and don't have a set way in
>>>>>> mind. I'm fine with use Lucene as Ian Kellen had suggested long
>>>>>> time ago
>>>>>> for performance and use the db just as a persistent storage. I'll very
>>>>>> through and make sure there's a tab for the tag cloud, feeds and
>>>>>> proper
>>>>>> methods in beans, velocity models, etc.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Elias
>>>>>>
>>>>>> [1]
>>>>>> http://www.nabble.com/Re%3A-Evalutating-tag-support-p3972587s12275.html
>>>>>>
>>>>>>
Re: Tagging support in Roller
Posted by Elias Torres <el...@torrez.us>.
I replied to your good comments and updated the wiki. Could we discuss
making the 3.1 branch and moving 3.0 branch to trunk?
-Elias
Allen Gilliland wrote:
>
>
> Elias Torres wrote:
>>
>> Allen Gilliland wrote:
>>> Ok. I took another pass over the proposal and have a few thoughts/ideas
>>> I think we can talk about here on the list to get this moving.
>>
>> Excellent, thanks for taking a look at it.
>>
>>> 1. We should ditch the current branch based on roller 2.1 and recreate
>>> it using the 3.0 codebase, migrating whatever code is still relevant.
>>
>> +1
>>
>>> 2. I suggest we follow Anil's suggestion in the issues section and not
>>> try and make an decisions about categories vs. tags. That's definitely
>>> still an important debate, but I suggest we get tags going first then we
>>> can actually see how each is used and make a decision based on acquired
>>> feedback rather than speculation.
>>
>> +1
>>
>>> 3. I suggest we hold off on the tagging for weblogs and just do tags for
>>> weblog entries. This will just narrow the scope of the proposal a bit.
>>>
>>
>> +0 I hadn't noticed the suggestion until yesterday but it seems like a
>> fine idea. If we want to do it later, that's fine, but I don't mind
>> doing it together.
>
> I mainly suggested this to keep things simple. We know that we want
> tagging on entries, but tagging on weblogs could be debated. If we
> leave it out for now then the proposal means less work and greater
> liklihood that we can get it done in time. Plus, we don't even know if
> people really want tagging at the weblog level, it may be something that
> we would do that's not really all that useful.
>
> So I still suggest we strip it out and just do tagging on weblog entries.
>
>
I'm ok with it.
>>
>>> As far as the data model, classes, and methods are concerned ...
>>>
>>> i think the weblogentrytag table looks pretty good, but i'm wondering if
>>> we really need a reverence to username, what is that for? also, how is
>>> the tagtime supposed to work? does it only get set once when the tag is
>>> added or does it get updated when the tags are updated?
>>
>> tagtime is mostly for analysis of when a specific tag was inserted to
>> that entry, since authors can re-tag their entries. I'm fine with just
>> using entry modified time, but then the question is whether we duplicate
>> that time as well. For now, I'm fine with taking it out as well. What do
>> you think?
>>
>>> i'm not sure i understand all of the proposed manager method additions
>>> either ...
>>>
>>> getWebsiteTags(WebsiteData website) - not needed
>>
>> If we don't implement Website tagging.
>>
>>> getWeblogEntriesByTag(WebsiteData website, String tag) - ok
>>> getWeblogEntriesByTag(String tag) - ditch, just use method above
>>
>> +1
>>
>>> getAllTags() - how? this could return thousands of results
>>
>> This is for tcloud (I forgot to mention that the return is not TagData
>> but TagCloudEntry (a pair of tagname and count)).
>>
>>> getAllTags(WebsiteData website) - again, how? why?
>>
>> Website cloud of entry tags.
>
> doesn't that make it of even greater concern? i would still expect a
> decent sized site to have thousands of unique tags and then to get an
> aggregate count of each of those tags to return in this method would be
> a lot of data.
>
> i don't have a problem with this as long as the results can be limited
> some how.
>
>
ok. I have been thinking of having a table
create table websitetagcloud {
id
websiteid
name
count
};
so we can return this data quickly and we can do some limits here such
as only tags with count > 1 or something like that. I've updated the
Wiki page with this and other changes.
>>
>>> getTagsOrderByCount(WebsiteData website, int count) - ok, for cloud?
>>
>> I guess we don't need a hottags for a specific site and could probably
>> be done with getAllTags(WebsiteData)
>>
>>> getTagsOrderByCount(int count) - ditch, just use method above
>>
>> This is used for HotTags for the entire site.
>
> all of the ones where i said 'ditch, just use method above' i was trying
> to suggest that we only need the 1 method signature and if it accepts a
> website then that param is optional. so if the website is non-null then
> the results are restricted to the website, otherwise they apply to the
> site as a whole.
I understood your suggestion and I'm taking it, I was just clarifying
the difference between the two calls.
>
> that just cuts down on the number of methods and in all likelihood the
> implementation of getTagsOrderByCount(count) would have been just to
> call getTagsOrderByCount(null, count), so why have the extra method
> signature in the manager interface.
>
>
+1
>>
>>> removeTag(String id) - ok, also need removeTag(tag)
>>
>> +1
>>
>>> findTags(WebsiteData website, String pattern, int maxResults) - ok
>>> findTags(String pattern, int maxResults) - ditch, just use method above
>>
>> +1
>>
>>> also, i think every method needs to have a 'limit' parameter to limit
>>> the result set and the maxResults should be configurable at the site
>>> wide level so that we can prevent methods provided to users from
>>> returning overly large result sets.
>>
>> Could we use pagers instead? Limits feel too artificial for me and we
>> could be cutting out important information all of the time.
>
> Yes we can, although our concept of a pager isn't like an iterator where
> you want walk through the results one chunk at a time. it only gives a
> view of a portion of an overall collection and provides a standard way
> to link to alternate views of the collection. I'm not sure if that fits
> with what you are expecting to do.
>
>
I think for somethings like getting hottest tags a pager would work,
since we can retrieve just the first page. Pagers will definitely be
useful when display entries for a specific tag, since that number is
unbounded. However, for tag cloud, not sure pagers would help much,
caching will be our friend.
>>
>>> none of the methods reference username, so that makes me think we don't
>>> really need the username associated with a tag.
>>
>> My thoughts on username were for the case you want type-ahead on *your*
>> tags and not just a specific weblog. I think a personal tagcloud would
>> be nice. Disclaimer: I can't believe I'm asking for all these clouds
>> when in reality I'm not a big fan of them, but oh well. I guess username
>> is important if more than one blog author exists, should we know who
>> entered which tag?
>
> That makes sense and I would think we definitely would want to do that.
> However, maybe the reference should be to user id then, since that is
> the primary key for a user. The problem with username is that it's not
> the primary key of the user table, and I believe that at some point we
> expect that users should be allowed to change their username.
+1 fixed on the wiki.
>
>
>>
>>> the getAllTags() methods bother me a bit because i would think that on
>>> any site that gets a reasonable amount of usage those methods would
>>> return enormous result sets. what do we need them for anyways?
>>
>> clouds. Would paging resolve the concern?
>
> yes, paging could help. Dave and I discussed but never implemented any
> restriction on pagers. Some pagers have natural boundries, like entries
> in a day, but the pager of the weblogs recent entries does not and it
> should.
>
> this would be another example of where a site owner should be allowed to
> restrict tag paging to a certain limit so that users can't abuse the
> data they are given access to.
Definitely.
>
> -- Allen
>
>
>>
>>> everything else sounds about right, although it would be nice to see a
>>> bit more info about what methods we think are needed in the site and
>>> page models.
>>
>> I'll give that more thinking later today.
>>
>>> -- Allen
>>>
>>>
>>> Elias Torres wrote:
>>>> I have updated the proposal on the wiki page for tagging. Please
>>>> comment/delete/change/add/etc to it. I'll be glad to discuss and
>>>> improve it.
>>>>
>>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_WeblogTags
>>>>
>>>> -Elias
>>>>
>>>> On 9/11/06, Elias Torres <el...@torrez.us> wrote:
>>>>> Hi Guys,
>>>>>
>>>>> We initially implemented a tagging function into Roller 2.0 (at
>>>>> IBM) but
>>>>> that really never made it into core because of my lack of effort in
>>>>> completing a few things that Allen had suggested before it was
>>>>> functional enough. I replied to his feedback answering some of the
>>>>> concerns (which I didn't think were major) [1], but I never got a
>>>>> direct
>>>>> reply to my email. We would like to move to 3.0+ but we can't until
>>>>> tagging is in place.
>>>>>
>>>>> There's the big decision to whether we support either categories or
>>>>> tags
>>>>> or both. I'm fine with supporting both as long as we can disable
>>>>> either
>>>>> one or none in the UI through roller.properties.
>>>>>
>>>>> I'm willing to code it in any specific way and don't have a set way in
>>>>> mind. I'm fine with use Lucene as Ian Kellen had suggested long
>>>>> time ago
>>>>> for performance and use the db just as a persistent storage. I'll very
>>>>> through and make sure there's a tab for the tag cloud, feeds and
>>>>> proper
>>>>> methods in beans, velocity models, etc.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Elias
>>>>>
>>>>> [1]
>>>>> http://www.nabble.com/Re%3A-Evalutating-tag-support-p3972587s12275.html
>>>>>
>>>>>
>
Re: Tagging support in Roller
Posted by Allen Gilliland <al...@sun.com>.
Elias Torres wrote:
>
> Allen Gilliland wrote:
>> Ok. I took another pass over the proposal and have a few thoughts/ideas
>> I think we can talk about here on the list to get this moving.
>
> Excellent, thanks for taking a look at it.
>
>> 1. We should ditch the current branch based on roller 2.1 and recreate
>> it using the 3.0 codebase, migrating whatever code is still relevant.
>
> +1
>
>> 2. I suggest we follow Anil's suggestion in the issues section and not
>> try and make an decisions about categories vs. tags. That's definitely
>> still an important debate, but I suggest we get tags going first then we
>> can actually see how each is used and make a decision based on acquired
>> feedback rather than speculation.
>
> +1
>
>> 3. I suggest we hold off on the tagging for weblogs and just do tags for
>> weblog entries. This will just narrow the scope of the proposal a bit.
>>
>
> +0 I hadn't noticed the suggestion until yesterday but it seems like a
> fine idea. If we want to do it later, that's fine, but I don't mind
> doing it together.
I mainly suggested this to keep things simple. We know that we want
tagging on entries, but tagging on weblogs could be debated. If we
leave it out for now then the proposal means less work and greater
liklihood that we can get it done in time. Plus, we don't even know if
people really want tagging at the weblog level, it may be something that
we would do that's not really all that useful.
So I still suggest we strip it out and just do tagging on weblog entries.
>
>> As far as the data model, classes, and methods are concerned ...
>>
>> i think the weblogentrytag table looks pretty good, but i'm wondering if
>> we really need a reverence to username, what is that for? also, how is
>> the tagtime supposed to work? does it only get set once when the tag is
>> added or does it get updated when the tags are updated?
>
> tagtime is mostly for analysis of when a specific tag was inserted to
> that entry, since authors can re-tag their entries. I'm fine with just
> using entry modified time, but then the question is whether we duplicate
> that time as well. For now, I'm fine with taking it out as well. What do
> you think?
>
>> i'm not sure i understand all of the proposed manager method additions
>> either ...
>>
>> getWebsiteTags(WebsiteData website) - not needed
>
> If we don't implement Website tagging.
>
>> getWeblogEntriesByTag(WebsiteData website, String tag) - ok
>> getWeblogEntriesByTag(String tag) - ditch, just use method above
>
> +1
>
>> getAllTags() - how? this could return thousands of results
>
> This is for tcloud (I forgot to mention that the return is not TagData
> but TagCloudEntry (a pair of tagname and count)).
>
>> getAllTags(WebsiteData website) - again, how? why?
>
> Website cloud of entry tags.
doesn't that make it of even greater concern? i would still expect a
decent sized site to have thousands of unique tags and then to get an
aggregate count of each of those tags to return in this method would be
a lot of data.
i don't have a problem with this as long as the results can be limited
some how.
>
>> getTagsOrderByCount(WebsiteData website, int count) - ok, for cloud?
>
> I guess we don't need a hottags for a specific site and could probably
> be done with getAllTags(WebsiteData)
>
>> getTagsOrderByCount(int count) - ditch, just use method above
>
> This is used for HotTags for the entire site.
all of the ones where i said 'ditch, just use method above' i was trying
to suggest that we only need the 1 method signature and if it accepts a
website then that param is optional. so if the website is non-null then
the results are restricted to the website, otherwise they apply to the
site as a whole.
that just cuts down on the number of methods and in all likelihood the
implementation of getTagsOrderByCount(count) would have been just to
call getTagsOrderByCount(null, count), so why have the extra method
signature in the manager interface.
>
>> removeTag(String id) - ok, also need removeTag(tag)
>
> +1
>
>> findTags(WebsiteData website, String pattern, int maxResults) - ok
>> findTags(String pattern, int maxResults) - ditch, just use method above
>
> +1
>
>> also, i think every method needs to have a 'limit' parameter to limit
>> the result set and the maxResults should be configurable at the site
>> wide level so that we can prevent methods provided to users from
>> returning overly large result sets.
>
> Could we use pagers instead? Limits feel too artificial for me and we
> could be cutting out important information all of the time.
Yes we can, although our concept of a pager isn't like an iterator where
you want walk through the results one chunk at a time. it only gives a
view of a portion of an overall collection and provides a standard way
to link to alternate views of the collection. I'm not sure if that fits
with what you are expecting to do.
>
>> none of the methods reference username, so that makes me think we don't
>> really need the username associated with a tag.
>
> My thoughts on username were for the case you want type-ahead on *your*
> tags and not just a specific weblog. I think a personal tagcloud would
> be nice. Disclaimer: I can't believe I'm asking for all these clouds
> when in reality I'm not a big fan of them, but oh well. I guess username
> is important if more than one blog author exists, should we know who
> entered which tag?
That makes sense and I would think we definitely would want to do that.
However, maybe the reference should be to user id then, since that is
the primary key for a user. The problem with username is that it's not
the primary key of the user table, and I believe that at some point we
expect that users should be allowed to change their username.
>
>> the getAllTags() methods bother me a bit because i would think that on
>> any site that gets a reasonable amount of usage those methods would
>> return enormous result sets. what do we need them for anyways?
>
> clouds. Would paging resolve the concern?
yes, paging could help. Dave and I discussed but never implemented any
restriction on pagers. Some pagers have natural boundries, like entries
in a day, but the pager of the weblogs recent entries does not and it
should.
this would be another example of where a site owner should be allowed to
restrict tag paging to a certain limit so that users can't abuse the
data they are given access to.
-- Allen
>
>> everything else sounds about right, although it would be nice to see a
>> bit more info about what methods we think are needed in the site and
>> page models.
>
> I'll give that more thinking later today.
>
>> -- Allen
>>
>>
>> Elias Torres wrote:
>>> I have updated the proposal on the wiki page for tagging. Please
>>> comment/delete/change/add/etc to it. I'll be glad to discuss and
>>> improve it.
>>>
>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_WeblogTags
>>>
>>> -Elias
>>>
>>> On 9/11/06, Elias Torres <el...@torrez.us> wrote:
>>>> Hi Guys,
>>>>
>>>> We initially implemented a tagging function into Roller 2.0 (at IBM) but
>>>> that really never made it into core because of my lack of effort in
>>>> completing a few things that Allen had suggested before it was
>>>> functional enough. I replied to his feedback answering some of the
>>>> concerns (which I didn't think were major) [1], but I never got a direct
>>>> reply to my email. We would like to move to 3.0+ but we can't until
>>>> tagging is in place.
>>>>
>>>> There's the big decision to whether we support either categories or tags
>>>> or both. I'm fine with supporting both as long as we can disable either
>>>> one or none in the UI through roller.properties.
>>>>
>>>> I'm willing to code it in any specific way and don't have a set way in
>>>> mind. I'm fine with use Lucene as Ian Kellen had suggested long time ago
>>>> for performance and use the db just as a persistent storage. I'll very
>>>> through and make sure there's a tab for the tag cloud, feeds and proper
>>>> methods in beans, velocity models, etc.
>>>>
>>>> Thanks,
>>>>
>>>> Elias
>>>>
>>>> [1]
>>>> http://www.nabble.com/Re%3A-Evalutating-tag-support-p3972587s12275.html
>>>>
Re: Tagging support in Roller
Posted by Elias Torres <el...@torrez.us>.
Allen Gilliland wrote:
> Ok. I took another pass over the proposal and have a few thoughts/ideas
> I think we can talk about here on the list to get this moving.
Excellent, thanks for taking a look at it.
>
> 1. We should ditch the current branch based on roller 2.1 and recreate
> it using the 3.0 codebase, migrating whatever code is still relevant.
+1
>
> 2. I suggest we follow Anil's suggestion in the issues section and not
> try and make an decisions about categories vs. tags. That's definitely
> still an important debate, but I suggest we get tags going first then we
> can actually see how each is used and make a decision based on acquired
> feedback rather than speculation.
+1
>
> 3. I suggest we hold off on the tagging for weblogs and just do tags for
> weblog entries. This will just narrow the scope of the proposal a bit.
>
+0 I hadn't noticed the suggestion until yesterday but it seems like a
fine idea. If we want to do it later, that's fine, but I don't mind
doing it together.
> As far as the data model, classes, and methods are concerned ...
>
> i think the weblogentrytag table looks pretty good, but i'm wondering if
> we really need a reverence to username, what is that for? also, how is
> the tagtime supposed to work? does it only get set once when the tag is
> added or does it get updated when the tags are updated?
tagtime is mostly for analysis of when a specific tag was inserted to
that entry, since authors can re-tag their entries. I'm fine with just
using entry modified time, but then the question is whether we duplicate
that time as well. For now, I'm fine with taking it out as well. What do
you think?
>
> i'm not sure i understand all of the proposed manager method additions
> either ...
>
> getWebsiteTags(WebsiteData website) - not needed
If we don't implement Website tagging.
> getWeblogEntriesByTag(WebsiteData website, String tag) - ok
> getWeblogEntriesByTag(String tag) - ditch, just use method above
+1
> getAllTags() - how? this could return thousands of results
This is for tcloud (I forgot to mention that the return is not TagData
but TagCloudEntry (a pair of tagname and count)).
> getAllTags(WebsiteData website) - again, how? why?
Website cloud of entry tags.
> getTagsOrderByCount(WebsiteData website, int count) - ok, for cloud?
I guess we don't need a hottags for a specific site and could probably
be done with getAllTags(WebsiteData)
> getTagsOrderByCount(int count) - ditch, just use method above
This is used for HotTags for the entire site.
> removeTag(String id) - ok, also need removeTag(tag)
+1
> findTags(WebsiteData website, String pattern, int maxResults) - ok
> findTags(String pattern, int maxResults) - ditch, just use method above
+1
>
> also, i think every method needs to have a 'limit' parameter to limit
> the result set and the maxResults should be configurable at the site
> wide level so that we can prevent methods provided to users from
> returning overly large result sets.
Could we use pagers instead? Limits feel too artificial for me and we
could be cutting out important information all of the time.
>
> none of the methods reference username, so that makes me think we don't
> really need the username associated with a tag.
My thoughts on username were for the case you want type-ahead on *your*
tags and not just a specific weblog. I think a personal tagcloud would
be nice. Disclaimer: I can't believe I'm asking for all these clouds
when in reality I'm not a big fan of them, but oh well. I guess username
is important if more than one blog author exists, should we know who
entered which tag?
>
> the getAllTags() methods bother me a bit because i would think that on
> any site that gets a reasonable amount of usage those methods would
> return enormous result sets. what do we need them for anyways?
clouds. Would paging resolve the concern?
>
> everything else sounds about right, although it would be nice to see a
> bit more info about what methods we think are needed in the site and
> page models.
I'll give that more thinking later today.
>
> -- Allen
>
>
> Elias Torres wrote:
>> I have updated the proposal on the wiki page for tagging. Please
>> comment/delete/change/add/etc to it. I'll be glad to discuss and
>> improve it.
>>
>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_WeblogTags
>>
>> -Elias
>>
>> On 9/11/06, Elias Torres <el...@torrez.us> wrote:
>>> Hi Guys,
>>>
>>> We initially implemented a tagging function into Roller 2.0 (at IBM) but
>>> that really never made it into core because of my lack of effort in
>>> completing a few things that Allen had suggested before it was
>>> functional enough. I replied to his feedback answering some of the
>>> concerns (which I didn't think were major) [1], but I never got a direct
>>> reply to my email. We would like to move to 3.0+ but we can't until
>>> tagging is in place.
>>>
>>> There's the big decision to whether we support either categories or tags
>>> or both. I'm fine with supporting both as long as we can disable either
>>> one or none in the UI through roller.properties.
>>>
>>> I'm willing to code it in any specific way and don't have a set way in
>>> mind. I'm fine with use Lucene as Ian Kellen had suggested long time ago
>>> for performance and use the db just as a persistent storage. I'll very
>>> through and make sure there's a tab for the tag cloud, feeds and proper
>>> methods in beans, velocity models, etc.
>>>
>>> Thanks,
>>>
>>> Elias
>>>
>>> [1]
>>> http://www.nabble.com/Re%3A-Evalutating-tag-support-p3972587s12275.html
>>>
>
Re: Tagging support in Roller
Posted by Allen Gilliland <al...@sun.com>.
Ok. I took another pass over the proposal and have a few thoughts/ideas
I think we can talk about here on the list to get this moving.
1. We should ditch the current branch based on roller 2.1 and recreate
it using the 3.0 codebase, migrating whatever code is still relevant.
2. I suggest we follow Anil's suggestion in the issues section and not
try and make an decisions about categories vs. tags. That's definitely
still an important debate, but I suggest we get tags going first then we
can actually see how each is used and make a decision based on acquired
feedback rather than speculation.
3. I suggest we hold off on the tagging for weblogs and just do tags for
weblog entries. This will just narrow the scope of the proposal a bit.
As far as the data model, classes, and methods are concerned ...
i think the weblogentrytag table looks pretty good, but i'm wondering if
we really need a reverence to username, what is that for? also, how is
the tagtime supposed to work? does it only get set once when the tag is
added or does it get updated when the tags are updated?
i'm not sure i understand all of the proposed manager method additions
either ...
getWebsiteTags(WebsiteData website) - not needed
getWeblogEntriesByTag(WebsiteData website, String tag) - ok
getWeblogEntriesByTag(String tag) - ditch, just use method above
getAllTags() - how? this could return thousands of results
getAllTags(WebsiteData website) - again, how? why?
getTagsOrderByCount(WebsiteData website, int count) - ok, for cloud?
getTagsOrderByCount(int count) - ditch, just use method above
removeTag(String id) - ok, also need removeTag(tag)
findTags(WebsiteData website, String pattern, int maxResults) - ok
findTags(String pattern, int maxResults) - ditch, just use method above
also, i think every method needs to have a 'limit' parameter to limit
the result set and the maxResults should be configurable at the site
wide level so that we can prevent methods provided to users from
returning overly large result sets.
none of the methods reference username, so that makes me think we don't
really need the username associated with a tag.
the getAllTags() methods bother me a bit because i would think that on
any site that gets a reasonable amount of usage those methods would
return enormous result sets. what do we need them for anyways?
everything else sounds about right, although it would be nice to see a
bit more info about what methods we think are needed in the site and
page models.
-- Allen
Elias Torres wrote:
> I have updated the proposal on the wiki page for tagging. Please
> comment/delete/change/add/etc to it. I'll be glad to discuss and
> improve it.
>
> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_WeblogTags
>
> -Elias
>
> On 9/11/06, Elias Torres <el...@torrez.us> wrote:
>> Hi Guys,
>>
>> We initially implemented a tagging function into Roller 2.0 (at IBM) but
>> that really never made it into core because of my lack of effort in
>> completing a few things that Allen had suggested before it was
>> functional enough. I replied to his feedback answering some of the
>> concerns (which I didn't think were major) [1], but I never got a direct
>> reply to my email. We would like to move to 3.0+ but we can't until
>> tagging is in place.
>>
>> There's the big decision to whether we support either categories or tags
>> or both. I'm fine with supporting both as long as we can disable either
>> one or none in the UI through roller.properties.
>>
>> I'm willing to code it in any specific way and don't have a set way in
>> mind. I'm fine with use Lucene as Ian Kellen had suggested long time ago
>> for performance and use the db just as a persistent storage. I'll very
>> through and make sure there's a tab for the tag cloud, feeds and proper
>> methods in beans, velocity models, etc.
>>
>> Thanks,
>>
>> Elias
>>
>> [1]
>> http://www.nabble.com/Re%3A-Evalutating-tag-support-p3972587s12275.html
>>
Re: Tagging support in Roller
Posted by Elias Torres <el...@torrez.us>.
I have updated the proposal on the wiki page for tagging. Please
comment/delete/change/add/etc to it. I'll be glad to discuss and
improve it.
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_WeblogTags
-Elias
On 9/11/06, Elias Torres <el...@torrez.us> wrote:
> Hi Guys,
>
> We initially implemented a tagging function into Roller 2.0 (at IBM) but
> that really never made it into core because of my lack of effort in
> completing a few things that Allen had suggested before it was
> functional enough. I replied to his feedback answering some of the
> concerns (which I didn't think were major) [1], but I never got a direct
> reply to my email. We would like to move to 3.0+ but we can't until
> tagging is in place.
>
> There's the big decision to whether we support either categories or tags
> or both. I'm fine with supporting both as long as we can disable either
> one or none in the UI through roller.properties.
>
> I'm willing to code it in any specific way and don't have a set way in
> mind. I'm fine with use Lucene as Ian Kellen had suggested long time ago
> for performance and use the db just as a persistent storage. I'll very
> through and make sure there's a tab for the tag cloud, feeds and proper
> methods in beans, velocity models, etc.
>
> Thanks,
>
> Elias
>
> [1] http://www.nabble.com/Re%3A-Evalutating-tag-support-p3972587s12275.html
>