Make an Annotation with Links, Notes, Tags v2

[Greg_Jones]

i’ve come to agree with this. but here’s the thing… i’m writing a book, and so each of these databases would interface; the databases would essentially be chapters in a book. to that end, i need to replicate certain files and notes between databases, but it seems that i’m unable to do that. can anyone recommend a solution to this situation? a colleague suggested considering indexing files, but i don’t think that would work for my configuration. still, i’m happy to entertain other ideas. thanks.

As you have discovered, you are not going to be able to replicate documents across databases. Your colleague is correct that you could index the documents into multiple databases, but that would have to be done manually. Another option is that you could dump all the common documents into one folder in the Finder, then index that folder into multiple databases.

Are the chapters in the book really that unrelated that one database does not work best, e.g a collection of short stories, etc.?

[NZT-48]

@korm

You shouldn’t need to repeatedly “reinstall” scripts – though I’m not sure what specifically “reinstall” means on your kit. If the problem persists, it’s a good candidate for opening a ticket with Support.

got it. thx.

@korm

It’s not possible to replicate a file between databases. If it is essential to have access to the same file in more than one database, then index it in each database. The indexed instance is exactly the same file in each database, so this approach amounts to the same result as you would have if multiple-database replication were possible.

right. but a colleague who has used DTP for quite some time argued that i shouldn’t index my databases. he said that if a database is always changing, through adding new documents, as well as adding annotations and links to them, it would create a mess to index them. he also said that it creating and maintaining replicants w/in an indexed databases would be a recipe for disaster. do you agree? is there any other suggested approach that would enable me to not index and somehow still replicate between databases? thx.

[NZT-48]

@Greg_Jones

i’ve come to agree with this. but here’s the thing… i’m writing a book, and so each of these databases would interface; the databases would essentially be chapters in a book. to that end, i need to replicate certain files and notes between databases, but it seems that i’m unable to do that. can anyone recommend a solution to this situation? a colleague suggested considering indexing files, but i don’t think that would work for my configuration. still, i’m happy to entertain other ideas. thanks.

As you have discovered, you are not going to be able to replicate documents across databases. Your colleague is correct that you could index the documents into multiple databases, but that would have to be done manually. Another option is that you could dump all the common documents into one folder in the Finder, then index that folder into multiple databases.

Are the chapters in the book really that unrelated that one database does not work best, e.g a collection of short stories, etc.?

i might not explained myself properly. to clarify, the chapters in the book really are related, and that’s why i’d like to link material between databases via replication or some other similar method. the only reason that that one database does not work best is because i’ve found that in order to optimize this wonderful “Make an Annotation with Links, Notes, Tags v2” script, it seems to me (based on my experience) that one ought to use one database per topic - otherwise there are just too many tags to confine to one topic. but then it seems to create a catch-22 of not being about to also link material between databases via replication. that’s my dilemma. i welcome any other suggested solutions. thanks.

[Greg_Jones]

I don’t know what else to suggest, as you may need to decide if the script is more important to you than having all your data available, and contained (imported) into a single database. In any event, replicating imported documents across databases just isn’t going to be possible as the document can only be contained in one database.

I’m not trying to convince you to index your documents, but indexing is the only way I am aware of to get the same document to appear in multiple databases. Index the documents into one database, duplicate them to locations in additional databases, and the documents in the database will all point to the same document in the filesystem (Finder). Used this way with indexed documents across databases, the duplicate command acts as a replicate command.

Even though they will function as replicants, the documents will not have any visual/color clue to indicate that they also occur in another database the way replicated documents appear. That limitation may present a problem for you also, if you want a visual cue that a document is indexed in multiple places.

[korm]

Removed comment; pointless

[amcawood]

Meanwhile, can I just reiterate an earlier suggestion that this sort of annotation capability be baked into Devonthink?

I can’t get either of Korm’s template scripts (_Annotation MD___Cmd-Shift-Alt-M and the RTF version) to work. I get a new doc with the header info, but after “Type your note here”, nothing.

Troubleshooting this issue involves trawling through thousands of words across several long threads on this forum, and when that fails, bugging the Korm or Frederiko for support that they provide out of generosity.

Rather than do that, I’m giving up and going back to Highlights. But given the sustained interest in this functionality, and that it sits squarely within Devonthink’s design intention, I’d like to see Devontech build it into the software. Looking forward to DTPO 3.0 + DTTG 2.0 …

[NZT-48]

@Greg_Jones

I don’t know what else to suggest, as you may need to decide if the script is more important to you than having all your data available, and contained (imported) into a single database. In any event, replicating imported documents across databases just isn’t going to be possible as the document can only be contained in one database.

I’m not trying to convince you to index your documents, but indexing is the only way I am aware of to get the same document to appear in multiple databases. Index the documents into one database, duplicate them to locations in additional databases, and the documents in the database will all point to the same document in the filesystem (Finder). Used this way with indexed documents across databases, the duplicate command acts as a replicate command.

i hear you an appreciate everything you’ve said. my main concern with using indexing is that it’s unkind to emergent databases - that is when one adds to or moves files around in databases. i’ve noticed that i do so, and i fear that might wreak havoc with indexed databases. understand what i mean.

but i get your central point about which is more important: replication or the annotation w/ links + tags script. a pity there’s not a way to accommodate both.

i suppose i’ve been searching for a solution that’s related to TagNotate app - or what it tries to do - i.e., annotate PDFs (with highlights, underlines, and notes - though adding notes doesn’t yet seem to to be fully formed in TagNotate), assign tags to the annotations (that’s basically what this script does in DTP), and then select a tag (or tags) to cull annotations containing the same (one or more) tags across single or multiple documents. that culling tags / annotations feature seems to be TagNotate’s strongest attribute.

unfortunately, i don’t use TagNotate because it imports - instead of syncing - documents from dropbox (making it repository for annotated documents, as well as the tags that are created for them), the ability to make annotated notes seems to be limited (at least it’s non-existent in the ipad version), and the annotation interface is generally a bit clunky.

anyway, this annotation w/ links + tags script accomplishes almost all that i’m seeking to do. yes, it would be great it if it also had the culling tags / annotations feature, but the script writers already produced amazing features and i’m not complaining. they’ve helped us out a great deal.

for me, i need to keep my tags manageable for each project, and that means: one projects = one database, to keep a tightly focused set of tags. but some of my core annotations / tags do overlap with what i’ve got in other databases. that’s why the inability to replicate in this instance is frustrating.

having said all of this, i’m happy to consider a completely different approach. please feel free to make suggestions. thx.

@Greg_Jones

Even though they will function as replicants, the documents will not have any visual/color clue to indicate that they also occur in another database the way replicated documents appear. That limitation may present a problem for you also, if you want a visual cue that a document is indexed in multiple places.

i see. so, even if i went the index - replication approach, there wouldn’t be any way to indicate if a document was a replicant, correct?

[NZT-48]

@korm

@NZT-48

the only reason that that one database does not work best is because i’ve found that in order to optimize this wonderful “Make an Annotation with Links, Notes, Tags v2” script, it seems to me (based on my experience) that one ought to use one database per topic - otherwise there are just too many tags to confine to one topic. but then it seems to create a catch-22 of not being about to also link material between databases via replication. that’s my dilemma. i welcome any other suggested solutions. thanks.

Putting indexing aside – let’s try to see why the script (any of the versions in this thread) would cause one to have multiple databases – especially to the extent of having “one database per topic” – and why the quantity of tags is the driver for this. Is there something in your process that requires so many tags that managing them is unwieldy?

perfectly reasonable question. i’d love to have everything in one database, and to use a uniform tag system. but some of my projects have very specific research needs that require their own set of tags (e.g., pertaining to names or groups/issues).

when i first stated using this script, i noticed that the tags quickly grew, accordingly, and it became unmanageable to sift through the drop down menu in the script to locate appropriate tags. (again, not a criticism about the script - though maybe there’s a way to tweak the existing interface so it’s easier to locate tags and/or have the ability to create subfolders for tags for better organizational management.)

it therefore seemed best to create a tag system for each project. making one tag system per project meant making a separate database per projects. maybe there’s a way to create separate tag systems per project, within groups, inside a single database (i.e., database->project assigned to group->tag systems for project). but the problem with this, as far as i can see, is that the script will keep reverting to all the tags in a database, and won’t apply the tags system for the project that one is working in. correct? if that’s the case, then this probably isn’t a solution.

as i said in an earlier post, some of my core annotations / tags do overlap with what i’ve got in other databases. that’s why i’m seeking a solution to replicate files between projects.

i’m totally happy to consider a completely different approach. please feel free to make any suggestions. thx.

[NZT-48]

@amcawood

Meanwhile, can I just reiterate an earlier suggestion that this sort of annotation capability be baked into Devonthink?
…
Troubleshooting this issue involves trawling through thousands of words across several long threads on this forum, and when that fails, bugging the Korm or Frederiko for support that they provide out of generosity.

Rather than do that, I’m giving up and going back to Highlights. But given the sustained interest in this functionality, and that it sits squarely within Devonthink’s design intention, I’d like to see Devontech build it into the software. Looking forward to DTPO 3.0 + DTTG 2.0 …

ditto that sentiment!

esp. the part about having “this sort of annotation capability…baked into Devonthink”! i’d second that, and respectfully ask that the DTP developers consider some of my earlier suggestions about appropriating the TagNotate app features (i.e., being able to sort and search for files with one or more tags), as well as adding onto to this terrific script. seems plenty of users would love these features. thanks for considering our requests.

[jprint714]

I totally agree with the last sentiment. It might be a bit outside of Devonthink’s main scope, but it sure would be great to have these annotations be a part of future software updates.

Thanks very much!

[Nhaps]

@Frederiko, thanks for the great script. For me I get the error displayed below. Tried leaving date blank, but default being input automatic is 2009… don’t know why.

[korm]

Removed comment; pointless

[Nhaps]

removed response as well, not a problem

[korm]

Removed comment; pointless

[Nhaps]

No, the only difficulty is that the script is broken on my end, not for any other reason.

[NZT-48]

@korm

I assume you are using Frederiko’s version, then – the one with the window that prompts for tags.

correct. i actually assumed this with the prevailing version. forgive me: it’s a very long thread, and so reading through i assumed Frederiko built upon your script, changing the interface. is that right? anyway, yes, i’m using his script.

@korm

Does your project-oriented system of tags get defined on the fly, or do you design it at the onset of a project and maybe only tweak it later? The reason I ask is that there is a way to modify Frederiko’s script with a call to a function that points to a specific tag set – or perhaps a tag group whose sub-tags were for a given project – or a filter to choose a subset on the fly. Hard to tell without seeing your taxonomy and tag structure if that would actually help your situation.

both. Frederiko’s script has three basic tag parent folders: “Annotation tags” (e.g., follow up research); “People”; “Issues.” i use each of these tag parent folders to create a tag taxonomy based on the project i’m working on. sometimes the tags overlap w/ tags from other projects (esp. certain global issues); mostly, however, the tags i create for a particular project are tailored to the people and issues pertaining to the particular project (esp. people).

have i answered your question? happy to further clarify if that’s helpful. thx.

[Nhaps]

Let me know if you all can respond to my problem which is illustrated with an image above. Fred’s script is broken with that message.

[NZT-48]

preamble: i’m relatively new to devonthink, and have never done any scripting before. so, forgive this question.

here it is: there a way to tweak the script so that it can to create separate tag layout per project, within groups (i.e., database->project assigned to group->tag layout for project)?

again, i ask as a novice, but if it’s possible it could be a solution. always happy to consider a completely different approach as well. thx.

[Frederiko]

when i first stated using this script, i noticed that the tags quickly grew, accordingly, and it became unmanageable to sift through the drop down menu in the script to locate appropriate tags. (again, not a criticism about the script - though maybe there’s a way to tweak the existing interface so it’s easier to locate tags and/or have the ability to create subfolders for tags for better organizational management.)

The tags autocomplete so you shouldn’t have to search through them. I have found that any system of tagging requires regular culling to avoid getting out of hand and to keep relevance. If you don’t remember what tags you are using, tags don’t work. You have to be very disciplined about them. If you need a more complex system of tagging you might try using prefixed for addition categories say “R-”, “A-” etc

Also remember you can always go through the tags afterwards in the tags folder and rearrange into more detailed categories.

The script will not work across multiple databases with indexed documents for a very simple technical reason I have been unable to find a work around for. The underlying tag groups use the annotated documents uuid as the tag group name. Documents in different databases have different uuids, so the tagging links break down.

Frederiko

[Mio]

I was able to successfully start the script after I highlighted a text within either a PDF or RTF file. However, once I tried to save it nothing happened. In another words, I only see “annotation” folder within the inbox folder without any file stored there…
Any idea?