TeamSite Metadata

One of the TeamSite branches on our TeamSIte server does not capture metadata as part of the workflow. In this branch basically collect all the metadata in the DCR. Then DCT fields are published to a MySQL database. Does anyone know any issues doing this way? We are currently planning on upgrading TeamSite to 6.5 from 5.5.2 SP6.

One of the major reasons to have metadata captured as part of DCR is that users did not want the extra step to fill in metadata.

Regards,
Damitha

Regards,
Damitha Bogahawatta
Senior Software Engineer
Resolute Information Technology

Find more posts tagged with

Comments

gzevin

I consider this as a 'legacy approach' that does not conform TeamSite's architecture. However, it works.

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

Adam Stoller

If you search through the forums (probably a year or more ago by now) you can find a number of posts regarding this topic.
The basic pros/cons are:
- [pro] separation of content from metadata
- [con] separate UIs that look and behave differently

I believe 6.7 (early next year?) is supposed to [finally] use the same UI engine for both templating and metadata capture, which will go a long way to removing the 'con' above - but it will still be an additional step in the process of creating assets within TS (which may or may not be a "bad thing").

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

smenon

A couple of corrections -

TS 6.7 will contain the infrastructure to unify the datacapture frameworks, but all the applications/UIs will not be migrated to use that infrastructure in the 6.7 timeframe. We are targeting the WF datacapture/instantiation as the first application that will use this infrastructure and then post TS 6.7 we will look to migrate the metadata and forms publisher UIs to this new infrastructure.

When this new infrastructure is available and exposed, you should be able to specify mutliple data-sources to the form such that you could envision building a Form where some of the fields could be saved as DCRs where the other fields could be saved as EAs on the DCR. This will allow you to present the end-user with a single form to capture both EAs and DCR data.

I hope this makes sense.

--Sunil Menon
Product Manager
Interwoven, Inc.

gzevin

>This will allow you to present the end-user with a single form to capture both EAs and DCR data.

>I hope this makes sense.

actually, it does and it does not in the same time. I always advocate the usage of the MD capture as a separate step, as it allows bulk attachment of metadata to a number of assets (both HTML and non-HTML ones). Also, metadata ususally describe the target HTML, not the originating DCR (i.e. there potentially could be multiple HTMLs coming from the same DCR) and architecturally it makes sense to do this uniformly, in all cases.

However, I could see some limited usage of what you have just described.... but still I feel this is some step in a backward direction....

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

Adam Stoller

Hmm - interesting. I probably share some of the same concerns that Greg mentioned.

For my purposes - I'd be a lot happier if I could use FormAPI within a metadata capture form, and if the help/description items and marking of required fields were consistent between the two.

Expanding this to the workflow instantiation form opens up need for additional thought. At first blush, if it provides me with the ability to do the FormAPI stuff, I'd say "good" - but trying to figure out the mechanics of designing the instantiation form and integrating the information from that form into the WFT (or would this only be with the *new* workflow development tool?) leaves lots of room for issues.

I realize it's still pretty early in the scheme of things (since 6.7 isn't due out until sometime in 2006) - but I hope you'll be able to expand on this in more detail over the next 6 months ...

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

gzevin

another thing I would want to add - while I do advocate tagging multiple files at once, the performance of this interface with a large metadata DCT is pathetic when it comes to more than a handful of files.....

So, while I see what IWOV is doing, I agree with you that I'd rather see some action on the metadata capture front

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

smenon

I am not advocating that both metadata and DCRs be always captured in a single form. I was highlighting one example where might want to save the data from a single form into two different "data sources". There are some use-cases where it might be relevant to capture metadata on the same form - although as you point out, it is a limited use-case and might not be appropriate in all scenarios.

Also, to address ghoti's request for FormAPI on the metadata capture UI - with the new infrastructure you will have a JavaScript API that will allow you to manipulate your form fields.

--Sunil Menon
Product Manager
Interwoven, Inc.

gzevin

sounds good Smiley Happy

cannot wait Smiley Happy

with the MD capture performance - is anything being done about it? we have whole sites that I cannot make use of it because I cannot mass tag, say, fifty files

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

Adam Stoller

Depending on your MDC requirements there are other things that don't quite work the way you might like them to when tagging multiple files - specifically being able to address multiple fields via cgi-callout code if all the fields don't appear on the same 'page' of the UI - this makes cross-field validation of the form tricky at best - and I don't think FormAPI will fix that.

It might be better for the above case, and possibly for performance too, if when tagging multiple files the UI presented the form the same way as it does when tagging a single file (perhaps with the addition of somewhere indicating all the files that are being processed) and then let the underlying engine deal with applying all the EAs to all the files when asked to commit the changes. This won't help situations where you'd like to use multiple tabs for the form, but it would help when dealing with multiple files using a single-page form (I think).

For bonus points, when committing the changes, the screen could display the list of files as they're being processed - it may add a tiny bit of time to the overall process but psychologically it will make it seem faster because you can see it doing something as opposed to staring at a watch-icon cursor ;-)

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

gzevin

and also... the way multiple files are tagged is very strange - say, if we have had tabbed metadata, the tabs disappear when tagging multiple files. I winged about it since beta-testing of 6, and nothing seems to being done to address this.

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

Adam Stoller

and also... the way multiple files are tagged is very strange - say, if we have had tabbed metadata, the tabs disappear when tagging multiple files. I winged about it since beta-testing of 6, and nothing seems to being done to address this.

"winged" ? ;-)

I think that's somewhat covered in my paragraph:

It might be better for the above case, and possibly for performance too, if when tagging multiple files the UI presented the form the same way as it does when tagging a single file (perhaps with the addition of somewhere indicating all the files that are being processed) and then let the underlying engine deal with applying all the EAs to all the files when asked to commit the changes. This won't help situations where you'd like to use multiple tabs for the form, but it would help when dealing with multiple files using a single-page form (I think).This would allow the original tabbed-interface to show up as normal - it just wouldn't make cross-fields-on-different-tabs validation any easier.

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

gzevin

actually, the behaviour ov muti-file tagging interface could be what it used to be with that ugly gray interface - there was a bulk setting interface, and also file-per-file tagging capability, switchable by a single click. How does this sound?

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

Adam Stoller

possibly - it's been a while since I used that interface - and even longer since I used that interface for tagging multiple files at the same time (in either mode)

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