Just off the top of my head, two methods come to mind. If you need Salmon to appear under both primary headings, modifying a Page List add-on to select by attributes could achieve that (see http://www.concrete5.org/marketplace/addons/page-list-plus/... for an example of a paid add-on that could work)
Or, if it needs to be accessed as a child page on the menu, consider adding the second instance of the page as an external link pointing to the original.
I'm sure there are other methods as well.
Hope this helps

Adrian
Arvixe Web Hosting / Concrete5 Community Liaison |
http://www.arvixe.com/concrete5_hosting.............

To add to adreco's answer...

I use Page List Plus on multiple sites. Simply adding two select page attributes, fresh & salt, would accomplish this. When creating a page you would select the one that applies or both. Then with PL Plus it's easy to search by page type, or by heierarchy, only displaying pages with either or both attributes selected!

I've approached this style of categorisation quite a few times by just using page aliases in the site map - when you drag and drop pages in the site map one of the options is to create a page alias.

The normal page list block will list aliased pages, so there's not really anything to configure or custom code to get it to work, you just make sure you tick the 'Display page aliases' checkbox on the block.

What I think it comes down to is working out what why works best from a content placement and management point of view and how often you need to put an item into multiple categories.

Pros of using page aliases:
- No third party blocks are needed
- Top level category pages don't need to be edited when newly created, the page list block setting would stay the same, it just looks at the 'child' pages.
Cons:
- Creating page aliases in the site map isn't hard but it can feel a bit fiddly/messy, especially if the site map is big.
- Can't add a new page/item to multiple categories straight away using the composer, you have to add your page to the 'primary' category first, then go to the site map as a second step to create the aliases for additional categorisation

Pros of using a custom page attribute:
- Can place an item in multiple categories immediately on page creation (you'd have a nice list of checkboxes on the composer form)
- Much easier immediately tell what categories a page is in
Cons:
- Every time you want to create a new top level category, you need to go and modify the attribute to include your new option, as well as edit your new category page's page list plus block to filter to match the new option.
- Can't use the autonav block to show a tree of categorised items (I don't think)

So I'd suggest it just comes down to how often you are creating top level categories (perhaps the question is more WHO would be doing this data entry), and considering what is going to be easier to manage in the long run. If your list of top level categories is pretty static, the attribute way is probably better, whereas if you are constantly adding new categories (or you need to set it up so it's easy for someone else to do so) only only occasionally need to put an item in multiple categories then the page aliases might be the way to go.

Thanks for the in depth informative answers.

The pros and cons are very useful.

I am feeling a bit dense though as if the attribute route is utilised, I am still wondering about the context in which 'Salmon' appears.
If i am viewing a page list under a page called "Fresh Water Fish' which lists fish via a pagelist, when I want to click on to the 'Salmon' page for full details, in which context will I view it? 'Fresh Water Fish' and 'Salt Water Fish' would be top level pages and wouldn't Salmon have to live under one of them? Then when you click thru from a parent page in what context (ie Fresh or Salt) are you viewing the Salmon page?

Hope this makes sense..

the structure i suggested could consist of a main area of the site where all fish types are stored, one to a page. each page would have the attributes to select upon creation. (salt, fresh, or both)

then you could create a freshwater page and a saltwater page and using the page list plus filtering, display only the fish that were selected as freshwater on the freshwater page. and vice versa. any fish with both attributes selected would therefore display under both categories!

Thanks enlil,
I see how this can work. But still feeling stupid, because I am asking what about the fish view?

We have a view of freshwater fish , thanks to page list it shows 'Salmon' as does 'saltwater' page. But the page list usually lets you click thru to the page 'Salmon' whichis another 'view'. So when you click on the 'Salmon' item from the page list to view 'Salmon', in what context ( by context you can read 'menu path', 'nav selected', 'page hierarchy') does it appear?

[think i might just have to build it and see :) ]

Don't feel stupid, these are important questions!

When you click through to see a fish, you'd see it by it's original page path, the one where the real page is located, not the alias.

This is actually a good thing because in the majority of cases you don't want to have identical content appearing under different page paths as search engines penalise that kind of thing. The pages list in different places, but the page itself has one url.

For your particular scenario, I'd actually put all my pages under a broader 'fish' category, and then use the aliases for the categorisation.

Thanks.
Some of my thinking in the background to this question was really coming from UX perspective about being able to discover content under different 'trigger' categories or routes into it and keeping a context for the view consistent. I am not sure but i suspect a data driven system [Drupal?] might provide a different approach that is just plain harder in a page driven system. I totally get the duplicate content argument but I was wondering if it was possible to keep the context view, so that 'Salmon' data could be seen from

Home > Fresh Water Fish > Salmon
and
Home > Salt Water Fish > Salmon

It doesn't sound like it is possible in C5 and the discussion could spiral into a while other IA problem which wasn't the intention but might be good fun.

I really appreciate all the responses above in thinking through options.

And ff course this has got nothing to do with fish!

I just found this thread from late last year because I'm looking at ways to make tags that are SEO-friendly like we have in WP or Drupal. And taxonomy came to mind. I thought I'd chime in the C5 equivalent (roughly) to taxonomy would be attributes?

Did you ever get what you were working on setup and find solutions around this?