Metadata architecture question, help needed

We are currently storing all of our metadata within the DCR, which requires the users the rekey the information into the DCT. (its keyed initially into a workflow)

we recently had consultants here and they were not impressed with this architecture and recommended we use EAs and TS metadata.

we would like to change and use TeamSite metadata and extended attributes. from a high level, what all would be involved? i know we would have to enable and configure TS metadata.

would u recommened switching as soon as possible? we are currently on TS 5.5.2 sp2...would be better to switch methods after an upgrade to TS 6.1 first?

---------------------
Eric B.
Federated Investors
AOL IM: arthas76

Find more posts tagged with

Comments

nipper

This is not something you can get a solid answer from devnet. I think you need to pay consultants lots more
money. :-)

Can you replace DCRs with EAs - yea.

Does metadatacapture have all the features that templating does ? no.

CHeck the manual, but used to be you could not do formapi (still can't I think), visual formatter,
inline callouts (I think you can do this now on MDC). So what are you doing with the DCRs ? Are they
simple ? Then yes. Also, IIRC MDC is not as granular for different branches, projects, etc.

We want to replace DCRs with MDC, but it does not have the functionality we need (plus the fact that once
in a while we have a 5-10K DCR due to VFE).

HTH

Andy

iwovGraduate

Based on limited information I have about your requirements and existing architecture its hard to say. I can only point out a few things you should consider. In certain cases, it may be viable to do so; however, in general I would say that storing metadata within the DCR is not architecturally sound.

From what you say it seems that you are entering and/or storing metadata more than once. Your users should not have to enter the information more than once, and you should have a single source (does not mean you cannot export your metadata to XML or DB to be used by other applications) for it, preferably extended attributes.

How big of a change would it be - again it depends how your data is used, how much content you have, etc. From your user's perspective: they will have two separate steps/screens - one to enter content (DCT) and one to enter metadata (MDC). If you are planning to make this change as well as upgrade in the near future, I would recommend you do not spend too much on customizing the existing solution without taking these two things into consideration.

Also, keeping metadata as extended attributes would give you a straight forward path in case you want to utilize MetaTagger's advanced functions such classification, recognition, extraction etc. I have known implementations where they did not want to make this change and re-invented the wheel of MetaTagger in form of TS customizations. On the other hand, MDC is very limited in its capibility in comparision with Templating. You cannot use FormAPI, etc. with MDC.

In my experience a "big bang" approach often leads to bigger problems. So take one step at a time. Just my $0.02

gzevin

I have just developed a process of moving from DCR-based metadata towards EA-based.

it involves a 2-step change and regeneration.

if you are interested, mail me.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

good feedback, thank you. let me give a little more background.

i think one of the reasons we didnt use the TS metadata was that our business units refused to fill out another form (wf + DCT + metadata capture)

also, we have alot of custom metadata besides the standard stuff (expiration date, publish date, search keywords, etc) that is DCT category/datatype specific. if i wanted to use TS metadata all of this custom metadata would have to be moved to the additional metadata form correct? or could it all be passed from the workflow via EAs? this seems like it would be alot of work on the WF end tho, since each type would need customized WF options

its disappointing that everyone ive spoken to (along with this feedback) seems to say storinh Metadata in the DCRs is not architecturally correct. i have no idea why the consultants/integrators set it up this way then!

---------------------
Eric B.
Federated Investors
AOL IM: arthas76

Adam Stoller

i have no idea why the consultants/integrators set it up this way then!
Generally [IMO] (a) lack of knowledge, or (b) short-sightedness and/or (c) dissatisfaction with the appearance / behavior of the OOTB Metadata Capture form, which hasn't received any attention until TS6 where it has been replaced with the MetaTagger UI - though still not 100% in-sync with the main Templating/Forms Entry view.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

nipper

>i think one of the reasons we didnt use the TS metadata was that our business units refused to fill out another form (wf + DCT + metadata capture)

THis is a very valid reason to leave MD in the DCT. UInless you are using MetaTagger, there may not be a compelling reason to change.

>also, we have alot of custom metadata besides the standard stuff (expiration date, publish date, search keywords, etc) that is DCT category/datatype
>specific. if i wanted to use TS metadata all of this custom metadata would have to be moved to the additional metadata form correct? or could it all be
>passed from the workflow via EAs? this seems like it would be alot of work on the WF end tho, since each type would need customized WF options

Lets look at what you are trying to accomplish. Depending what screen you want this entered in byt the user, will determine how the default
implmenentation will store the info (DCR, EA). You can make a DCR save something as an EA, but it takes a non-trivial amount of extra work.

First consider what you want to accomplish. What data are you collecting and how do you want to use it ? Also if it works now, why change ?
Your users will always have DCTs & WFs, what do you hope to get out of adding MDC ?

>its disappointing that everyone ive spoken to (along with this feedback) seems to say storinh Metadata in the DCRs is not architecturally correct. i have no
>idea why the consultants/integrators set it up this way then!

I do not necessarily agree with that statement. You have your choice. EAs & MDC are used more often for non-DCR content than for DCR
content.

Andy

Migrateduser

No, storing metadata as extended attributes sucks. For one thing it limits the length of values to something like 4000 characters. It also requires iwextattr and parsing which is bad for performance, when you are probably already parsing the DCR using XPath or tpl. And your users have to enter data in two UIs, and all of the DCT functionality is not available in MetaTagger. Wait, maybe it's MetaTagger that sucks. Also, if you deploy DCRs to a non-IW server (or even a process on the TeamSite server that doesn't know Interwoven APIs), the EAs are not available - if it's in the DCR XML then it's always available.

Who did these consultants work for?

Edited by JimmyFat on 05/10/04 10:22 AM (server time).

JonathonG

Personally, I would tend to agree with what nipper said (*gasp* that's scary Smiley Wink

).

MDC is best for non-templated content. If you've got a mixture of templated/non-templated it may be a better architecture to capture metadata in a consistent manner, i.e. via MDC. However, if you are at a site that is doing 90% or greater templated content, I would argue that a user-friendly approach of single point-of-entry may actually be better.

At my current customer, we have all metadata captured through DCTs. In the rare case of non-templated content (typically uploaded PDFs, DOCs, etc.), we have created an "upload" DCT. This captures the *same* metadata in the *same* manner. And, it then helps to automate the upload process by giving the user upload functionality through the template.

I guess I would land on saying that the "correct" metadata storage strategy is somewhat requirements dependent.

Jonathon
Independent Interwoven Contractor