This a very hard problem. If you search for "ontology product classification" you'll find many research papers and discussions on the topic. If one was simply a more detailed version of the other it would be quite feasible, but your description implies that isn't the case, and thus you'll need to construct your own classification scheme and map the others onto it.
Do you have a common key (UPC code? or other) that will allow you to verify your mapping between the different product categories? If so, you might be able to construct your own categorization scheme and then map the others onto it with some degree of success.
Clearly the first option is the best for the consumer but it could be very hard and very time consuming to construct such a mapping and it will need constant updates.
One approach would be to construct a simpler hierarchy than any of the ones provided. A simpler hierarchy will make the [mostly manual] effort of mapping categories into your hierarchy much easier as most will simply be inclusions. This might make the user experience worse but if you add great search capabilities and great "related products" / "people who bought this also bought this" tools around the product browsing experience you can probably make up for the lack of hierarchy.
Number One isn't that bad of a nightmare. Your users' experience is the number one priority; never forget that. If the user has an easier time navigating a shorter route, then give them that opportunity. Also, I would wrap the API with some abstraction so my code doesn't know about the API at all and only knows about the abstraction layer. This way I can change APIs and leave most of my code alone, only changing the abstraction layer.
Use a session to pass data from page to page and a factory to create the page's state on entry based on the session data; this will strengthen the context between page, state, and user data.
Keep first level objects (the ones the page directly talks to) in context to the page; this will help when diagnosing problems.
Most importantly, create a series of tests for your abstraction layer that test every object, function, and input output pair to make sure your application is rock solid.
发布评论
评论（3）
这是一个非常难的问题。如果您搜索“本体产品分类”，您会发现许多有关该主题的研究论文和讨论。如果一个只是另一个的更详细版本，那将是非常可行的，但您的描述暗示情况并非如此，因此您需要构建自己的分类方案并将其他分类方案映射到它上面。
您是否有通用密钥（UPC 代码？或其他）来验证不同产品类别之间的映射？如果是这样，您也许能够构建自己的分类方案，然后将其他分类方案映射到该方案上，并取得一定程度的成功。
显然，第一个选项对消费者来说是最好的，但构建这样的映射可能非常困难且非常耗时，并且需要不断更新。
一种方法是构建一个比所提供的任何层次结构更简单的层次结构。更简单的层次结构将使将类别映射到层次结构的[主要是手动]工作变得更加容易，因为大多数只是包含项。这可能会使用户体验变得更糟，但如果您围绕产品浏览体验添加出色的搜索功能和出色的“相关产品”/“购买此产品的人也购买了此”工具，您可能可以弥补层次结构的缺乏。
This a very hard problem. If you search for "ontology product classification" you'll find many research papers and discussions on the topic. If one was simply a more detailed version of the other it would be quite feasible, but your description implies that isn't the case, and thus you'll need to construct your own classification scheme and map the others onto it.
Do you have a common key (UPC code? or other) that will allow you to verify your mapping between the different product categories? If so, you might be able to construct your own categorization scheme and then map the others onto it with some degree of success.
Clearly the first option is the best for the consumer but it could be very hard and very time consuming to construct such a mapping and it will need constant updates.
One approach would be to construct a simpler hierarchy than any of the ones provided. A simpler hierarchy will make the [mostly manual] effort of mapping categories into your hierarchy much easier as most will simply be inclusions. This might make the user experience worse but if you add great search capabilities and great "related products" / "people who bought this also bought this" tools around the product browsing experience you can probably make up for the lack of hierarchy.
第一名并不是那么糟糕的噩梦。用户体验是第一要务；永远不要忘记这一点。如果用户可以更轻松地导航较短的路线，那么就给他们这个机会。另外，我会用一些抽象来包装 API，这样我的代码就根本不了解 API，而只了解抽象层。这样我就可以更改 API 并保留大部分代码，只更改抽象层。
使用会话在页面之间传递数据，并使用工厂根据会话数据创建页面的进入状态；这将加强页面、状态和用户数据之间的上下文。
将第一级对象（页面直接对话的对象）保留在页面上下文中；这将有助于诊断问题。
最重要的是，为您的抽象层创建一系列测试，测试每个对象、函数和输入输出对，以确保您的应用程序坚如磐石。
Number One isn't that bad of a nightmare. Your users' experience is the number one priority; never forget that. If the user has an easier time navigating a shorter route, then give them that opportunity. Also, I would wrap the API with some abstraction so my code doesn't know about the API at all and only knows about the abstraction layer. This way I can change APIs and leave most of my code alone, only changing the abstraction layer.
Use a session to pass data from page to page and a factory to create the page's state on entry based on the session data; this will strengthen the context between page, state, and user data.
Keep first level objects (the ones the page directly talks to) in context to the page; this will help when diagnosing problems.
Most importantly, create a series of tests for your abstraction layer that test every object, function, and input output pair to make sure your application is rock solid.
您必须向客户提供一致的、不变的界面。
我想看看您想到的两种不同方法的示例。
You have to provide to your clients a consistent not changing interface.
I would like to see an example of the two different approaches you have in mind.