Sunday, December 5, 2010
Adding Categories
Adding Categories - we didn't discuss it in class, but the consensus on AUGI is no consensus. There are ardent believers in allowing it, and ardent believers in leaving it alone... I'm going to try and find an official list of all the classes (categories) IFC lists as an example, but no luck yet. I'm a big fan of adding a discrete set of user requested categories based on a petition process or something like that. I don't think a free for all is warranted, but I also don't think never adding a category is a good solution either. My two cents...
Subscribe to:
Post Comments (Atom)
There is a need for more categories as we have run into big workarounds. The lack of categories really makes scheduling more difficult. Also, it is next to impossible to add a Project Parameter to a category as it will affect all items in that category.
ReplyDeleteAn example of this is Signage, currently we have them in Specialty Equip, but have difficulties doing what we need to do.
I agree it would be interesting to understand how the categories map to IFC standards.
Thanks for adding this to further the discussion.
I'm not sure created a user-generated list is the way to go. In theory it sounds like a good compromise – it’s not completely customizable but has more options that we currently have.
ReplyDeleteHowever, in practice, I can't imagine getting a comprehensive list for all disciplines all across the world! For example, I know for sure, that in India the construction industry/architectural industry would need some categories/nomenclature not used in North America and vice versa.
It's just a random example, but as much as I would like to believe we can get a comprehensive list that is completely user generated (petitions/forums etc.), I don’t think we could cover all of our needs in any sort of cohesive manner.
Natasha
One thing I'd considered as something to resolve Tucker's issue is allowing us to create tags and schedules that are restricted to certain subcategories, and assigning a subcategory at the family level rather than just the geometry level.
ReplyDeleteThat way IFC mapping can be maintained, as can most of the application's controls. However, users can have a semblance of freedom in their content and standards.
Thoughts?
I like the idea of creating Tags and schedules for sub-categories as well as assigning it to the family instead of just geometry.
ReplyDeleteWould you have an overall "category" override though? So using Tucker's example if you are allowed to assign a different tag to Signage and a different one for Specialty equipment, would the Signage sub-category always behave differently from the parent "Specialty Equipment" (in tags/schedules etc)? Or would there need to be a way to consolidate sub categories back?
I think schedules and tags that were for a whole category (Specialty Equipment Tags or Schedules) would schedule both Specialty Equipment, Signage, and any other sub-categories of specialty equipment just as they do now. So, no, they never behave "differently" than the parent category because they are part of it. Just like things are now. The difference is that you could create tags or schedules that ONLY look for subcategories within a category.
ReplyDeleteI suppose you could make an interesting argument for scheduling subcategory matches. So, if you happened to have Signage as a subcategory in bot Specialty Equipment AND Generic Models a subcategory schedule or tag would get them both. But, for now I'm more in favor of respecting the boundaries we've got at the category level and then allowing us more flexibility and reporting options at the subcategory level.