Metadata of Replicants and Duplicates

Hi there,

after stwo years with DT I discovered something basic :blush: :

Metadata of a replicant – including document title – will be changed in any instance if I change them in one.

I got used to another concept from duplicates, that one could change Metadata for each instance, while the content is still the same. In the beginning I did not like it, but it has its merits. So I expected the same for replicants. But – no.

Why is it important? I came across the problem when I sorted documents for a course that I do a second time this year and possibly several more times. So I have my basic information for all lessons in this year and the following (to be updated of course) and pick up the necessary documents for each lesson and create a group for each lesson with these basic documents in order to present pictures, data etc.

Now, documents in the basic information group have a basic name like “Authour, short title, page, content”. In my lessons group, they should get a number and a title that is necessary in this particular lesson. I could work with duplicates, but that is not elegant and increases the database.

As Christian said earlier, duplicates should not exist for long in a database, I agree. They are created in order to be changed step by step, then they turn into originals. Replicants are incarnations of identical content, but according to the context in a group they need different meta data.

At least the title should be independent.

How do you think?


Hi, Maria:

Yes, if you change the title of a replicant, that will change the title of all it’s associates, or clones, or whatever you wish to call the other instances.

I’ve run into a similar problem with some projects and have resolved it to my satisfaction by developing the project with duplicates and replicants, then spinning off the project as a separate database and deleting it from my main database.

For example, I’ve often done editing work on the Tutorial database by merging it into my main database, then exporting it for import into a new database. There are advantages to that, as I can instantly shift back and forth between working on that project and other projects in my database. But it also results in duplicates or replicants in the main database if I reuse some material in the Tutorial project.

And I’ve done a syllabus for a graduate course on hazardous waste site investigations in precisely the same way.

Think of “publishing” your course material as a separate database.

If it needs to be updated next year with new material that has been added to your main database, merge it into your main database (whereupon lots of duplicates will probably show up, including items that had been replicants prior to the export to a new database). Make your changes. Then export it out again as a separate standalone database for your course. And delete the copy remaining in your main database so that duplicates and some replants revert to ‘normal’ black text names. Or make your changes once you’ve exported and created the new database, so that you don’t need to worry about altering replicants in your main database.

And wouldn’t your students love to get their hands on that course database? Think of all the copies of DT Pro we could sell them! :slight_smile:

Or (gee, DEVONtech loses out this way but its cheaper for your students) you do a bit of hyperlinking in your course database (like the Tutorial) and publish it as a Web site available to your students. A course syllabus with lecture topics linked to recommended readings.

If, later on, you come across some reference material in your main database that you would like to include in your course database, just do an export/import and organize the new material into your course database.

Hi Bill,

thanks for the good ideas. As always in difficult cases, you offer a great workaround.

Still, it is a workaround, and I think, content and metadata are something different. Metadata may change according to context. This should be reflected in the power of DTPro handling replicants.

And – I will consider your ideas about the web site :wink:


Hi, again, Maria:

Long ago I was having fun doing some bleeding edge research when molecular biology was new. One had to invent techniques and often build lab equipment with stuff available at the local electronics shop, hardware store and grocery store.

Example: From those sources and for just a few bucks I put together an electrophoresis apparatus that did a very good job of separating enzymes of interest. And even cheaper, some gadgets that did a good job of separating and quantitatively comparing the characteristic building blocks of DNA from closely related strains of bacteriophage. And using an Abbe refractometer (used in the sugar industry) to help separate slightly different strains of phage in a cesium chloride substrate after an ultracentrifuge run, and calculate their relative densities.

A workaround (or kludge) is simply figuring out how to do what you want to do, with what’s available. Fortunately, DT Pro seems almost infinitely adaptable. :slight_smile:

Hi Bill,

it seems to be a private conversation between the two of us… :slight_smile:

You are right, and I am already working around. The reason I put this suggestion into the forum for requests and suggestions is that I wish for improvementt. If people had none of these requests and suggestions, they would still write on a typewriter – or carve into stone?


No, we are listening :blush:

Even if i understand your problem i think the replicants concept makes much more sense in the way it is now. Having different metadata for each replicant would unneccessarily complicate this feature and make it logical inconsistent.
And now i’ll go back to my chisel and carve some stone 8)


If I understand you correctly, this process wouldn’t work that well for me. Whether it’s a course or a writing project, I would need to remain within the context of my main db, since I’m am constantly needing to research or link to information stored in it. I normally open separate windows for projects rather than create separate dbs, since I can’t have more than one db open at the same time. It’s a huge pain to have to switch/close out of one to get into another db. Perhaps with the new DT this won’t be an issue, when we can have multiple dbs open at the same time.

Do you have this issue, where you need full access to your main db while in your separate, project db and if so, how do you handle it? If I had to wait for DT to switch back and forth between dbs, I’d lose my train of thought. I’m often in the middle of something pressing when I need to do a search or access something in another part of the db. Or as often happens, I need to link to something in another part of the db. It wouldn’t work if it were in a different db altogether.

So when I have the situation Maria described, I have to create duplicates. Why is it bad to have duplicates in your db for long (Maria mentioned this)?

Thanks to you both for discussiong this. As always, I learn from the great kahunas (the true ‘Gods’) of DT Pro!!! :laughing:


Alexandria, sometimes I do bad things, and can only hope for absolution by whatever God may be relevant.

Having duplicates is bad to the extent that they increase the size and memory requirements of your database, especially by comparison with the minimal overhead of replicants.

But if you are willing to accept that kind of “badness,” and your objectives are better accomplished, go right ahead. I absolve you. :slight_smile:

The advantage of duplicating a file is that you can make the kinds of editing and metadata changes that Maria wants to do. Of course, if there are enough edit changes, at some point that duplicate file will no longer be considered a duplicate by DT Pro, and its name will become black rather than blue.

A “good” example of using duplicates is to create a document that you wish to use as a template. Use Data > Duplicate on that document and you have created a a duplicate. “Fill in” the template and it will no longer be a duplicate, as it has been substantially modified.

If you have a fast Mac with lots of RAM, switching databases is very fast, by the way. And although the memory footprint of databases will be smaller in DT Pro version 2.0, when concurrent databases arrive that old saying, “RAM is good; more RAM is better” will remain true.


I don’t believe you ever do anything bad! :laughing:

Thanks once again for all the good info. I must have a slow Mac. It takes quite a while to open different dbs. Way too long to make it practical. I have my RAM maxed out for this computer, so can’t do much there. And I can’t afford an Intel machine until the dissertation is complete (then lookout, 'cause I’m getting a souped-up, maxed out MacBook, plus a 60 GB iPod! Now if THAT isn’t motivation…!).

This issue doesn’t come up for me all that much, and of course it is true that after a certain amount of fiddling a duplicate is not a duplicate any longer. But it’s good to know that I’m safe if I do need to create a duplicate. Don’t want to anger those DT gods!!! :slight_smile:

Thanks again!


Hi Louise, thanks for listening!

I can see your point about logical inconsistency of different metadata for replicants. I felt similarly about metadata for duplicates in the beginning. Now I prefer this concept, and I think it would be more consistent to implement this feature with both duplicates and replicants. Still – I do not think that those who are against this idea carve into stones :wink: .

Here are some thoughts:

(1) Metadata that may logically change according to context:

Title, label, IPTC data (if these will be implemented)

(2) Metadata which would not change:

URL, path, date of modification (of content) and date of creation, number of replicants, location of replicants (if this will be implemented sometime), EXIF data (if these will be implemented)

(3) I suppose that it is difficult to implement the feature of different metadata for individual replicants because this affects the basics of the database architecture. So it may be useless to ask for even more like “separate metadata which can be changed individually from those which cannot” or "provide a button like ‘change for all replicants’ ". But – I do :blush: , I would particularly like the button ‘change for all replicants / duplicates’.


What a generous and kind conversation :wink: And Alex, I envy you, when I finished my dissertation I fell into a deep black hole (no money left, no power, what to do next?), I wish you better!

This is actually my workaround: Creating duplicates – file garbage – and use their feature of providing individual metadata. It works, works very well and blue looks less frightning than red :slight_smile: Fortunately, computers have great power nowadays, still, I don’t like the idea of collecting redundant information on my machine…