Well, after the little amichi vendor slamming, I am a little leary about
posting this, since it does indirectly support a product offered by my
company, but I think it is still useful information based on your question
about metadata. This is a short article I wrote talking about storing
metadata/content in a relational format vs. an xml format.
Please note that I was not an english major.
--------------------
Content Management Systems know nothing about your Content
David A. Vap, Software AG
It is an irony. Most people think that the rollout of a Content Management
System (CMS) will provide an everlasting vault of valuable content that can
be easily found and reused. The truth of the matter is that the first
generation CMS applications do not natively understand your content - making
reuse and searching difficult. How can that be you ask? After all, they
are Content Management Systems. They must know and understand the content
that is being ingested into them.
Well, let's look at how this state of affairs has evolved. When Interwoven,
Vignette, Artesia, and others set about building their first generation
applications about five years ago, here is what the technology landscape
looked like:
- Relational technology was pervasive and accepted as primary
persistence layer
- SGML, the XML precursor, was only used for complex technical
publishing
- Content formats were primarily proprietary
- HTML was all the rage
So, logically, these vendors built their products on top of relational
technology. Much of the content was viewed as a black box and metadata was
wrapped around the content and stored in a set of relational tables. The
metadata stored a pointer out to the actual essence (content), which was
stored either on the file system or in a streaming server. So, in reality,
first generation CMSs are really just middlemen. They take content in, make
an inventory of it using user assigned metadata and then pass it on to some
distribution channel. If you asked the middleman the details of what is
inside the box on their shelves, they can't tell you. They only know what
is on the shipment manifest.
A few years later, XML started gaining momentum. XML became the accepted
vehicle for both internal and external tagging of the content. At this
point it was too late in the development cycle to pull out any relational
underpinnings and convert to a native XML store, so the vendors did the next
best thing. They provided frameworks for importing and exporting the
content in an XML format. This required a fascinating Cirque Du Soleil act
to convert the incoming XML stream into a set of relational tables that
meta-modeled XML structures. Anyone who has done this before knows, XML to
Relational Mapping can get quite complicated. It can only be done for a
subset of XML Documents and often round-tripping of a XML document is
impossible. For example, ask your content management vendor to handle in an
intelligent manner a SCORM eLearning or METS document in their relational
structure.
As always happens with software, subsequent generations of applications must
provide substantially greater functionality in order to interrupt the market
and leapfrog larger first generation vendors. This is exactly what is
happening in applications that are Content Oriented, including your typical
CMS solutions.
Since then, it has become accepted that XML is the primary medium for
content. The majority of the content creation vendors such as Adobe and
Microsoft have moved their product portfolios to natively store their output
utilizing XML standards.
It would be really nice if next generation CMS knew more about the actual
content of the content and, that is exactly what is happening. Next
Generation CMS vendors are storing content directly in a native XML store.
The benefits of this are numerous
-easily change the metamodel representing the content via simple schema
changes, reducing the cost of administering the system
- search on the values of specific content tags, allowing for better
searching and reuse of content
- reduce development/maintenance costs associated with
1) transforming xml based content into relational formats
2) providing baseline content management services covered by
WebDAV (available in most native XML databases)
- ability to easily integrate content with other systems utilizing XML
as the transport
- easily transform content for different delivery devices via W3C
standards such as XSLT
-----Original Message-----
From: Mattias Konradsson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 05, 2003 4:47 PM
To: [EMAIL PROTECTED]
Subject: [cms-list] managing metadata
I'm working on a cms system and time has come to do the metadata stuff. I
don't have much experience in this aspect of the cms so I'd like to hear
your thoughts
about what essential features one should include, anyone has any good
experience to share on the subject?
I've also figured out two ways I could implement metadata, either to simply
store xmldata for each document which then can be aggregated into one big
document which you can run powerful xpath expressions against. The other
method is using a dynamical database implemented in sql where you can define
different attributes for each document. The problem with the first approach
is that the aggregated xmldocuments are potentially huge and loading it into
memory for searching would probably mean a performance hit. Method nr 2
should work pretty well , should even be able to convert the sql tables to
xml if you want to do xpath or to direct sql searches, only downside I can
see is that the metadata probably can't be as hierachial complex keeping the
xml shallow. On the other hand I'm not sure metadata needs to be that
structurally complex, any thoughts?
best regards
---
Mattias Konradsson
--
http://cms-list.org/
more signal, less noise.
--
http://cms-list.org/
more signal, less noise.
