Hello,
I apologize if this has been answered somewhere else, I couldn’t find an update since 2018.
Is it possible to create links or relations between items? I’m trying to use Tropy for provenance research, so I’d like to be able to link an object to catalogues or exhibitions that it appears in for example. Ideally the relationships would show up in the metadata.
At the moment the best way I’ve found to achieve this is with tags but that might get unwieldy quickly.
Hi,
currently you may use the Copy Item Link feature as described here: How to use the link button.
Hello,
Please let me know if this needs to be a separate post; I found this while looking for an answer to an issue I am having and it seems like it may be a bug?
In the linked post, @inukshuk indicated that you can right-click on an item and select “Copy item link” to get a tropy URL that can be included in other places to be able to link back to that item. However, I’m not able to make that work correctly.
I have multiple projects, and I’ve found that when I copy the link to an item, it looks like this: tropy://project/current/items/55/56 There’s no reference to the actual project or the items therein, and if I click the link (from Obsidian/Zotero, if that’s helpful), it just opens a random item in whatever the most recent project is, rather than the one I have actually copied the link to. For projects where there isn’t an item number, Tropy will open, but won’t open an item.
Am I doing something wrong here? How do I get the actual link to the item, in the project it’s actually in?
You’re doing everything right, this is a limitation that we have not addressed yet. At the moment, the URLs only work for a single project. We’ve had two solutions in mind for this but haven’t really made a decision either way: the main problem is that you can move project files around freely, so there is really no easy way for Tropy to locate a project if, for example, we used the project id in the URL. One way around this would be to use the full path to the project file; the downside to this is that URLs will be relatively long and that they will break if you move the project file.
The other approach we considered was to introduce short names / ids mapped to project files: you would establish such a mapping explicitly in the project settings. This would give you shorter URLs but requires an extra configuration step (as before, URLs would break if you move the project file, but every time you open the project in Tropy the mapping could be checked, so basically ensuring that the URLs work as long as you’ve opened the project once after moving it).
Would you have a preference between these two approaches? Or another idea altogether?
Given that file link maintenance will always be a problem no matter what you do, I’d probably lean towards having an ID that you can map to and a URL that is less unwieldy. I tend to name files and organize them before viewing them in any sort of CMS/database (whether that’s tropy or some other program like iTunes), and I think most people are probably either in the camp of giving specific names to files so they can easily find them, or not caring about file names and using Tropy to manage and find things.
However, I think whatever system is developed should take into account that things will always need to be moved at some point - hard drives fail, after all - and make it easy for the user to map their existing files into a new place if needed. It would be ideal if the system were set up in such a way that if I need to change the file path (but not necessarily any of the file names) that I could do so and not need to somehow relink everything by say, opening up every item once or something. I’ve had to do that with other systems and it’s such a pain, esp when you are dealing with large collections.
Good points, thanks! I agree that URL stability is probably the thing we should optimize. My favored approach is to allow to define a name in the project (it could default to an URL friendly version of the regular project name). This way the URLs would be stable as long you don’t change the name. In order to resolve the project (after moving or renaming the project file) you’d have to open the project at least once but all the URLs would remain the same.
Hi there,
I write here although the conversation has took a different turn.
Links are useful, especially on other software (e.g. to refer to specific items in general notes any some kind of writing software).
However, it would be great to have a way to link multiple items which is embedded in Tropy, something quite similar to Zotero items linking.
Tropy Notes should be used to comment, transcribe and translate documents, while item linking is a metadata-kind of information. I often work with documents recorded in multiple versions, translations and other instances where 1-to-1 link would be extremely useful (not enough for tagging or categorization). Currently, to go back and forward each time in search of related documents is truly a pain.
Thanks!
I’ll open a ticket to track this on GitHub.
Considering the windows environment, can’t Tropy manage the paths to different projects in c:\users\username\appdata\local\tropy ?
Then, it should be easy to keep all links working after moving a project to a new path, provided that this operation is done ‘inside’ Tropy, and not with File Explorer. (I’m not a dev though, so I might be very wrong)
Regarding another comment in this thread, I agree that links from an entity to another entity is more of a metadata – but depending on the user workflow, it could be more useful in the notes. In my particular workflow, I would prefer it as metadata, like in Zotero. A “preview on hover” would be the cherry on the cake.
Yes, you’re right, Tropy stores some data in %APPDATA on Windows. That’s actually where Tropy stores the list of most recently used projects and other settings. We’ll add a name for each project to the URL and the URLs will work on a device if Tropy has opened the project with that name at least once before. If you move the project, you’ll have to open it again once for Tropy to know its new location.