Templating vs. MetaTagger

In order to allow FormAPI code in the form used to gather metadata from the user, to provide the user with a consistent user interface, and to give the user one place to enter all content and metadata, we would like to store metadata in the DCR rather than having a separate window for MetaTagger.

I understand that one of the limitations of this approach is that it could be harder to configure who sets metadata and who enters content, but in this environment they are always the same person anyway. I also see that some FormAPI and server side code would be required to populate fields in the DCT with data generated by MetaTagger.

I am wondering if there are any other limitations of this approach.

The client has already purchased MetaTagger but is now thinking that it may be too complex for them to implement and doesn't like the extra steps. I don't like the inconsistent UIs and the fact that I can't use FormAPI in the MT DCT.

Find more posts tagged with

Comments

smigster

I've always preferred to have discretely entered metadata fields in the DCR to save the hassle of an extra metadata entry step. FormAPI makes it pretty easy to control who enters what so I wouldn't be too concerned about forgoing a separate metadata entry requirement.

It'a also possible to bypass an interactive MetaTagger interface by using MT CLTs (like iwgenmetadata and iwmtbatch) for fields that MT fills in (like keywords and summary). These can be invoked during a tt_data or New Job workflow.

Migrateduser

Keep in mind that by bypassing MT, you are essentially removing the ability to "intelligently" tag content. The value is incredible, and once users move into areas like categorization of content, synonym mapping, etc., they will find greater value than in a DCT based approach to capturing metadata.

Has the client seen MT 3.1 or 3.5?

Other limitations to capturing metadata in the xml:
- you now require parsers to extract those values
- search engines which leverage the TS backing store must now rely on the metadata from the XML (unless you introduce the extra steps of extracting the metadata from the xml and setting the values a EA's)
- again, unable to leverage the intelligent tagging capabilities of MT
- unable to leverage vocabularies or taxonomies
- must introduce "allowed" and "disallowed" fields on the DCTs for users who have metadata responsibilities

These are just a few.

Rgds,

jc_iwov

Migrateduser

I'm curious how things have turned out. We are having the same debate. There is concern over lack of FormAPI, and the templates seem to integrate a little better with workflows (after finishing with the MetaTagger GUI a person has to go to their ToDo list to resume with the workflow. Not a big step, but an inconvenience).

The big hassle would be that we would have to programmatically generate new templates each time our vocablulary changes, or else write some sort of cgi-callout.

Adam Stoller

I haven't tried this lately (don't have a setup to try it right now) - but I believe if your cgitask that is running mtmetaproxy.cgi has only one transition, that when you 'Finish' tagging the asset it should automatically transition to the next step in the workflow.

Are you sure this isn't the case?

The 'extra step' that is often involved is if the person tagging the asset did not 'own' the preceding task, and therefore would have to go to the To Do List to *start* the metatagging process - but that's consistant with any cgitask that does not follow a preceding usertask owned by the same user.

--fish
(Interwoven Senior Technical Consultant)

input.txt

Migrateduser

I think it is working out really well. The hard part now is determining what is content vs. metadata (things like page title) vs. control data (since we store things like publish date in the template). I also feel that the configuration was a lot easier than metatagger, but then we don't have things like autotagging (though I'm sure it could be done with standard templates instead of a new UI). At first I was extracting fields from the DCRs and assigning them as extended attributes on the output files but now I realize there is little reason for or value in this, I can always just parse the DCR. There is a lot of functionality and reusability in this system (since most of the components of the templates are built with inlines that are shared to all templates). I also don't know how it would work with DataDeploy. We collect metadata on templated and non-templated content and even directories.

We already have user acceptance issues, and because of bugs and performance issues we never want the user to go to the todo list to find a task. So adding an email to them to get them to set metadata might not be acceptable. I think there is a way you can have the DCT go straight to the metadata form when the workflow starts, but I don't know how this would work for non-templated content (our metadata capture form for non-templated content includes functionality to let them download and upload the file). But there may also be value in some environments in having a different person assign metadata than the person entering the content.

Migrateduser

Do you have the end-user name the DCR and browse the proper directory to save it in?

Migrateduser

For templated content, yes they have explicitly choose a directory and name the file. We capture things like business unit, then regex the DCR when they try to save it to ensure they are in the right directory top-level directory. But there is no way to force the directory in formapi without also forcing the file name, and we can't always force the file name. Plus I don't want to add a directory picker to the templates.

For non-templated content (word documents, etc.) there is a custom menu item that creates a DCR that corresonds to that file path (if such a DCR does not exist), then edits that DCR.