Here's an easy way to understand the Content Server

Oracle Content Server is the foundation of Oracle Universal Content Management Suite. It's the center product. Other major UCM modules, such as Web Content Management and Document Management are built on top of it.

Think of the Content Server as a central database for storing content. A database analogy is the easiest way to understand it.

In fact, you can think of a Content Server as one huge table that can store millions of records.

And the only major difference between Content Server and a database server is the fact that every record in it has revisions and can go through the workflow.

Every row in the table would be a single content item. Every field in that row would be a metadata field — just like in a table in SQL Server or Oracle or MySQL, or any other database you are comfortable with.

And just like a row in a table you can add and remove fields to fit your organization's requirements.

Every database, as you know, has standard or system fields. And just the same way Oracle Content Server has pre-defined metadata fields; the system metadata fields. It also has custom metadata fields.

Let's take a quick look:

1. On your VM, go to http://localhost/idc. You'll see a login screen as seen in the screenshot below.
2. Click on the Login link. Type sysadmin for user name and idc for the password. Your Content Server Home page loads as shown in the following screenshot:
3. Now click on New Check In. The check-in form loads as shown in the following screenshot:

Ugly, isn't it? Imagine getting your end users to fill a form like this every time they have a document to check in! The good news is that you can easily personalize this form with custom rules and only show the fields you want your users to see.

Did you notice that some of the field names have an asterisk in front of them? Yes, those values are required, but in our case, those are system fields. Here's a quick description of some of the major metadata fields you'll be sure to deal with:

• Content ID: A unique identifier of the content item in the system.
• Type (content type): A built-in metadata field that allows you to specify a broad category for this content item, such as "Vendor Invoice", "Human Resources", or "Project Plan".
• Security Group: A metadata field that controls an item's security. I will give you later in the following chapters.
• Comments: A place for extra info about the content item. This filed is custom or extended metadata.
• Release Date: The date this item is "released" into the system. In most cases, that would be the date of its original check in.

Custom metadata fields are the ones that you can define and manage and even delete if you wish. System metadata fields, such as content ID or title, are part of the system and are required for Content Server to function properly.

You can use metadata values to find content in the database and you can search by any combination of fields. Content Server even has a simple, almost SQL-like query language. Or you can search by individual field just like in Windows Explorer you can search files by name or modification dates.

But that's where the similarity ends. Unlike Windows Explorer, you don't necessarily have a folder structure in Content Server. The actual content store is flat like a database table.

But most organizations prefer to use hierarchies such as shared drives, file plans, retention schedules, and so on. Can you continue to use them with Content Server? Yes, you can!

Your users can continue benefiting from taxonomies, from the knowledge your organization has accumulated, and you can continue using that filing system if it still works well for business folks.

Each content item may be associated with a virtual folder. Remember, the content is not physically stored in that folder. It is just linked to it so that users can also find it that way — in addition to using the search feature.

Virtual folders provide users a convenient and familiar metaphor for storage and classification. Content Server folders may be browsed just like other, familiar systems.

We will have a longer discussion on Virtual Folders once we get to Chapter 7, Under the Hood.