Hi, the taxonomy.module provides a way to make term descendant to multiple independent terms (multiple parents). Does anyone use this kind of functionality, and what for? Konstantin Käfer – http://kkaefer.com/
In my opinion, any time multiple parents are used it is a mistake in the data model. For example, if you have regional offices and each office has a sale, customer and advertising contact person, you might be tempted to model the data like this: Boston --sales --customer --advertising Detroit --sales --customer --advertising New York --sales --customer --advertising One quickly sees, however, that the cleaner model would be two vocabularies, one for location, one for contact person. I have no use for multiple parents and would support deprecating it for eventual removal. -Robert Konstantin Käfer wrote:
Hi,
the taxonomy.module provides a way to make term descendant to multiple independent terms (multiple parents). Does anyone use this kind of functionality, and what for?
Konstantin Käfer – http://kkaefer.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Douglass schrieb:
In my opinion, any time multiple parents are used it is a mistake in the data model. For example, if you have regional offices and each office has a sale, customer and advertising contact person, you might be tempted to model the data like this:
How about: Fish living in: - - salt water . shark . salmon . eel . cod - - fresh water . trout . salmon . eel . carp Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGpeNafg6TFvELooQRArsHAJ9ZLyyMKxIUW25OBZFi43CQ+T5MIwCfTNxu Yhbq6xb9JMsB7XgH+HcUl48= =Xezr -----END PGP SIGNATURE-----
From reporting/analysis point of view, salmon IS salmon. .s Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Robert Douglass schrieb:
In my opinion, any time multiple parents are used it is a mistake in the data model. For example, if you have regional offices and each office has a sale, customer and advertising contact person, you might be tempted to model the data like this:
How about:
Fish living in:
- - salt water . shark . salmon . eel . cod
- - fresh water . trout . salmon . eel . carp
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGpeNafg6TFvELooQRArsHAJ9ZLyyMKxIUW25OBZFi43CQ+T5MIwCfTNxu Yhbq6xb9JMsB7XgH+HcUl48= =Xezr -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 sime schrieb:
From reporting/analysis point of view, salmon IS salmon.
Yes, and? Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGpeqHfg6TFvELooQRAkfAAJ9UFgvG49VNHDzMuQdZUcSVdcVd7QCfUFXC ddUOUtblSAAU75fDV3eRGNs= =6fLJ -----END PGP SIGNATURE-----
I've often wondered about this as well, and figured I was missing something. But for this use case, two separate vocabularies would capture the same data, and it would be easier for the end user to comprehend: Type of Fish -shark -salmon -eel -cod -trout -carp Habitat -ocean -lakes -rivers -marsh -brackish I think this is one of those cases where we should ask a librarian -- when it comes to explaining uses for taxonomy/categorization, I have found that librarians can explain use cases I have never imagined. Cheers, Bill Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Robert Douglass schrieb:
In my opinion, any time multiple parents are used it is a mistake in the data model. For example, if you have regional offices and each office has a sale, customer and advertising contact person, you might be tempted to model the data like this:
How about:
Fish living in:
- - salt water . shark . salmon . eel . cod
- - fresh water . trout . salmon . eel . carp
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGpeNafg6TFvELooQRArsHAJ9ZLyyMKxIUW25OBZFi43CQ+T5MIwCfTNxu Yhbq6xb9JMsB7XgH+HcUl48= =Xezr -----END PGP SIGNATURE-----
-- Bill Fitzgerald http://www.funnymonkey.com Tools for Teachers 503.897.7160
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Fitzgerald schrieb:
I've often wondered about this as well, and figured I was missing something.
But for this use case, two separate vocabularies would capture the same data, and it would be easier for the end user to comprehend:
Type of Fish -shark -salmon -eel -cod -trout -carp
Habitat -ocean -lakes -rivers -marsh -brackish
Makes sense to me.
I think this is one of those cases where we should ask a librarian -- when it comes to explaining uses for taxonomy/categorization, I have found that librarians can explain use cases I have never imagined.
What I am mainly concerned about is the upgrade path if we should drop this special tree diagramm from Drupal's taxonomy module. How do we avoid to screw up the site of somebody using it? Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGpfTNfg6TFvELooQRApkzAJ9NGJJ4y2aBy3uqDP/acbdIZJN/TgCgvhOr xmHxIrbRzMI4pFcp8Aipt5w= =gKj3 -----END PGP SIGNATURE-----
On 7/24/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
What I am mainly concerned about is the upgrade path if we should drop this special tree diagramm from Drupal's taxonomy module. How do we avoid to screw up the site of somebody using it?
How about a note in README.txt: Dear Users, We're dropping support for taxonomies with multiple parents. It would be impossible to guess how you want your taxonomy upgraded because there are multiple ways to "solve" this problem. Please read <help text distilled from this thread> to see how to fix this scenario. Thanks, Drupal -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
On 7/24/07, Greg Knaddison - GVS <Greg@growingventuresolutions.com> wrote:
On 7/24/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
What I am mainly concerned about is the upgrade path if we should drop this special tree diagramm from Drupal's taxonomy module. How do we avoid to screw up the site of somebody using it?
How about a note in README.txt:
Dear Users,
We're dropping support for taxonomies with multiple parents. It would be impossible to guess how you want your taxonomy upgraded because there are multiple ways to "solve" this problem. Please read <help text distilled from this thread> to see how to fix this scenario.
Thanks, Drupal
-- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
Very cute! That is actually what many projects would actually do. My question is: is it a priority to decide now what to do about this? A detailed discussion involving set theory and library science is required, plus modern tendencies in semantic web. In other words, and this is quite serious, just as Drupal ties in to Web 2.0in general, the taxonomy must eventually tie in with the two main branches of semantic web work being done today: topic maps, on the one hand, and RDF, on the other. The connection with the Dublin Core and RSS attemts to link up with taxonomy suggest that this debate may very well be connected to the whole aggregation question also... saludos, Victor Kane http://awebfactory.com.ar
On Tue, July 24, 2007 15:10, Greg Knaddison - GVS wrote:
We're dropping support for taxonomies with multiple parents.
Please don't. I need it :-) I wonder if there is a specifical need to drop this support. It worked up to now - if there is something really comples about it please explain :-) Ciao --8<-----------------------------------fnord----- Piermaria Maraziti piermaria@maraziti.it KALLISTI ICQ744473 MSN:kallisti@hotmail.it +3934735GILDA www.gilda.it www.eridia.it www.hovistocose.it
Hi,
I wonder if there is a specifical need to drop this support.
a) Taxonomy could be rewritten using another data model that allows for more efficient querying, e.g. nested sets (chx ;)) b) There is no sane way to display two identical terms properly. Currently, there is no way to decide whether a term is identical to another one or has just the same name. Also, nothing has been decided. If people come up with convincing and sensible use cases, it will most likely not be dropped. Konstantin Käfer — http://kkaefer.com/
At 17.28 24/07/2007, you wrote:
I wonder if there is a specifical need to drop this support. Also, nothing has been decided. If people come up with convincing and sensible use cases, it will most likely not be dropped.
In board games and RPG industry there would be a similar need of a multiple parents taxonomy. Using more than one dictionary is not the right choice because the navigation would be more complex. Ciao! --8<-----------------------------------fnord----- Piermaria Maraziti piermaria@maraziti.it KALLISTI ICQ744473 MSN:kallisti@hotmail.it +3934735GILDA www.gilda.it www.eridia.it www.hovistocose.it
I agree. Having experience with BusinessObjects and COGNOS, I have never come across an implementation of multiple parents in the way that classifications are stored. Robert Douglass wrote: ...
One quickly sees, however, that the cleaner model would be two vocabularies, one for location, one for contact person. I have no use for multiple parents and would support deprecating it for eventual removal.
-Robert
Konstantin Käfer wrote:
Hi,
the taxonomy.module provides a way to make term descendant to multiple independent terms (multiple parents). Does anyone use this kind of functionality, and what for?
Konstantin Käfer – http://kkaefer.com/
On Tue, July 24, 2007 13:47, sime wrote:
I agree. Having experience with BusinessObjects and COGNOS, I have never come across an implementation of multiple parents in the way that classifications are stored.
I have an ecommerce website (that will be ported to Drupal in the next few months) in which I have: * Silver jewelry - pagan pendants - ... * Clairvoyance items - crystal balls - scrying bowls - ... * Accesssories - Calices - Athames - ... * Pagan items - pagan pendants - crystal balls - scrying bowls - Calices - Athames because in main categories there are also a lot of items not pagan and I needed a way to create a portion of the site specifically for pagans. Ciao! --8<-----------------------------------fnord----- Piermaria Maraziti piermaria@maraziti.it KALLISTI ICQ744473 MSN:kallisti@hotmail.it +3934735GILDA www.gilda.it www.eridia.it www.hovistocose.it
Robert Douglass wrote:
In my opinion, any time multiple parents are used it is a mistake in the data model.
We're using Drupal to revamp the web portfolio of a private intelligence firm, and we have some uses: Post Soviet-bloc -- Poland -- Russia European -- Poland -- France The parents are children are so related that most users would find splitting them into multiple vocabularies redundant: Location: Post Soviet-bloc European Country: Poland Russia France
I've had times when I would like to have done this too. This particular use case is a very good example. David Strauss wrote:
Robert Douglass wrote:
In my opinion, any time multiple parents are used it is a mistake in the data model.
We're using Drupal to revamp the web portfolio of a private intelligence firm, and we have some uses:
Post Soviet-bloc -- Poland -- Russia European -- Poland -- France
The parents are children are so related that most users would find splitting them into multiple vocabularies redundant:
Location: Post Soviet-bloc European
Country: Poland Russia France
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
Post Soviet-bloc -- Poland -- Russia European -- Poland -- France
Just out of curiosity, is it possible to determine European/Poland vs. Soviet/Poland? I understand that they are identical, but nonetheless it might be interesting to see if the user specifically selected one or the other. Konstantin Käfer — http://kkaefer.com/
On Jul 24, 2007, at 1:54 PM, Konstantin Käfer wrote:
Post Soviet-bloc -- Poland -- Russia European -- Poland -- France
Just out of curiosity, is it possible to determine European/Poland vs. Soviet/Poland? I understand that they are identical, but nonetheless it might be interesting to see if the user specifically selected one or the other.
It sounds like the problem is that some developers are trying to define a single hierarchy for terms with multiple parents. Writing your modules to ignore vocabularies which allow multiple parents should do the trick.
2007/7/24, Robert Douglass <rob@robshouse.net>:
In my opinion, any time multiple parents are used it is a mistake in the data model. [...]
If you have a data model for musical genres (which used multiple parents), where you put "folk rock" but as a child of "folk" and "rock"? "Celtic punk" as a child of "punk" and "Celtic (folk)"? I'd be sad to see the ability to use multiple parents go. Multiple parents have been one of the reasons I've been clinging so tightly onto Drupal's taxonomy module, as few other categorisation/tagging applications allows for thus. (I could also imagine such cases as "Tønder Festival 2006" being a child of "2006 (Events)" and "Tønder Festival"...) -- Frederik 'Freso' S. Olesen <http://freso.dk/>
I think this entire discussion is confusing data models, on the one hand, with set (inclusion) theory, on the other. Also, the so-called "use cases" being mentioned are half analytical entities (solution domain) and half requirements (problem domain). First, the use cases need to be expressed in terms of problem domain requirements. Then, it can be decided whether some kind of inclusion in sets (taxonomy) or data model (i.e., cck field plus views) can implement the needed functionality. saludos, Victor Kane http://awebfactory.com.ar On 7/24/07, Frederik 'Freso' S. Olesen <freso.dk@gmail.com> wrote:
2007/7/24, Robert Douglass <rob@robshouse.net>:
In my opinion, any time multiple parents are used it is a mistake in the data model. [...]
If you have a data model for musical genres (which used multiple parents)...
On 24/07/07, Konstantin Käfer <kkaefer@gmail.com> wrote:
Hi,
the taxonomy.module provides a way to make term descendant to multiple independent terms (multiple parents). Does anyone use this kind of functionality, and what for?
We do, it's an important part of our site. eg: http://ilign.com/categories/50,39/all and http://ilign.com/categories/48 In the above knowledge base, the "subject" vocab uses multiple parents - eg the "budgets" term has parent terms "financial", "planning", and "project". And the "risks" term has "project" and "business alignment" parents. The other "audience" and "purpose" vocabs are just simpler hierarchies though. I can sympathise with the extra hassle that having multiple parents causes - getting my taxonomy_filter contrib module (the menu you see on the right sidebar of the above urls) to play handle them was more effort than I hoped, but it was worth it. The ability of Drupal to handle that sort of categorisation was the main reason we chose Drupal in the first place. Allowing the same term to be used in multiple contexts is useful and powerful. Maybe I'm not fully aware of alternative methods but I would hate to see multiple parents disappear from Drupals taxonomy system. -- Cheers Anton (styro@drupal.org)
Maybe I'm not fully aware of alternative methods but I would hate to see multiple parents disappear from Drupals taxonomy system.
Agreed. I am more than aware of the technical challenges but "challenges exist only to solve them". It's not a solution to say "doh this is complex, rip it out!".
participants (15)
-
Anton -
Bill Fitzgerald -
catch libcom -
Darren Oh -
David Strauss -
Frederik 'Freso' S. Olesen -
Gerhard Killesreiter -
Greg Knaddison - GVS -
Karoly Negyesi -
Konstantin Käfer -
Piermaria Maraziti -
Robert Douglass -
Sean Robertson -
sime -
Victor Kane