Thank you for the clarification. Does your use of “currently” mean that metadata may be opened up for scripting in the future? I am curious about why this metadata is read-only: is there some technical or functional limitation that makes changing metadata through scripting unfeasible or difficult in other ways, or is this a DT design decision?
I asked in my original post:
Can you provide some insight about why the document’s “keywords” metadata field was set to the plain text preceded with the plain text, “Tags:” in the imported document? As I wrote earlier, one would expect that text identified as “Tags:” would be imported as DT tags, and not “keywords,” if this text were to be recognized at all when documents are imported.
I’m not able to reproduce this effect - merely by adding such text to the body of an RTFD and then importing it:
Is it possible that whatever process is creating the RTFDs is also adding the keyword metadata to the file(s)? Where these files originally produced by an export process involving HTML that incorporated </> tags?
Except in the case of HTML that includes such “meta” tags, DT does not parse imported text looking for keywords, tags or any other metadata. For imported documents, if there exists OpenMeta extended attributes containing tag values, then DT will recognize the tags and create DT Tags associated with that document. This is really the only way that imported documents get Tags associated with them.
The whole topic of keywords, metadata, and tags is often confusing. Perhaps this post might help sort it for you.
That’s exactly what happened! These rtfd documents were produced from Journler’s export function. I surmise that Journler does not support OpenMeta, and so, transformed its tags into keywords when it exported the documents. I was unaware that this was happening.
While verifying this, I discovered that one can use “keyword:” in Spotlight searches (and can presumably use the other “properties” metadata, such as “author,” “company,” etc.) Very useful.