Nested facets
A structural element of classification systems that I have never seen discussed explicitly has been hovering in my mind for years, and suddenly became kinda clear to me, so I’m writing this down ;) Sometimes really simple things can take a long time to sink in with me.
Many times, you’ll have an overall taxonomy (say, “products”) (whatever structure it has, faceted or not), and then, once you reach a certain point within that taxonomy (say, “digital cameras”), you suddenly are offered additional taxonomies to refine your choice (say, “lens type”). These additional taxonomies aren’t just nodes within the higher taxonomy, they are additional facets, NOT part of the taxonomy you were browsing so far.
Try browsing epinions.com as an example, or have a look at this diagram:
These kind of nested facets are clearly being used and useful in real life, but I haven’t seen their structural or other properties being discussed explicitly anywhere. They are not part of XFML, for example, nor are they part of Travis’ Facetmap, afaik.
Maybe they are too obvious to be discussed, but some awareness of the existence and usefulness of nested facets (I’ll just call them that, seems to work) would mean there would be more chance of them being built into the standards and tools that define the restrictions within which we often work. So who has worked with nested facets? Any tools that explicitly support them? Any comments on their properties?
April 24th, 2004 at 2:47 am
Nested facets
Peter Van Dijck has posted an interesting blog entry on the concept of nested facets. To quote: Many times, you’ll have an overall taxonomy (say, “products”) (whatever structure it has, faceted or not), and then, once you reach a certain…
April 24th, 2004 at 4:46 am
one property you might consider is selectively activating/disclosing the nested facet — rather than revealing it at the top level along with all the other facets, only reveal it once you’ve browsed down to that level.
this would be particularly important once you have lots of nested facets (eg. printer ink vs toner, peripheral is USB/parallel port/SCSI/firewire, speakers support stereo, etc etc etc)
April 24th, 2004 at 4:39 pm
Yes, that’s what I was trying to say :) The additional facets only show up once you get down to a certain level.
April 24th, 2004 at 11:58 pm
Nested Facets
Peter Van Dijck writes about “nested facets” in a recent post. The concept is, as Peter notes, not new, but worth making explicit. In a nutshell, the idea is that you can include a faceted classification system in a small part of a larger taxonomy. Pet…
April 25th, 2004 at 5:42 pm
Peter:
Rather than “nested facets”, how about “object properties”?
We found the issue you raise to be a central challenge in the design of an effective tool for business knowledge modeling. The problem here is that the classic understanding of a taxonomy as a hierarchy of specialization classes turns out to be too limited in many real-world cases. This is especially true when you want your model to serve additional business purposes, as well as to support faceted search.
In our model, the “Cameras Facets” structure on the right-hand side of your diagram would represent a class definition for the “Camera” class, where the Camera class has “Resolution” and “Lens Type” properties. Each instance of a Camera would possess Resolution and Lens Type properties, with appropriate values for that particular Camera.
We would represent each node in the classifying hierarchy (”Electronics”, “Cameras”) as an object instance as well — maybe as an instance of a “Product Container” class. That would allow us to associate additional properties with each Product Container, which might include descriptive text for navigation purposes, alternative terms for text search, or relationships to instances in other hierarchies.
Finally, the arrows on your “Product” hierarchy would be modeled as connections among object instances, which may or may not have semantics of their own. The leaf nodes in the hierarchy would be Camera instances (or PDA instances, etc.), while the intervening nodes in the hierarchy would be instances of the Product Container class.
We have found this object-oriented perspective to be more natural, more robust, and more easily repurposed than the traditional “is-a” taxonomy. In this example, it should be easy to see how the model described could be used to drive a complete product catalog system, allowing hierarchical navigation and providing faceted, text, and parametric search.
April 25th, 2004 at 5:43 pm
Peter:
Rather than ‘nested facets’, how about ‘object properties’?
We found the issue you raise to be a central challenge in the design of an effective tool for business knowledge modeling. The problem here is that the classic understanding of a taxonomy as a hierarchy of specialization classes turns out to be too limited in many real-world cases. This is especially true when you want your model to serve additional business purposes, as well as to support faceted search.
In our model, the ‘Cameras Facets’ structure on the right-hand side of your diagram would represent a class definition for the ‘Camera’ class, where the Camera class has ‘Resolution’ and ‘Lens Type’ properties. Each instance of a Camera would possess Resolution and Lens Type properties, with appropriate values for that particular Camera.
We would represent each node in the classifying hierarchy (’Electronics’, ‘Cameras’) as an object instance as well — maybe as an instance of a ‘Product Container’ class. That would allow us to associate additional properties with each Product Container, which might include descriptive text for navigation purposes, alternative terms for text search, or relationships to instances in other hierarchies.
Finally, the arrows on your ‘Product’ hierarchy would be modeled as connections among object instances, which may or may not have semantics of their own. The leaf nodes in the hierarchy would be Camera instances (or PDA instances, etc.), while the intervening nodes in the hierarchy would be instances of the Product Container class.
We have found this object-oriented perspective to be more natural, more robust, and more easily repurposed than the traditional ‘is-a’ taxonomy. In this example, it should be easy to see how the model described could be used to drive a complete product catalog system, allowing hierarchical navigation and providing faceted, text, and parametric search.
April 26th, 2004 at 2:47 am
Travis:
Another excellent approach!
Regarding concerns about leaning “back towards the single-parent hierarchy that we try to avoid with facets” — remember that the model I described builds classifying hierarchies out of object instances, not classes. Leaf nodes can be classified by multiple hierarchies. There’s no implication at all of a single-parent hierarchy.
April 26th, 2004 at 3:57 am
Travis, great approach! I like it. A facet could then have multiple scopes.
April 27th, 2004 at 9:30 am
Gosh folks, what a wonderful work you are doing. Many, many thanks. These are excellent insights and of course the questions that go with these insights :-) Compliments for great work! The camera example is really helpful for me.
For right now, my question is: “What (usability) mistakes can we make by nesting (facets)?”
April 27th, 2004 at 9:31 am
Gosh folks, what a wonderful work you are doing. Many, many thanks. These are excellent insights and of course the questions that go with these insights :-) Compliments for great work! The camera example is really helpful for me.
For right now, my question is: “What (usability) mistakes can we make by nesting (facets)?”
June 4th, 2004 at 5:10 am
You’re actually just describing ONTOLOGIES. Ontologies are similar to taxonomies, but as you are getting at, they can have different properties at different levels of the tree. It’s like a big, big class hierarchy.
August 29th, 2004 at 5:44 am
Alan Pinstein , your description of ontologies is a bit simple. Ontologies doesn’t really fit here. They are more about inter-relationships among the various taxonomies. Most literature described them as network relationships. Ontologies map all possible reationships.
Peter’s nested facets are more like sub-divisions in DDC. Taking common properties and adding them to the broader facets when applicable.
This is my understanding. =)
September 7th, 2006 at 5:51 pm
Roughly twenty years ago I came up with an idea that I called “Nested Faceted Classification,” which appears to be somewhat different from what is being discussed. The idea being discussed reduces the cognitive load on one trying to retrieve something by exposing only facets that are germane to all entities not yet excluded from consideration.
Another problem is not to present the user with too many values for a facet.
The approach I developed applies faceted classification to the values of the facets, hereby reducing the cognitive load in a different dimension. Unfortunately, the plug was pulled on the project, so there was no funding even to publish intermediate results of broader applicability than to the (canceled) project.
Now that the term “nested faceted classification” has been pre-empted for a
different meaning from what I use, perhaps I should use a different term, such
as “recursive faceted classification.”