Categories with a Common Directory?

Folks,

I want to assign the bulk of my site's stories to categories
for which  
I don't want unique directory names in the URL. Whether
fiction,  
poetry, or nonfiction, I want all stories to be under
"/articles/",  
not "/fiction/" or "/poetry/" (or even
"/articles/fiction/".) But it's  
important that I maintain metadata indicating whether each
of these  
stories is fiction, poetry, or nonfiction (or a book review,
a  
dispatch, a gallery, or any of a half dozen other sections
of our  
magazine) -- after all, we can't go presenting a work of
fiction (such  
as our obituary for James Frey) and having people believing
it's true.  
Also, we group the contents of each issue by these
categories.

Are categories more flexible than they appear to be? Or is
my solution  
to simply ignore Bricolage's concept of categories and
create a new  
custom field for the Story element in which I can store each
story's  
category?

Best,
Waldo

---
Virginia Quarterly Review
One West Range, Box 400223
University of Virginia
Charlottesville, VA 22904-4223

Waldo Jaquith wrote:
> Are categories more flexible than they appear to be? Or
is my solution 
> to simply ignore Bricolage's concept of categories and
create a new 
> custom field for the Story element in which I can store
each story's 
> category?

We use multiple categories on the Insight on Conflict site
to drive the 
Topics section (http
://www.insightonconflict.org/categorisation/).

Assign your story to /articles as the primary category and
then to as 
many secondary categories as you need:

/type/fiction
/type/poetry
/type/review
...

What you do with the secondary categories at burn time is up
to you - 
Bricolage will attempt to burn the story in each of the
categories. We 
call $m->clear_buffer; $m->abort; in the secondary
category autohandler 
to stop Bricolage outputting anything. We then have a
separate cover 
story that looks up all the stories in a secondary category
and creates 
the topic list that you see.

It's really very flexible.

S.

-- 
Digital Craftsmen Ltd
Exmouth House, 3 Pine Street, bond. EC1R 0JH
t 020 7183 1410 f 020 7099 5140 m 07951 758698
w http://www.digitalcr
aftsmen.net/

> I want to assign the bulk of my site's stories to
categories for which
> I don't want unique directory names in the URL. Whether
fiction,
> poetry, or nonfiction, I want all stories to be under
"/articles/",
> not "/fiction/" or "/poetry/" (or
even "/articles/fiction/".) But it's
> important that I maintain metadata indicating whether
each of these
> stories is fiction, poetry, or nonfiction (or a book
review, a
> dispatch, a gallery, or any of a half dozen other
sections of our
> magazine) -- after all, we can't go presenting a work
of fiction (such
> as our obituary for James Frey) and having people
believing it's true.
> Also, we group the contents of each issue by these
categories.

Waldo, perhaps you could use Bricolage keywords for this
purpose?
Likewise, you could create a subelement that is a
multi-select dropdown
with a defined list of options (fiction, poetry,
nonfiction)? You can
then program your templates to use this information as you
wish.

Chris


--------------------------------

Chris Schults
Web Developer
PCC Natural Markets
206-547-1222 x104
chris.schultspccsea.com
http://www.pccnatura
lmarkets.com 

On Apr 17, 2008, at 08:23, Waldo Jaquith wrote:

> I want to assign the bulk of my site's stories to
categories for  
> which I don't want unique directory names in the URL.
Whether  
> fiction, poetry, or nonfiction, I want all stories to
be under "/ 
> articles/", not "/fiction/" or
"/poetry/" (or even "/articles/ 
> fiction/".

Um, why? Search engines like descriptive URLs.

Best,

David

On Apr 17, 2008, at 2:08 PM, David E. Wheeler wrote:
> On Apr 17, 2008, at 08:23, Waldo Jaquith wrote:
>> I want to assign the bulk of my site's stories to
categories for  
>> which I don't want unique directory names in the
URL. Whether  
>> fiction, poetry, or nonfiction, I want all stories
to be under "/ 
>> articles/", not "/fiction/" or
"/poetry/" (or even "/articles/ 
>> fiction/".
>
> Um, why? Search engines like descriptive URLs.

There are a few reasons. The first is that it wouldn't make
sense  
within the scope of our directory structure. We keep all of
the  
content for all issues in /articles/year/season/slug/. It's
simply  
illogical to present it as
/articles/category/year/season/slug/ or as / 
category/year/season/slug/. (It implies a division of our
content,  
site-wide, by the genre of the work. That's not a division
that we  
make or care to make.) The second is that this is how we do
it *now*,  
and it's always difficult to change the URLs of thousands of
pages.  
The third is that the URLs would become entirely too long.
And the  
fourth is that the additional information, while more
descriptive,  
wouldn't add any substantially useful information for our
readers.

Were I inventing our site structure from the ground up, I
believe I'd  
want to find some way to incorporate genre information in
the URL in  
lieu of "/articles/". But my task with Bricolage
is to have the site  
entirely unchanged, from the public's perspective. If I do
my job  
correctly, nobody will have the slightest idea that we've
switched  
CMSs, at least at first. They might figure it out when I'm
freed up to  
add all sorts of great new features to the website. 

Simon and Chris, thank you very much for your suggestions.
In  
particular, Chris, it hadn't crossed my mind that keywords
could be  
useful for this purpose, but it makes perfect sense. I'm not
sure  
which of the two approaches that I'll take, but in importing
all of my  
existing content, I believe I'll allow for each
possibility.

Best,
Waldo

---
Virginia Quarterly Review
One West Range, Box 400223
University of Virginia
Charlottesville, VA 22904-4223

On Apr 17, 2008, at 11:30, Waldo Jaquith wrote:

> There are a few reasons. The first is that it wouldn't
make sense  
> within the scope of our directory structure. We keep
all of the  
> content for all issues in /articles/year/season/slug/.
It's simply  
> illogical to present it as
/articles/category/year/season/slug/ or  
> as /category/year/season/slug/. (It implies a division
of our  
> content, site-wide, by the genre of the work. That's
not a division  
> that we make or care to make.)

In that case, I personally wouldn't use /articles. I'd just
put  
everything in the root category, so you got
/year/season/slug. / 
articles/ is just redundant.

> The second is that this is how we do it *now*, and it's
always  
> difficult to change the URLs of thousands of pages.

Yah, backward compatibility is important.

> The third is that the URLs would become entirely too
long. And the  
> fourth is that the additional information, while more
descriptive,  
> wouldn't add any substantially useful information for
our readers.

It's not for your readers, it's for the search engine
(although I  
personally get a lot out of descriptive URLs, but I'm a
geek).

> Were I inventing our site structure from the ground up,
I believe  
> I'd want to find some way to incorporate genre
information in the  
> URL in lieu of "/articles/". But my task with
Bricolage is to have  
> the site entirely unchanged, from the public's
perspective. If I do  
> my job correctly, nobody will have the slightest idea
that we've  
> switched CMSs, at least at first. They might figure it
out when I'm  
> freed up to add all sorts of great new features to the
website. 

Right, that makes sense, and is pretty standard. Legacy is
important,  
FBOFW.

> Simon and Chris, thank you very much for your
suggestions. In  
> particular, Chris, it hadn't crossed my mind that
keywords could be  
> useful for this purpose, but it makes perfect sense.
I'm not sure  
> which of the two approaches that I'll take, but in
importing all of  
> my existing content, I believe I'll allow for each
possibility.

I think that key words are better for this, unless you're
also using  
them for something else (like keywords for your documents),
in which  
case I'd go with the secondary category solution (which I
first did  
for Macworld back in the day).

Best,

David

> Simon and Chris, thank you very much for your
suggestions. In
> particular, Chris, it hadn't crossed my mind that
keywords could be
> useful for this purpose, but it makes perfect sense.
I'm not sure
> which of the two approaches that I'll take, but in
importing all of my
> existing content, I believe I'll allow for each
possibility.

You're welcome Waldo. As for keywords, they're great as you
can search
for stories by them. However, keep in mind that keywords are
added via
text fields and are case sensitive (IIRC). Thus, your users
could use
"nonfiction", "Nonfiction",
"non-fiction" and "Non-fiction", which
would
treated as separate keywords.

Chris


--------------------------------

Chris Schults
Web Developer
PCC Natural Markets
206-547-1222 x104
chris.schultspccsea.com
http://www.pccnatura
lmarkets.com 

On Apr 17, 2008, at 2:38 PM, David E. Wheeler wrote:
> On Apr 17, 2008, at 11:30, Waldo Jaquith wrote:
>> There are a few reasons. The first is that it
wouldn't make sense  
>> within the scope of our directory structure. We
keep all of the  
>> content for all issues in
/articles/year/season/slug/. It's simply  
>> illogical to present it as
/articles/category/year/season/slug/ or  
>> as /category/year/season/slug/. (It implies a
division of our  
>> content, site-wide, by the genre of the work.
That's not a division  
>> that we make or care to make.)
>
> In that case, I personally wouldn't use /articles. I'd
just put  
> everything in the root category, so you got
/year/season/slug. / 
> articles/ is just redundant.

The only reason I'm using /articles/ now is that our
existing CMS  
requires *something* that stands between the articles
hierarchy and  
the root. Because, yeah, /articles/ makes me cringe, too.
 That
may  
be the one change that I make during this transition.


>> The third is that the URLs would become entirely
too long. And the  
>> fourth is that the additional information, while
more descriptive,  
>> wouldn't add any substantially useful information
for our readers.
>
> It's not for your readers, it's for the search engine
(although I  
> personally get a lot out of descriptive URLs, but I'm a
geek).

What I should have said that it wouldn't add any
substantially useful  
information *that would be worth the longer URLs*. (Thus
conflating  
points 3 and 4...but it's so *nice* to have a whopping four
points to  
make. 

I have to wonder how useful that genre data is to search
engines.  
Surely they don't treat nonfiction and fiction separately.
And I don't  
know that folks searching for "fiction," in
general, are ever going to  
find our publication appearing prominently, no matter how
awesome our  
Google-fu is.  This is
the kind of thing that Dublin Core is really  
meant for...though, thanks to spammers, site-defined
metadata is  
basically useless. OTOH, providing more metadata to search
engines (or  
Greasemonkey, or whatever) is *always* good. Hmm.


>> Simon and Chris, thank you very much for your
suggestions. In  
>> particular, Chris, it hadn't crossed my mind that
keywords could be  
>> useful for this purpose, but it makes perfect
sense. I'm not sure  
>> which of the two approaches that I'll take, but in
importing all of  
>> my existing content, I believe I'll allow for each
possibility.
>
> I think that key words are better for this, unless
you're also using  
> them for something else (like keywords for your
documents), in which  
> case I'd go with the secondary category solution (which
I first did  
> for Macworld back in the day).

That is a bit of a conundrum for me. Keywords are an awfully
useful  
thing, for using internally, and I'd hate to give that up.
OTOH, it  
seems like a fantastically useful thing, to just generate
categories  
from keywords. Bricolage, like Perl, seems to have a real
strength in  
providing multiple methods of accomplishing the same thing,
so I'll  
figure something out. 

Best,
Waldo

---
Virginia Quarterly Review
One West Range, Box 400223
University of Virginia
Charlottesville, VA 22904-4223