I thought that DT writes tags out as open meta tags on export. When I …
-create a new RTF in DT
-tag it with something (“test”)
-export it by dragging it to desk
-view it in leap or tagit
no tags are visible. What did I wrong?
Hm, maybe I should have asked more directly:
-Should the tags assigned in DT be visible in other open-meta-applications?
-Does anybody get different results?
I imported a file into DTPO and tagged it. Then I exported the file from both the (nontag) group I had put it in and from the Tag subgroup representing the tag. In both cases, using the Tags app, which is based on openmeta, I verified that both files had the proper tag.
I then tried your method of creating a new RTF in DTPO, tagged it, exported it to the desktop and the tag was included.
In my third test, I dragged out the file to the desktop. That one had no tag. So it looks like you have to “export” it using “files/folders”, not drag it.,
Thanks for testing! I never used the export function before, I thought that dragging to the desk means exporting.
Because It seems to be logical that
drag in = importing and
drag out = exporting
I would like to suggest that DT writes the open meta tags out when dragging files to a target outside the database.
‘Export’ involves not only sending the file to the Finder, but also its associated metadata. Tags will be placed into the Spotlight Comments field. Other metadata will be included in one or more DEVONtech_storage file(s), the number and placement depending on the organization of the exported content.
Usually when I’m giving directions about exporting content I specify that after choosing File > Export > Files & Folders, the selected content be sent t0 a new, empty folder in the Finder.
What’s the purpose of that DEVONtech_storage file? As it contains metadata about the exported folders and files, if the contents of that folder are now imported into another DEVONthink database, the metadata will be incorporated into the new ‘residence’ database.
Why did I specify a new, empty folder to hold exported content? That’s because if there’s a previous metadata file already in a folder, it could be overwritten if another export is made into that folder. Information will be lost.
So, logically and operationally, ‘Export’ means something more than the result of ‘dragging out’ content from a database. I don’t think you would like the additional complication of associated metadata files if dragging out became the same as Export. ‘Dragging out’ is clean and simple. The results of dragging out are just folders and/or files copied from the database to the Finder, which is generally what the user wants. If you want file & folders plus metadata, use the Export procedure, which adds some complexity above just copying files & folders to the Finder.
This isn’t to say that such distinctions in the current state of DEVONthink are fixed in concrete. DEVONthink (and OS X) are changing and evolving over time. But there’s usually a reason (perhaps not immediately obvious) for operations that at first blush appear to be equivalent to have different consequences in practice.
A number of applications use Spotlight Comments as the host for holding tags such as keywords and OpenMeta or other tags, for transport between applications and computers. Is that a safe place to hold metadata? Absolutely not. There are applications in common use that will destroy the contents of Spotlight Comments. The OpenMeta standard for sharing metadata between applications on a computer proposed using an area of OS X to store data that isn’t approved by Apple for that purpose, and that could result in loss of existing metadata stored there, anytime Apple decides to use that area of OS X code for another purpose. For a number of reasons, the dream of a universal tagging system remains in doubt. There’s some progress, though, and DEVONthink supports that.
Hi,
there are a number of issues here (and at stake for me):
- I’d lobby for a much wider support of openmeta-(meta-)data within DTP(O), meaning a live inclusion of meta-data when indexing (especially when indexing) external content within DTP(O)-databases. I want this additional layer of information I have added and use within the Finder-environement. I want to enhance this with information I gather/keep/organize within DTP, e.g. notes, links annotations etc. linked to files kept in Finder. I wan t to be able to look at data from different perspectives, from within DTP, (hopefully) helped by the built-in AI and from Finder (e.g. tags-view/Folder-structure of my material). Currently this is not implemented, an implementation would make DTP(O) so much more powerful. Openmeta supports this, the API is available so this should no be too difficult to put into. I’d suggest to link this to a user-decision based on a preference.
Data in DTP-database is already searchable by spotlight, so why not attach (openmeta-)tags to the relevant cache-files which identify items in the database (or indexed into…)? There would be the need to re-write this metadata every time the cache/index is re-written by DTP(O) but I believe this is not such a performance-problem.
Leap and Yep offer perspectives to look at my data/files which are different from DTP but far superior in connection with (openmeta)-tags. The current implementation of tags-view/search etc. in DTP is far from powerful and I am eagerly awaiting (and expect) improvements. Still, live resemblance/inclusion of openmeta-data within DTP would make it possible to use this superior perspective.
The export of data as a one-time-only operation to get openmeta-metadata attached to files makes – in my opinion – sense only when finishing a project and the exporting to an archive…
- It is true, metadata-support by Apple is somewhat lacking, SnowLeopard broke some part of openmeta and that led to a change in namespace where openmeta-tags are kept. This change is – to my knowledge - currently supported by apps made by ironic e.g. Deep, Yep, and Leap (latest releases) as well as DefaultFolderX (DFX). Some other applications like Punakea or Tags have not yet followed. This is not very big problem since there is a mechanism built in to – live – convert different flavours of openmeta-tags to the current/latest version.
So important question to the development-team at Devon (I know Bill is not part of it): did you implement the latest version of openmeta into the im/export-mechanism?
Disclaimer: These thoughts are work-in-progress, I have yet to grasp the full potential of the DTP(O)-way of conversion of Group-structure into tags (but bought the upgrade yesterday…)
Best regards,
Rolf
Just curious: are xattr and Spotlight Comments the same?
No, I do not like the additional files. But tags do not need an additional file as they are included. From a users point of view it’s not logical that some tags can be found in the file and some don’t (the ones that were created in DT).
So I would like DT to preserve the tags that I created in DT when I drag the file out. (Maybe you can use a modifier key to get rid of tags for privacy reasons)
The export function is very inconvenient (more clicks, an extra file).
Here’s why I want this functionality:
I’m organizing my teaching material in DT on the iMac. The files that I need the next day are dragged out to different folders inside my sync-folder. Every evening that folder gets synchronized with the AirBook that I take to my courses. There I use Leap to open the files. So I need the tags but not the extra file with the other metadata. I don’t want to use the cumbersome export function 20 times a day.
Edit:
Maybe I should collect the files I need in a DT Group and export them altogether so I need to use the export function only once.
Spotlight Comments are stored as X-Attributes:
spinoza:~/Desktop$ xattr -l foo.txt
com.apple.FinderInfo:
0000 00 00 00 00 54 78 4D 74 00 00 00 00 00 00 00 00 ....TxMt........
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
com.apple.metadata:kMDItemFinderComment:
0000 62 70 6C 69 73 74 30 30 5F 10 13 74 68 69 73 20 bplist00_..this
0010 69 73 20 66 6F 6F 20 74 65 78 74 2E 2E 2E 08 00 is foo text.....
0020 00 00 00 00 00 01 01 00 00 00 00 00 00 00 01 00 ................
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1E ...............
As you can see, there’s other stuff stored as xattrs…
Best, C
Although not before Leopard.
This discussion thread appeared when I queried the Forum about “meta data”, so I write here even though my issue may be more appropriate somewhere else. I am an historian and identifying the provenance of a document is crucial to my research. In terms of documents copied or downloaded from the Web, whether pdf, rtfd, webarchive, or whatever, I need clear identification of URL and date-time accessed. DTP is generally very good at preserving and showing this documentation — so long as the record remains within the DT database. However, this documentation of provenance is lost when the document is exported, unless the imported document (e.g. an imported document that had been saved, or printed, as a pdf or rtfd document; and of course a webarchive always contains its URL). If I save the document directly to DTP, either by Apple Services or by browser script (e.g. Devonagent, Safari, Camino, OmniWeb, etc), the provenance information is only in DTP’s metadata. I would like to see DTP incorporate the practice of MacJournal: Its Service “New Entry With Selection” attaches the URL of the document (or selection) to the saved RTFD document itself, and its Export function allows the incorporation of specified metadata, again on the document itself. The result is that provenance information is always with the document, regardless whether that document is in MacJournal or not. DTP is a much, much more powerful information management system, but I wish it also incorporated MJ’s method, perhaps old-fashioned?, regarding the “stamping” of provenance information (metadata) on the individual document. As a final example, if I export a document from DTP to desktop to send to a colleague, that document’s provenance information is lost unless I enter it manually.
Hi William-
Where would you suggest placing this metadata in the file formats you mention? Many of them don’t have places to put metadata.
I don’t know MacJournal, but if you’re suggesting that it wraps all of its data in an RTFD format, then DTPO could easily accomplish the same with a little Applescripting.
I regularly maintain lots of attributed data for my DTPO files via RTFD that has incorporated (at various times) JSON, YAML, and personal, idiosyncratic formats. It’s a simple matter to parse with Python or Ruby and appscript.
Best, Charles
Drag & drop did not always set Spotlight comments & OpenMeta tags, the final release will fix this.