If you think that the post should be tagged "astronomy" and "radio
astronomy", why is it not ok to tag it "tags:radio astronomy" so that
radio+astronomy and astronomy will find the content?
I sort of agree with your comments on using radioastronomy (false, ugky
and long compund noun) and agree with your comments about using
surrogates for space.
I don't get why its the space as delemiter that's wrong.
Ian Kallen wrote:
IMO, the spaces-as-tag-delimiter folks have it wrong since it forces
hostile use of language; "radioastronomy" isn't a real compound word
and it's hard on the eye.
The driving principle should be human usefulness to identify and
organize what the post is about. In your case, you really would want
both "astronomy" and "radio astronomy" ... there's not a lot of
throughput on the latter (see
http://technorati.com/tag/radio+astronomy) but the stronger the
co-occurrence the more related the tags are (which is good, btw); in
other words there's a strong relationship between these two but not
with "radio" and tag relationships help inferred topicality emerge.
Technorati will normalize "radio astronomy" to "radioastronomy" (but
we don't do the reverse lexical analysis) at query time, however the
former is more readable. We do this normalization as a convenience
since it's rarely wrong but I don't think the compound words are
people friendly. When folks tag with artificial compound words,
underscores, plus signs, etc I don't think it adds to human
readability (underscores are stripped in our queries and the plus
signs are treated as url encoded). Naturally, links have to be URL
encoded; so tagging your post this way seems quite natural and
informative
<a href="http://technorati.com/tag/radio+astronomy"; rel="tag">radio
astronomy</a>
<a href="http://technorati.com/tag/astronomy"; rel="tag">astronomy</a>
-Ian
Jeffrey Blattman wrote:
maybe it's because i don't really "get" tagging, but what confuses me
is that some tags cannot be represented w/ a single word. for
example, i might want to tag something with "radio astronomy".
tagging it with "radio" or "astronomy" doesn't capture the intent at
all. i would naturally want/try to quote the phrase.
p.s., you can use the "+" char to encode a space in a url ... a
little nicer than %2 or whatever.
Allen Gilliland wrote:
My opinion is that the way it works now is still the best, where
tags have to be a single word and if you want to do phrases then use
underscores or dashes.
I think the main reason against allowing for tag phrases is
complexity. You are increasing the complexity both on the user
input side as well as on the retrieval side and for what I consider
a marginal benefit. On the UI side of things I think it's confusing
to many users to allow for quoted phrases. Then on the retrieval
side you are also confusing things because how do you get at the url
for "modern art"? /tags/modern%2Bart ... that's not something users
can type in by hand which is part of what's nice about forcing
single word tags.
As for Elias' suggestion of allowing phrases and converting the
spaces to underscores, I think that's a little dicey. For one, it
still leaves the user confusion aspect around using quoted phrases,
which I believe most users don't really want. On the technical side
I think you may be playing with fire though because why should the
tag "modern art" become modern_art instead of modern-art. And
regardless of which you convert to, is that the value stored in the
db? That would mean that when the user comes back to that entry the
tags list will show modern_art instead of their original tag phrase
which can be confusing for users as well.
My belief is that the reason why tagging has been successful at
places like del.icio.us and flickr is because the rules are short
and simple. Tags are separated by spaces, period. It's a slight
blow in functionality but keeps the usability as simple and easy as
possible.
-- Allen
Anil Gangolli wrote:
Oh. I must have missed the discussion about not supporting spaces
in tags because I would at least have made an attempt to convince
people to support spaces in tags.
It comes up for tags like "modern art" that are not really
meaningful to separate.
Regarding Elias's proposal, I initially felt against it, because
I'd rather use real spaces in the tags. That's still the case, but
less so, because I did a quick Technorati sampling, and there
already seems to be a sizable rift between the true space users and
the underscore users.
So for example Technorati lists 494 posts using "modern_art"
compared to 981 using "modern art" and differences in the thousands
for "george bush" compared to "george_bush", with the latter tag
far in the lead.
--a.
----- Original Message ----- From: "Elias Torres" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, November 22, 2006 4:09 PM
Subject: Re: Apache Roller 3.1RC1 (incubating) ready for testing
Allen Gilliland wrote:
Anil Gangolli wrote:
I installed 3.1RC1 on my dev box. Seemed to be clean using a
fresh db
installation and 3.0 required-jars package.
I was trying the tag-related functionality out and I see a few
issues:
(1) The tag entry field on the entry edit page uses space
separation
and doesn't seem to accomodate tags that include spaces. I tried
quoting with double-quotes; that didn't seem to work.
Yes, that is the expected behavior. We talked about this when we
were
evaluating the tags proposal and decided that most sites seem to be
using the solution that we have, where tags cannot be multi word
phrases.
I now have a requirement at IBM to support spaces with the following
caveat. If you enter "elias is cool" it will be stored as
elias_is_cool.
In other words, we support it as an input (double quotes) but we
don't
store it that way. Are you guys cool with it?
-Elias
(2) The user guide link in the JSP footer seems to point off to
an old
2.x guide. I was looking for and couldn't find the
documentation in
the 3.1 guides on the various forms of URLs, specifically I was
looking to test the tag-based URLs. I know I've seen it somewhere,
but I can't remember where.
Hmm. For the user guide I think it would be nice if these kinds of
links pointed to urls within the app, like /roller-ui/docs/*, for
user
documentation about the current app version.
I may also take this opportunity to throw out an idea I had a little
while ago for documentation that was related to this. It seems
to me
that since blogging is supposed to website publishing made easy
then one
of the key components of a really mature blog system would be good
documentation throughout the application. I haven't been a big
documentation contributor in the past, but I think that's more
because I
felt the app needed more work and less docs at the time. Now
that the
app is getting more and more mature it may be time to consider a
nice
solution for providing rich documentation.
So what I had been thinking about was a way where we could write
all of
our documentation in small and easily reusable components,
possibly in
xml, which we could easily use to either 1) provide a full help
guide
document (aka user guide) or 2) take bits and pieces of the docs
and be
able to insert them directly into the appropriate pages.
So for example, if a user is on the 'Templates' page and is
working on
customizing their blog then we could have some documentation
hooks which
provide contextual help info like ...
1. what is this page for?
2. what can i do on this page?
3. how do i use this page?
4. what do each of the fields on this page mean?
5. how does this affect my blog?
So for the 'Templates' page the top of the page may provide quick
links
which give a couple paragraphs of text explaining what the page
is for
and what you do on the page. Then you have the large text area
where
you can modify your templates which could have a little tool tip
icon
next to it which would tell the user what that field is for. Then
possibly at the bottom of the page we include a quick reference
sheet of
the models and macros to help users while they are authoring
templates.
One of the things that I think Roller has been hurting on is
usability
and in my mind of the most important elements of usability when
it comes
to web tools is contextual documentation. I think doing
something like
this could really help make Roller a more user friendly blogging
system.
(3) Tags don't seem to be displayed anywhere in the "basic"
theme at
all. Shouldn't we update this to show tags on entries, including an
actual rel tag ?
I think there may not have been any real consensus about whether
or not
to promote tags in the themes since in many cases users may not
be using
tags.
(4) I couldn't get anything to show up in the "Hot Tags" area of
the
front page. Haven't investigated what is happening yet; this
may be
my own problem.
Dunno about that one.
-- Allen
--a.
----- Original Message ----- From: "Dave" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, November 20, 2006 5:57 PM
Subject: Apache Roller 3.1RC1 (incubating) ready for testing
Thank you and yes, I meant 3.1.
With releasing 3.1, re-releasing 2.3.1 and working on 3.2 I've
got a
couple
too many versions floating around in my head.
- Dave
On 11/20/06, Jeffrey Blattman <[EMAIL PROTECTED]> wrote:
did you mean 3.1 RC1, or are we skipping 3.1?
Dave wrote:
> I've merged all applicable bug fixes from trunk to the
roller_3.1
> branch and prepared a first release candidate for the 3.1
release.
You
> can find the release files and latest 3.1 docs here:
>
> http://people.apache.org/~snoopdave/apache-roller-3.1/
>
> Here's the What's New in Roller 3.1 page:
>
http://rollerweblogger.org/wiki/Wiki.jsp?page=Roller_3.1_WhatsNew
>
> Release candidates are for testing purposes only.
>
> Please help out. The sooner you download, test and report
bugs the
> sooner we'll be able to fix them and get the release out. So
please
> help out the project and take RC1 for a spin.
>
> - Dave
--
Dave
*David Levy *
*Principal Engineer*
*Sun Microsystems Ltd.*
55, King William St.,
London EC4R 9ND
United Kingdom
Phone +44 (0) 20 7469 9908/x18308
Mobile +44 (0) 7710-360922
Blog http://blogs.sun.com/DaveLevy
Email [EMAIL PROTECTED]
Sun Proprietary & Confidential . This e-mail message is for the sole use
of the intended recipient(s) and may contain confidential and
privilidged information. Any unauthorised review, use, disclosure or
distribution is prohibited. If you are not the intended recepient,
please contact the sender by reply e-mail and destroy all copies of the
original message.
