6. Presenter
Jonathan Ralton
• Senior Information Architect
• SharePoint IT Pro since 2005
(WSS/SPS)
• No code!
• Document Management,
Content Management,
Knowledge Management…
@jonralton
jonathanr@bluemetal.com
blog.jonralton.net
11. In Theory…
Business
Process
Automation
Portals Social Co-Authoring
External
Collaboration
Workflow
Team
Collaboration
Incident
Management
Project
Management
Knowledge
Management
Enterprise
Content
Management
Application
Platform
14. In Theory…
What is…
• Content Architecture
• Taxonomy
How do they relate?
Content Architecture
Taxonomy
15. Content Architecture
1. The specification for a content management
solution
2. A set of activities and outputs for effective
content management
– Cleve Gibbon
38. Content Type
“a reusable collection of:
1. metadata (columns),
2. workflow,
3. behavior, and other
4. settings
for a category of items or documents in a…list or
document library”
39. Name Parent Name Group
System #N/A _Hidden
Document Collection Folder Folder _Hidden
System Page #N/A _Hidden
System Page Layout #N/A _Hidden
System Master Page #N/A _Hidden
Audio Rich Media Asset Digital Asset Content Types
Image Rich Media Asset Digital Asset Content Types
Rich Media Asset Document Digital Asset Content Types
Video Rich Media Asset Digital Asset Content Types
Document Item Document Content Types
List View Style Document Document Content Types
Form Document Document Content Types
Picture Document Document Content Types
Master Page Document Document Content Types
Wiki Page Document Document Content Types
Basic Page Document Document Content Types
Web Part Page Basic Page Document Content Types
Link to a Document Document Document Content Types
Dublin Core Columns Document Document Content Types
Document Set Document Collection Folder Document Set Content Types
Folder Item Folder Content Types
Discussion Folder Folder Content Types
Summary Task Folder Folder Content Types
Announcement Item List Content Types
Comment Item List Content Types
Contact Item List Content Types
East Asia Contact Item List Content Types
Event Item List Content Types
Issue Item List Content Types
Item System List Content Types
Link Item List Content Types
Message Item List Content Types
Post Item List Content Types
Reservations Event List Content Types
Schedule Event List Content Types
Schedule and Reservations Event List Content Types
Task Item List Content Types
Page System Page Publishing Content Types
Page Layout System Page Layout Publishing Content Types
Publishing Master Page System Master Page Publishing Content Types
40. Content Types – Inheritance
Item
Announcement Contact Event Issue Link Post Task
Document
Picture
Folder
Discussion
Document Set
41. Content Types – Categories
Item
Document
Folder
Document
Set
43. Content Types – Warning
DO NOT modify
the out-of-the-box
content types!
44. Content Types – Considerations
Site 1
Site 1.1
Site 1.1.1
Site 1.1.2
Site 1.2 Site 1.2.1
Site 1.3
• Where to define (Scope)
45. Content Types – Considerations
Intranet
Home
IT
Department
HR
Department
Marketing
Department
Sales
Department
Benefits
Team
Compensation
Team
• Ad
• Development Plan
• Invoice
• Offer Letter
• Performance Review
• Purchase Order
• Salary Increase Request
• Termination Letter
46. Content Types – Considerations
Content
Type 1
Content
Type 1.1
Content
Type 1.1.1
Content
Type 1.1.2
Content
Type 1.2
Content
Type 1.2.1
Content
Type 1.3
• Hierarchy (Inheritance)
• Levels of abstraction
47. Content Types – Considerations
• Ad
• Development Plan
• Invoice
• Offer Letter
• Performance Review
• Purchase Order
• Salary Increase Request
• Termination Letter
48. Content Types – Considerations
Document
Ad
Invoice
Offer Letter
Purchase Order
Salary Increase
Request
Termination Letter
49. Content Types – Considerations
Document
HR Document
Offer Letter
Salary Increase
Request
Termination LetterAd
Invoice
Purchase Order
50. Content Types – Considerations
Document
Corporate
Document
Invoice
Purchase Order
HR Document
Offer Letter
Salary Increase
Request
Termination Letter
Marketing
Document
Ad
51. Content Types – Considerations
Document Master Document
Corporate
Document
Invoice
Purchase Order
HR Document
Offer Letter
Salary Increase
Request
Termination Letter
Marketing
Document
Ad
52. Content Types – Considerations
Standard Shipping
Request
Expedited Shipping
Request
Air Freight Request
International Air
Freight Request
Rail Freight Request
Ocean Freight
Request
International Ocean
Freight Request
• Shipping Approval
• Expedited Shipping Approval
• Exports Authorization
53. Content Types – Considerations
Shipping Request Type
Shipping Approval
Type
Standard Shipping
Request Type
Standard Shipping
Request
Non-Standard
Shipping Request Type
Air Freight Request
Rail Freight Request
Ocean Freight Request
Expedited Approval
Type
Expedited Shipping
Request
International Shipping
Request Type
International Air
Freight Request
International Ocean
Freight Request
• Shipping Approval
• Expedited Shipping Approval
• Exports Authorization
54. Content Types – Considerations
Site
Content
Type A
Content
Type A
in List 1
Content
Type A
in List 2
Content
Type A
in List 3
Content
Type A
in List 4
• Site vs. List/Library content
types
55. Content Types – Considerations
My Document.docx
Document Content Type
http://path/My%20Document.docx
Link to a Document Content
Type
• Link-based content types
59. Site Columns – Types
• All Day Event
• Audience Targeting
• Calculated
• Choice
• Currency
• Computed
• Cross Project Link
• Date and Time
• External Data
• File
• Hyperlink/Picture
• Integer
• Lookup
• Managed Metadata
• Multi-Text
• Number
• Number of Ratings
• Person/Group
• Publishing HTML
• Publishing Image
• Publishing Schedule End
Date
• Publishing Schedule
Start Date
• Rating (0-5)
• Recurrence
• Summary Links
• System
• Text
• Yes/No
60. Site Columns – Considerations
Site 1
Site 1.1
Site 1.1.1
Site 1.1.2
Site 1.2 Site 1.2.1
Site 1.3
• Where to define (Scope)
61. Site Columns – Considerations
Site
Column
Type A
Column
A in List
1
Column
A in List
2
Column
A in List
3
Column
A in List
4
• Site vs. List/Library columns
62. Site Columns – Considerations
Choice
Lookup
Managed
Metadata
• When to use which type
64. Site Columns –
Considerations
• ID;#Value
• Does update
• Metadata about choices
• Projected Fields
• Expand scope of List, but not
across Site Collections
• Possibility for cascading lookups
Lookup Column
65. Lookup Columns – Considerations
Site 1
Site 1.1
Site 1.1.1
Site 1.1.2
Site 1.2 Site 1.2.1
Site 1.3
• Where to define (Scope)
List
List
66. Site Columns –
Considerations
• Hierarchy of terms
• Scope across site collections, web
applications, farms
• No metadata about choices in 2010
• Extended Properties in 2013
• Can assist with navigation
• No InfoPath support
• No Document Information Panel
support
• No Data Sheet View support
• Folksonomy possibilities
Managed
Metadata Column
80. Metadata – Process
1. Identify common elements
2. Identify unique elements
3. Associate at the appropriate level(s) on the appropriate content
type(s)
81. Metadata – Process
Document Master Document
Corporate
Document
Invoice
Purchase Order
HR Document
Offer Letter
Salary Increase
Request
Termination Letter
Marketing
Document
Ad
• Employee Name
• Termination Date
83. SharePoint Building Blocks
Content Types
• Use to…
• Maintain consistency across
libraries and lists
• Isolate workflow, policies, and
other settings
• Information Management (Records
Management)
• Etc.
Site Columns
• Use to…
• Drive views
• Expose via search
• Drive reports
• Preserve information
• Trigger workflow
• Etc.
84. SharePoint Building Blocks
Farm
Web
Application
Content
Database
Site
Collection
Site List/Library
Item
Item
Site
Collection
Site List/Library Item
Site List/Library Item
Content
Database
Site
Collection
Site List/Library Item
Web
Application
Content
Database
Site
Collection
Site
List/Library
Item
Item
List/Library ItemSite
Collection
Site
85. Taxonomy/Context – Uses
• Leverage security (List, Site)
• Differentiate list-based workflows (List)
• Segregate content (List, Site, Site Collection)
• Facilitate geographic placement (Farm)
• Control versioning (List)
• Account for alternate authentication method(s) (Web Application)
• Account for encryption (Web Application)
• Etc.
86. Taxonomy/Context – Approach
1. Determine what content is needed where
2. Associate at the appropriate level(s) with the appropriate
container(s)
87. Taxonomy/Context – Considerations
• The content that will be stored as items
• The site and list/library columns that will identify, qualify, and differentiate those
items from each other
• The content types that will help maintain appropriate metadata, workflow,
behavior, and other settings for different kinds of items
• The lists/libraries that will segregate those items within the sites
• The sites that will contain those lists/libraries
• The site collections that will contain those sites
• The content databases that will house those site collections
• The web applications that will contain those site collections
• The farms that will host those web applications
88. Site Templates
• Assets Web Database
• Basic Meeting
Workspace
• Basic Search Center
• Blank Meeting
Workspace
• Blank Site
• Blog
• Business Intelligence
Center
• Charitable
Contributions Web
• Contacts Web Database
• Custom
• Decision Meeting
Workspace
• Document Center
• Document Workspace
• Enterprise Search
Center
• Enterprise Wiki
• FAST Search Center
• Group Work Site
• Issues Web Database
• Multipage Meeting
Workspace
• Personalization Site
• Projects Web Database
• Publishing Site
• Publishing Site with
Workflow
• Records Center
• Social Meeting
Workspace
• Team Site
• Visio Process Repository
89. Library Templates
• Asset Library
• Dashboards Library
• Data Connection Library
• Document Library
• Form Library
• Picture Library
• Record Library
• Report Library
• Slide Library
• Wiki Page Library
90. List Templates
• Announcements
• Calendar
• Contacts
• Custom List
• Custom List in Datasheet View
• Discussion Board
• External List
• Import Spreadsheet
• Issue Tracking
• Links
• PerformancePoint Content List
• Project Satisfaction Survey
• Project Tasks
• Status List
• Survey
• Tasks
91. Content Type Publishing
Advantages
• Manage ‘Enterprise Content
Types’ across site collections,
web applications, and farms
• High governance/control
• Higher reuse
Disadvantages
• Inheritance/Publishing
• Workflows
• Lookup Columns
• Backup/Restore/Disaster
Recovery
95. Deduction
Management
Site
Deduction
Library
Customer
Operations Site
Deduction
Contract
Library
Advertisement
Library
Billback Library
Syndicated
Data Library
Spin Report
Library
Scan Data
Library
Markdown
Funds Library
Repay Library
Markdown
Funds Site
Contract
Advertisement
Billback
Repay
Scan Data
Spin Report
Syndicated
Data
Customer
Customer
Customer
Customer
Customer
Customer
Customer
Deduction Type
Customer
Date Requested
Date Range Start
Date Range End
Contract Documents
Advertisement Documents
Billback Documents
Deduction Number
Repay Documents
Scan Data Documents
Spin Report Documents
Syndicated Data Documents
Product Category
Markdown
Deduction Status
107. Key SharePoint Limits
• Boundary: Static limits that cannot be exceeded by design
• Threshold: Configurable limits that can be exceeded to accommodate
specific requirements
• Supported: Configurable limits that have been set by default to a
tested value
108. Key SharePoint Limits
Limit Limit Type SharePoint 2010 SharePoint 2013
Farm
Content Databases Supported Not Specified 500
Site Collections Supported Not Specified 500,000 Personal Sites
250,000 Non-Personal Sites
Web Application
Content Databases Supported 300 Not Specified
Site Collections Supported 250,000 Not Specified
Content Database
Size Supported 200 GB – 4 TB 200 GB – 4 TB
Site Collections Supported 5,000 10,000 Total Sites
2,500 Non-Personal Sites
Items Supported 60,000,000 60,000,000
109. Key SharePoint Limits
Limit Limit Type SharePoint 2010 SharePoint 2013
Site Collection
Sites Supported 250,000 250,000
SharePoint Groups Supported 10,000 10,000
Users Supported 2,000,000 2,000,000
Site
Subsites Threshold 2,000 2,000
Lists or Libraries 5,000 Not Specified
Blog Posts Supported 5,000 5,000
Blog Comments Supported 1,000 1,000
110. Key SharePoint Limits
Limit Limit Type SharePoint 2010 SharePoint 2013
List or Library
Items Supported 30,000,000 30,000,000
Items in a Folder 5,000 Not Specified
Items in a View Threshold 5,000 5,000
Joins in a View Threshold 8 8
Unique Security Scopes Threshold 50,000 50,000
Columns Threshold 276 Single Line of Text
192 Multiple Lines of Text
276 Choice
72 Number
72 Currency
48 Date and Time
96 Lookup
96 Yes/No
96 Person or Group
138 Hyperlink or Picture
48 Calculated
94 Managed Metadata
276 Single Line of Text
192 Multiple Lines of Text
276 Choice
72 Number
72 Currency
48 Date and Time
96 Lookup
96 Yes/No
96 Person or Group
138 Hyperlink or Picture
48 Calculated
94 Managed Metadata
111. Key SharePoint Limits
Limit Limit Type SharePoint 2010 SharePoint 2013
Document
Size Boundary 2 GB 2 GB
Major Versions Supported 400,000 400,000
Minor Versions Boundary 511 511
Coauthoring Concurrent Editors Threshold 10 10
Page
Web Parts Threshold 25 25
Security
SharePoint Groups per User Supported 5,000 5,000
Active Directory Groups or Users
per SharePoint Group
Supported 5,000 5,000
112. Links
SharePoint 2010 SharePoint 2013 SharePoint Online
Resources for IT Pros bit.ly/SP10-Resources bit.ly/SP13-Resources bit.ly/SPO-Resources
Features and Editions bit.ly/SP13-Service bit.ly/SPO-Service
Limits and Boundaries bit.ly/SP10-Limits bit.ly/SP13-Limits bit.ly/SPO-Limits
SharePoint Maturity Model www.sharepointmaturity.com
Guidance for Modifying Pre-Defined Taxonomy bit.ly/17KHAuw
Discontinued Features and Functionality bit.ly/1bhrLKr
113. Links
My Knowledge Management (KM) Resources Click Here
My Enterprise Content Management (ECM) Resources Click Here
My Web Content Management (WCM) Resources Click Here
My SharePoint Resources Click Here
My Records Management Resources (RM) Click Here
Editor's Notes
Good Evening…
I’ve been coming to BASPUG for quite a few years now, so it’s nice to be presenting to you tonight and I hope we’ll get into some good conversation.
We’ve got about 60 minutes or so…
We’re going to do some quick getting-to-know each other,
then I’m going to give you a bit of an orientation.
We’ll get into the nuts and bolts,
attempt a live mini-design exercise using some of what we learned,
and finish up hopefully with some extra time for Q&A
SOUND GOOD?
VERY BRIEFLY about me…
Currently I’m with a really great company here in Boston—you may have heard about them 30 seconds ago…
I’m about a year into this role; I’ve had about four years of consulting under my belt and previously I’ve been in a corporate role as well
Been working with SharePoint for coming up on nine years now
I’m not a developer!
Major focus is on wrestling with all the ‘m’ acronyms… DM, ECM, WCM, KM…
Here’s how to ping me
But enough about me…
Let’s find out a little about all y’all.
Just so I get an idea who I’m talking to…
Do we have any
Developers?
Administrators?
Business people/end users?
What made you come tonight?
What do you wanna know?
You may have heard SharePoint does this thing called CM—whatever flavor it may be
Why are we talking about this?
SharePoint tells us that it can handle a LOT of different things—many more not up here on the screen.
Well…
Do you want to turn all this stuff on and hope for the best?
The goal is to create Pleasantville.
But you’re going to end up in the Wild West if you don’t think carefully about some of the stuff we’re going to talk about tonight.
To start off, we’re going to get into these 2 things, find out what they are, and how they relate to each other.
Hint: The answer is already up there.
We have this term out there, CONTENT ARCHITECTURE. What is that?
It’s about Content Management
Here, we’re looking at two parts to the whole
1. A specification. What’s that? It’s an outcome
2. Activities and outputs. We’re talking about a process
It’s part of a process which is going to help you achieve your content strategy and will form the foundation for content management
But let’s get to the ‘big’ word for today…
We’re here to talk about taxonomy…
What is this thing called TAXONOMY?
Simply…
OK so we’re going to be categorizing our stuff. Cool.
Even more simply…
In talking about these big concepts—content architecture and taxonomy--What are the common threads here?
What does taxonomy as part of content architecture look like?
It’s structuring
And organizing
How are we going to get there?
We’re grouping things
To be able to classify and categorize
Why do we work with taxonomy?
Again, findability
And usability
CONTENT
It’s also about your USERS.
It’s about half and half. Some people like to follow a map and street signs along the way to get to where they want to go.
Others like to search for their content and expect it to come up pretty high in the result set.
What kind of person are you?
Think about your email. If you’re a filer and have tons of nested folders that you put your emails into, you’re probably an green ‘navigation’ person.
If you’ve got all your emails in your Inbox and anytime you want to find something you type in a keyword or you group and sort by sender, you’re probably a purple ‘search’ person.
You have to consider both approaches in building out your taxonomy.
Once you’ve located some content…
We want some qualitative data about the content to differentiate it from the sea of other documents
The goals, again, are helping users FIND their stuff and USE it effectively.
To recap…
Taxonomy is part of the bigger picture; shouldn’t be examined in a vacuum.
Other parts of your content architecture will include policies, workflows, etc.
Remember that content architecture is the foundation for CM
Taxonomy is the map; the plan; the blueprint in SharePoint
My major point here is:
You must plan ahead if you want to get all the way there
This stuff is not black and white or one-size-fits-all.
I cannot tell you today an exact process to follow that will work for everyone in every case for all content.
And if you approach your users or whoever you’re working with on this stuff with the same solution every time, you’re doing it wrong.
At the same time, working through this stuff should consist of two complimentary objectives.
We saw this in the definition for Content Architecture…
You’re going to embark on the process because you have a desired outcome.
But, your outcome is going to be influenced by undertaking that process.
So everyone’s on the same page…
Going through the process
Helps people ideate
Can remedy bad things that didn’t work out in the past
Therapy session
Gets users to feel a sense of ownership; they’re going to help build it—not just be delivered something they didn’t have a part in shaping
At the end of your process
You should end up with documentation
You should also have some things that aren’t written out in sentences, like spreadsheets and charts that help illustrate the plan
All this stuff applies way beyond SharePoint
But… we’re at a SharePoint User Group meeting, so we’re going to stick to SharePoint.
I just met with a client today that is looking at this exact problem.
They’ve gotten their hands on SharePoint online, Office 365, they’ve played around with it a little, and they have a user community that has been starved for attention for years.
They want to let them in and provide some value as soon as possible, in a largely self-service paradigm.
We had a lot of conversation today around drawing up a plan for the foundation before they start building the house.
You get ahold of SharePoint.
You’re about to send out the email telling everyone the day has come and all their problems will be solved.
STOP.
As easy as it looks, as tempting as it may be…
Don’t do it.
If you don’t go through this process and plan ahead and communicate across all of the participants, stakeholders, sponsors, etc…
I’m going to be throwing a lot of information at you.
Please, not for my own sake… go read this white paper.
Planning
Documenting
Inheritance
OK here we go!
We have ALL these things to build with in SharePoint, and more…
How do we do it right?
Let’s start off with the basics.
We’re going to review what content types and site columns are
We’re going to put them together to be able to track metadata on our content
We’ve going to have our content types and site columns. Together we’re able to associate metadata appropriately with our content.
We’re going to have our sites, libraries, and lists (a.k.a. our containers in SharePoint)
That’s going to get us context, the logical architecture, for our content.
Deciding where to use all of our tools is what will bring our taxonomy to life.
60 minutes is not a lot of time.
We’re going to pretend…
SharePoint has two main constructs that we’re going to focus on at the outset: content types and site columns.
This is Microsoft’s definition right off of TechNet of a content type in SharePoint
Big word here: REUSABLE
Pay attention to the words in purple; these are reasons/qualifiers for why you would consider using a content type and for creating different content types
And notice our key term here about categories of items
A content type is not just a tag
Out-of-the-Box Content Types
They’ve always been there behind the scenes; you may not have realized you’ve been using them the whole time since SharePoint 2007
Some things to notice here…
There is a parent-child relationship model here
These things aren’t just one-offs
All things derive from Item (ultimately System)
Some are super special SharePointy things
Let’s take a look at the common OOTB ones that you interact with all the time.
Notice the parent-child relationship.
A picture is a further developed kind of document
A document set is actually a kind of folder
(I simplified some of the relationships here.)
Two major branches—item-based and document-based
Where an item is basically a row in a list
SharePoint content is all stored in lists. Libraries are lists. They’re just designed to store document-based content types.
Document-based content types are designed with the primary element being a file.
An item can have a file attached to it.
Item
Contact
Event
Document
Self-explanatory
Folder
A thing that holds documents
Document Set
A super special ‘binder’ but it’s a folder on steroids
Show the default content types
Show enabling content types in library; show Document content type
Content Types have a scope in a site structure within a site collection.
Content Types are only visible downward.
Let’s take a sample site structure and a few example content types.
I could just define these in the topmost site…
But, instead…
Content Types inherit properties from parents
This is why you might want to consider what I call an abstraction layer
Transactional vs. Abstraction
Let’s use this sample list of content types again
This is perfectly valid.
But it doesn’t follow our directive to plan ahead.
This is going to get unwieldy when the list grows to more than a half-dozen content types.
You’ll want to introduce a level of abstraction.
Here I’ve grouped the documents that have to do with human resources under a parent content type of ‘HR Document’
This is your abstraction layer.
I’m never going to USE this content type transactionally, meaning I won’t enable it in a library and assign this content type to a file.
Thinking ahead, I may want to put even more abstractions in place.
What does this get me?
The Ad is just one content type; why abstract it already?
You can’t insert a level in later on.
In fact I always insert one ultimate abstraction point just below Document so I have that place to influence all my custom content types without modifying the out of the box
Keep in mind the reasons I might want to instantiate another content type.
For example, I may want to isolate a workflow.
Let’s say I have this snippet of my content type hierarchy.
Obviously this inherits downward from document or form…
These are all transactional content types; I will be using these for real documents or forms.
This is certainly a valid model.
What you want to be careful of when inheriting a transactional content type directly from another transactional content type are any deviations downward that you may have to account for.
For example, I could set up a workflow for all shipping requests here.
That will apply downward to all 6 other content types
But let’s say I have a different approval process for expedited shipments.
I could set up a workflow on only that content type.
BUT, do I want BOTH of those to run?
No.
So I have to remove the other one.
OK… BUT what happens when I update the shipping approval workflow settings and I need to propagate those downward to the 5 other content types that need it?
Let’s say I have yet another workflow I need to perform on things that are shipped internationally; I need to get some sort of authorization to export out of the country.
OK… I can set up a workflow here, and another workflow here.
Do I have to remove the other workflow?
Maybe not because both actually need to run; they’re separate processes.
BUT (depending on how I set this up as reusable workflows/list/library workflows…) these may end up being two copies of the same workflow.
Not the best way to manage that because I have to make changes twice.
What could be a better way of setting up these content types?
I’ve added several abstraction layers here.
I can now define all three of my workflows in only one place, and all the content types that require them will have them and the ones that don’t won’t.
I’ve even thought ahead and split up the standard and non-standard request types because perhaps in the future I can foresee a separate workflow being needed for those.
Now this may not be ideally appropriate for OTHER settings like metadata.
I’ve now lost my inheritance between the 2 air freight content types and the inheritance between the 2 ocean freight content types.
You need to figure out what’s best for the business problems that you’re trying to solve and balance that with the setup and maintenance
Changes that you make at a certain level could be overridden
List/Library content type is linked but is just an instance/copy; they’re not one in the same
This could work to your advantage or your demise
Workflows
This is sometimes a good way to not have duplicate copies of the same document if it is needed in different places.
OK; next we’ve got site columns
Again, we’ve got TechNet to tell us the medical explanation
Again, notice the word REUSABLE
OK; next we’ve got site columns
Again, we’ve got TechNet to tell us the medical explanation
Again, notice the word REUSABLE
There are types of columns in SharePoint; they each have their own unique characteristics and field controls—the way the column is rendered in a newitem or edititem .aspx form
So, like content types, site columns have a scope—downward
The same rules apply
Like content types, there are instances/copies of site columns in libraries/lists
UNLIKE content types, you can instantiate a column in a library/list, but that’s not a site column and only has relevance to that container only
Required
One of the decisions you often have to make is when to employ one of these types for giving users a selection of things to pick from
Choice
Easy text
Never updated
Lookup
Can’t use across site collections
Has a scope
If you need to store additional metadata ABOUT the choices
Can help you with things called projected fields
Not all columns will project
Scope applies to lookup columns as well and can be used to your advantage.
Managed Metadata
Got this in SharePoint 2010
Only way OOTB to use a consistent set of terms across site collections—even web applications and farms
What’s altered this decision a bit is SharePoint 2013’s managed metadata extended properties.
Show sample MM hierarchy
You want to track data that will actually be of value.
Just because you can set up a column for your document approver’s shoe size doesn’t mean it’s relevant. You can have too many columns and it will be laborious for users to adopt the practice of providing that data to the system.
If your data has a low likelihood of ever being populated, perhaps because it’s not required, it can lead to bad data and the items that did have the field filled in become less valuable because it wasn’t done consistently.
This is a balancing act.
SharePoint’s going to refer to your column differently depending on how you’re referencing/accessing it
Programmatically
UI
Central Admin - Search
Show column properties
What is METADATA?
Simply…
You’re already using it and may not realize it.
Outlook
iTunes
From your Camera…
In SharePoint…
At the very least:
Created
Created By
Modified
Modified By
And an item always has Title
A document also has a name, which is the filename
We ASSOCIATE the site columns WITH the content types to get metadata
How do we decide where to set up the columns in our hierarchy?
For example…
The same goes for other settings on these content types, by the way.
Remember that we can isolate workflows, for example. We could set a retention policy. The same consideration applies to these.
I want to discuss how the components and concepts we’ve talked about so far progress and feed into your taxonomy.
We’ve got our content types and site columns. Together we’re able to associate metadata appropriately with our content.
Nothing happens with these until we instantiate these in particular containers within SharePoint.
Deciding where to do this with what building blocks is what brings your taxonomy to life.
Why do we care about all of this stuff?
Content Types, Site Columns, Metadata
Our content types and our site columns are building blocks that can be used/instantiated in different places to effect different results and support our goals of finding content and making it usable within SharePoint
SharePoint gives us several layers to work with from the farm all the way down to individual items.
It’s important to understand what can be configured where and the scope of those decisions.
Line of demarcation
On-Premise vs. the cloud
So in understanding your taxonomy and how it’s going to work and support your business processes, manage your content, comply with your security requirements… you need to understand the holistic view of how all of these things will work together in SharePoint.
To make it very basic…
Work your way up the layers
Again, there’s that line of demarcation.
OOTB we’re given several very different site templates.
OOTB we’re give several different library templates.
OOTB we’re given several different list templates.
These will all accelerate you getting started.
A few words about Content Type Publishing and the Content Type Hub…
This allows you to trump that line of demarcation we just saw, with your content types, and have consistent definitions and settings across site collections, web applications, and even farms.
It is incredibly important to consider and plan out the organization of the content that you’re going to manage.
SharePoint has certain constructs built-in to set you up properly for being able to employ many of its features.
I want you to understand not only what taxonomy is but that it’s part of a bigger idea.
I want you to understand the tactics for working with your taxonomy.
I want you to understand the goals for working with your taxonomy.
I want you to think about this stuff BEFORE you let your first user into your site.
Governance can be a whole week’s worth of other sessions and discussion. I encourage you to do a lot of research or call us for help ;-)