Comments (10)

  1. Robert Willis says:

    Are their plans to expand into the ontology area in the future once people get comfortable with taxonomies? Hierarchies are great but they don't fit all use cases. Ontologies are important and useful for very large organizations. Keep up the great work.

  2. vgrem says:

    Thanks Pat for very interesting story about Taxomony features!

    We've been using Taxonomy for a while in SharePoint 2010 projects and i can say it is VERY convenient feature.

    The only downside we've found related with declarative declarations of  taxonomy fields.

    In Schema we have to specify SspId,GroupId,AnchorId, but what if someone deploy Taxonomy store though feacture activation and after this step to create taxonomy fields then the only we've found to create taxonomy fields was using Taxonomy API.  

  3. Pat Miller MSFT says:

    You are correct, you need to create taxonomy fields through code, and not through onet.xml.  There is a limitation in the current version that makes it impossible to create a taxonomy field any other way.  The next blog post should shed some light on this area.

  4. spnewb says:

    Thanks for the post!  You mentioned something about overlaying security model with metadata, did it get implemented with SP 2010?  I can't find much info on it.  Thanks!

  5. spnewb says:

    Thanks for the informative post!

    You mentioned an interesting feature of overlaying security model with metadata, did this feature get implemented in SharePoint 2010?   I can't find much info on it.  Thanks!

  6. Pat Miller MSFT says:

    No, unfortunately this version of SharePoint doesn't have the infrastructure for supporting metadata-based ACLs.

    On the first comment, yes, you need to create the field through code, not xml.  The feature xml doesn't work for the taxonomy field.  Things like the category field in the enterprise wiki are created through activation code as well.

    Thanks for the comments, and hope to have some more posts up soon.

    Pat.

  7. Des Russell says:

    Pat this is a great article , very insightful and easy to understand how you have approached various aspects of the MMS. If i could ask a question, while we can secure people from editing term sets, can we apply security to term sets to deny users or groups of users access to certain content….e.g. members of a security group "Human Resources" can only see documents that have the term " Employee Contracts" assigned to them, general users can not see those documents?

  8. Stefan Bauer says:

    Hi Pat,

    in your article you wrote about the improvments on Content Query. So basically i check this and i liked the possiblity to Query Metadata ContainAny or ContainAll. The main problem from my point of view is that you are not allowed to query for three different columns using AND or OR condition with those ANY and ALL. So what i wanted you to ask is if there is a list of limitations for Content Query and Metadata. I mean it makes sense from an infrastructure perspective to avoid log running query and massiv data selection on the database. But i would be nice if we know the exact limitations and if there are workarounds ?

    Stefan

  9. Stefan Bauer says:

    Hi Pat,

    in your article you wrote about the improvments on Content Query. So basically i check this and i liked the possiblity to Query Metadata ContainAny or ContainAll. The main problem from my point of view is that you are not allowed to query for three different columns using AND or OR condition with those ANY and ALL. So what i wanted you to ask is if there is a list of limitations for Content Query and Metadata. I mean it makes sense from an infrastructure perspective to avoid log running query and massiv data selection on the database. But i would be nice if we know the exact limitations and if there are workarounds ?

    Stefan

  10. This article is a few years old now but an excellent introduction to enterprise metadata management. Thanks Pat! Great work!