nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

different metadata for different templates in a same branch and different branches

SPG

Can we have different metadata for different templates in a same branch?
I think we can have by setting the metadata-rules.cfg file.

But at the same time I want to do metadata-deployment of it to database. Is it possible? And if yes how?

For metadata deployment we need mdc_dd.cfg and debschema.cfg files....? Can we changes these file? And what we need to change in this?

Find more posts tagged with

Comments

gzevin

Can we have different metadata for different templates in a same branch?
I think we can have by setting the metadata-rules.cfg file.

But at the same time I want to do metadata-deployment of it to database. Is it possible? And if yes how?

For metadata deployment we need mdc_dd.cfg and debschema.cfg files....? Can we changes these file? And what we need to change in this?

not sure that you clearly understand your own requirements - but will try to answer -

you *can* have different metadata rules for different file types/patterns (based on a regex that you specify).

Metadata deployment is separate from you setting the metadata, so your Data Deploy module should be configured appropriately, HOW - RTFM.

SPG

Yes I do understand my requirement Smiley Happy

Probably I am not able to explain it properly.

I want different metadata for different templates in the same branch.
Eg: A branch ABC have A, B and C DCTs.
I want the following:
metadata for DCT A say name, number
metadata for DCT B say num (not number)
metadata for DCT C say name, number, title

When we set above metadata , I also want that metadata deployment should be done to database through DAS...

Are these things possible ? Please let me know if it's not clear.

Jamik

Yes I do understand my requirement
Probably I am not able to explain it properly.

I want different metadata for different templates in the same branch.
Eg: A branch ABC have A, B and C DCTs.
I want the following:
metadata for DCT A say name, number
metadata for DCT B say num (not number)
metadata for DCT C say name, number, title

When we set above metadata , I also want that metadata deployment should be done to database through DAS...

Are these things possible ? Please let me know if it's not clear.

Yes, these things are possible and are a trivial matter. I suggest reading the manuals, getting some training, and/or hiring a consultant who knows what they're doing. Then if you have problems implementing your requirement come back with detail on the issue you're having.

gzevin

Yes I do understand my requirement
Probably I am not able to explain it properly.

I want different metadata for different templates in the same branch.
Eg: A branch ABC have A, B and C DCTs.
I want the following:
metadata for DCT A say name, number
metadata for DCT B say num (not number)
metadata for DCT C say name, number, title

When we set above metadata , I also want that metadata deployment should be done to database through DAS...

Are these things possible ? Please let me know if it's not clear.

while I confirm that this is trivial, I always am uneasy about attaching metadata to/in DCRs - UNLESS DCRs are the final content that you are producing.

vpatel

while I confirm that this is trivial, I always am uneasy about attaching metadata to/in DCRs - UNLESS DCRs are the final content that you are producing.

Agreed with the classic TS only implementations. However, it is not uncommon to tag DCRs that are consumed by SitePublisher / LiveSite pages.

gzevin

Agreed with the classic TS only implementations. However, it is not uncommon to tag DCRs that are consumed by SitePublisher / LiveSite pages.

this is exactly what I said - when DCRs are final content - which is (sometimes) the case for LiveSite

Adam Stoller

while I confirm that this is trivial, I always am uneasy about attaching metadata to/in DCRs - UNLESS DCRs are the final content that you are producing.

I've done a number of implementations where Metadata was tagged on the DCRs and the PTs took care of transferring the metadata to the generated pages. IMO this is reasonable as the DCRs are the source and the pages are generated output. The content contributors interact directly with the creation of the DCRs and thus both content and metadata is within their domain. The generated output is created programmatically and deployed and generally shouldn't be modified after-the-fact.

I'm not saying this is the "only" view - just a reasonably legitimate view (IMO) that would account for metadata being set on DCRs.

gzevin

I've done a number of implementations where Metadata was tagged on the DCRs and the PTs took care of transferring the metadata to the generated pages. IMO this is reasonable as the DCRs are the source and the pages are generated output. The content contributors interact directly with the creation of the DCRs and thus both content and metadata is within their domain. The generated output is created programmatically and deployed and generally shouldn't be modified after-the-fact.

I'm not saying this is the "only" view - just a reasonably legitimate view (IMO) that would account for metadata being set on DCRs.

yes, I remember that, and I quite strongly disagree. I have some issues with the whole idea, in many ways on the theoretical level, being a former computer scientist. Because this goes against the architecture of the system which has clearly defined metadata structure and capture mechanism, and also the fact that no matter what is the source of the data is, the ultimate end product, that should be tagged is the target document. You are likely not familiar with metadata librarians. They would easily point you out that there could be a manuscript or a text/word file. But it's not this file, but the end book that will recieve ISSN/ISBN number.

your mentioned the method of implementation that was in use by IWOV consultants for some time, while the MD capture form was crappy and unusable. So, yes, it is kind of legitimate. But I'd call it a 'legacy style' implementation Smiley Happy

Adam Stoller

... You are likely not familiar with metadata librarians. They would easily point you out that there could be a manuscript or a text/word file. But it's not this file, but the end book that will recieve ISSN/ISBN number.

I don't think books tend to get ISSN numbers - that's mostly for periodicals and journals and is intended to be a unique id; ISBN is for books and the numbers can be decoded into several different pieces with individual meaning.

However, I think there's a bit of difference between a physical object (book) resulting from a series of processional steps and an intangible object (web page) resulting from automated processing of another intangible object (DCR) especially if the content author doesn't interact directly with the processed output at the time of creation - however, while I understand your point, I consider both methods as valid depending on the metadata being collected.

If the metadata is output-format-generic (e.g.: date of content creation or modification, author, description) - there is nothing about the generated page that distinguishes itself from the source DCR to make tagging from either side better or worse (IMO) - but the fact that the content author starts from the DCR, has their "hands" on the DCR makes it more convenient to tag the DCR at content creation time rather than adding more steps later in the publishing process to access the generated output and tag it "after the fact".

If the metadata-is output-format-specific (e.g.: different output files from the same DCR, each requiring distinct metadata, or date of output generation, etc.) than clearly tagging the generated files would make much more sense. Or, in the case of the ISBN example (which is generally for books, and not electronic-[only]-media - where you might need to submit a physical object to the standardization organization in order to obtain a registered ISBN number - then yes, the number is directly associated with the "generated object" - but it doesn't mean that back-referencing it to the source manuscript (as an addendum) would be "wrong" (again, IMO)

your mentioned the method of implementation that was in use by IWOV consultants for some time, while the MD capture form was crappy and unusable. So, yes, it is kind of legitimate. But I'd call it a 'legacy style' implementation

Perhaps, but legacy is not always "bad".

Shall we just agree to disagree [somewhat] on this point?

gzevin

Shall we just agree to disagree [somewhat] on this point?

Sure

I just want to add that it still seems to me that you are in hands (still) of the legacy implementations Smiley Happy

Which is not always bad Smiley Happy

Because post-6.0 workflows and especially the wizards of CC STD, and, even more especially, new formAPI in the MD capture make the process so seamless, the user sometimes is not even aware that they are tagging metadata, thinking it's simply a new page for data capture Smiley Happy

SPG

Guys ...can I reapeat my question.....and all can you please answer it... Smiley Happy

My question is can I have different metadata for different branches (in my original question I asked for same branch). I don't want to assign metadata to DCRs but to the pdf files......
Once we assign the metadata to pdf or video or any other files other than DCRs then if we applied DAS , using it, it should enter those rows to the DIFFERENT tables.

eg: In datacapture.cfg of teamsite local/config is mentioned below

Metadata for branch A is p, q and r
Metadata for branch B is x , y
Metadata for branch C is g , y

So in database table it should create the tables as following:
table Abranch having columns say Path, State, p, q and r only
table Bbranch having columns say Path, State, x, y only
table Cbranch having columns say Path, State, g and y only

Right now it's creating Path, State, p, q, r ,x, y,g

Is it possible. Already I have read the manuals...So please don't reply with that again Smiley Happy

Currently we are having one

CRB

yes it is possible.

gzevin

Is it possible. Already I have read the manuals...So please don't reply with that again

Yes. It is possible. If you have read the manuals, have you come across a custom database schema?

SPG

yes....but all these we can do it for different DCRs....my problem is related to metadata which is shared globally across one teamsite.
For metadata we are sharing one dbschema.cfg and one mdc_dd.cfg file. How should we design these files so that we are able to create different tables for different branches for pdf files (not for DCRs).

Please let me know in which manual it is mentioned....can you give any reference ?

vpatel

*****ASSUMPTION: you are using OD/DD to deploy your metadata into a DB.

What you are asking for is a custom solution. I do not believe that any of the OOTB guides have a solution cut out for your exact need. However, if you get the general understanding of the products (assuming TS and OD/DD) through various guides, you'll be able to piece a solution together.

With that said:
1. Are you using DD to deploy the MD into DB? I am assuming so.
2. Where are your dbschema.cfg and mdc_dd.cfg files located? Under od-home? Within your branch? Somewhere else?
3. What triggers the deployment to the DB? Are you using DAS?

Since you are getting a single table (i.e. Path, State, p, q, r ,x, y,g) it seems like that you probably have a single deployment definition. You probably need either one configuration file per branch or a single configuration file with multiple deployment definitions + filters (filter out branch specific items). I am sure there are other ways to do this as well. You can find more info on DD filters and deployment configurations in the DD Admin guide.

HTH!

SuppressDuplicatesMethods.pdf

SPG

Thanks for the reply.....

Here are the answers to your questions :
1. Are you using DD to deploy the MD into DB? I am assuming so.
Ans:I am using DAS and not the standalone deployment

2. Where are your dbschema.cfg and mdc_dd.cfg files located? Under od-home? Within your branch? Somewhere else?
Ans: These 2 files are in TSHome\local\config and shared by all the branches since global.

3. What triggers the deployment to the DB? Are you using DAS?
Ans: submit action triggers the deployment to DB using DAS. Even when there is a submit task in workflow , this will trigger the deployment using DAS.

Can we have different mdc_dd.cfg files per branch ? If what is the path for that ? In that case do we need to mention somewhere to pick the file of branch and not the global file? Do we need to delete mdc_dd.cfg and dbschema.cfg files from TShome/local/config folder?

Thanks in advance....

vpatel

My personal preference is to stay away from DAS and work with the stand alone deployment as it normally provides you with full flexbility and control. Post your mdc_dd.cfg file.

SPG

Please find the attached mdc_dd.cfg file.
Please let me know what we can do to resolve my issue.

As you said is correct that we should not use DAS.
But if the existing architecture is based on DAS, we should use the same.
But then it seems this is a bug with teamsite. Teamsite should create different tables by looking at metadata-rule.cfg file for different branches or may be different DCRs in same branch. It should not create one big table.

Capture.PNG

gzevin

Please find the attached mdc_dd.cfg file.
Please let me know what we can do to resolve my issue.

As you said is correct that we should use DAS.
But if the existing architecture is based on DAS, we should use the same.
But then it seems this is a bug with teamsite. Teamsite should create different tables by looking at metadata-rule.cfg file for different branches or may be different DCRs in same branch. It should not create one big table.

your DAS produces what you have configured. Don't blame any 'bugs' when it's your own making.

SPG

gzevin,
mdc_dd.cfg file can be generated with iwsyncdb command....this file can be generated either based on dbschema.cfg file which we can generate with the iwsyncdb command or we can create it manually.
I tried to add different tables in dbschema.cfg but there is one restriction that out of all groups only one can be the root group. So if I create only one group as master and others as non-root then when I try to add a row to one table it will add the records to all the tables and then it fails because other tables might have different metadata fields which can be null. And if the primary key is null then there will be the SQL exception for this.....
If you have solution for this let me know....

vpatel

Teamsite should create different tables by looking at metadata-rule.cfg file for different branches or may be different DCRs in same branch. It should not create one big table.

??? Just because you expect certains things doesn't mean that the product will work in that fashion. Product is engineered in a certain way and you should understand how it works first.

vpatel

gzevin,
mdc_dd.cfg file can be generated with iwsyncdb command....this file can be generated either based on dbschema.cfg file which we can generate with the iwsyncdb command or we can create it manually.
I tried to add different tables in dbschema.cfg but there is one restriction that out of all groups only one can be the root group. So if I create only one group as master and others as non-root then when I try to add a row to one table it will add the records to all the tables and then it fails because other tables might have different metadata fields which can be null. And if the primary key is null then there will be the SQL exception for this.....
If you have solution for this let me know....

Sounds like lack of some OD/DD understanding and a need to design a solution based on that understanding.

SPG

I am not expecting as I have a need.

This should be expected generally. If they are not creating different tables for different metadata values in datacapture.cfg file then this is a bug.
Based on this datacapture.cfg, it generates one big tables with the column names prefixed with rule_name. So if I have 10 branches using diffent set of metadata and each having 5 metadata fields . Then it will create 10*5 =50 column table. This is ridiculous.

This is the general expectation that it should create different tables (for DAS) based on datacapture.cfg file. But it is not, so it is a bug.

We are sharing same mdc_dd.cfg file for the whole teamsite (tell me if we can create different mdc_dd.cfg files per branch/per DCR or like that), and then if we decide that I want to generate the this mdc_dd.cfg file based on manual created dbschema.cfg file.
But how we can design dbschema.cfg file for different branches? As it allows only one root group. That means if it tries to add a record to one tables out of the 11 tables (one will be with the root-group="yes" : this is common fields for all the other tables (eg: Path, branch, workarea and path as combination of these 3 as primary key ) then it will try to add the record to all the tables. Here we will get the SQL exception.....

Please suggest.

vpatel

I am not expecting as I have a need.

This should be expected generally. If they are not creating different tables for different metadata values in datacapture.cfg file then this is a bug.
Based on this datacapture.cfg, it generates one big tables with the column names prefixed with rule_name. So if I have 10 branches using diffent set of metadata and each having 5 metadata fields . Then it will create 10*5 =50 column table. This is ridiculous.

This is the general expectation that it should create different tables (for DAS) based on datacapture.cfg file. But it is not, so it is a bug.

We are sharing same mdc_dd.cfg file for the whole teamsite (tell me if we can create different mdc_dd.cfg files per branch/per DCR or like that), and then if we decide that I want to generate the this mdc_dd.cfg file based on manual created dbschema.cfg file.
But how we can design dbschema.cfg file for different branches? As it allows only one root group. That means if it tries to add a record to one tables out of the 11 tables (one will be with the root-group="yes" : this is common fields for all the other tables (eg: Path, branch, workarea and path as combination of these 3 as primary key ) then it will try to add the record to all the tables. Here we will get the SQL exception.....

Please suggest.

Again, this is not a bug -- you can definitely get a normalized DB schema (not a flat DB table with 50 columns). You'll have to configure / program it that way. As I have stated earlier, if I were to do this myself I would get away from DAS and create various deployments (one per unique content data type) and then probably create a single Perl script / Java class to execute necessary deployment based on branch + content type. You may be able to do this with DAS but other alternative will give you much much much more flexilibility.

If you do not know how to achieve that then I would recommend getting some external help to do this.