[opml.org is back up!]
The basic OPML spec allowed for an
outline element whose
type attribute was
link that would also have a
url attribute whose value would be a valid URI. An OPML v1.0 example is
here. The whole 'type' attribute method is fairly arbitrary and open.
OPML 2.0 added a new
type value of
include where the
url value is
always an OMPL file (example
here & sample referenced
include). This feature is not currently supported by TB. FWIW, in the several years that OPML has been discussed here by TB users as an interchange format I've not seen anyone ask for
include support. So that's likely the reason it isn't supported.
It's worth noting point #3 in the 'Shortcomings' section of the Wikipedia
article on OPML, by way of managing expectations for what OPML-based intechange can offer:
Quote:Due to the arbitrary nature of the "type" attribute, and the acceptance of arbitrary attributes on "outline" elements, interoperability of OPML documents relies almost entirely on the undocumented conventions of content producers.
TB's OPML is closer to following the unofficial 'flavour' of OPML popularised by Omnigroup which centres around just these per-note characteristics:
- title: OPML "text" attribute, TB's $Name.
- text: Omni addition OPML "_note" attribute, TB's $Text
- checked status: Omni addition OPML "_status" attribute, TB's $Checked.
- creation date: OPML "created" attribute, TB's $Created.
As it happens, TB maps any other OPML attribute to a new TB String-type attribute using the OPML attributes name (and case)So, if an OPML file includes
categories (tags) data of "xx/yy/zz" - a slash being OPML's tags delimiter, TB with create $categories and insert the value "xx/yy/zz". To put that into a TB set-type attribute $Tags you'd simply find notes with a value for $categories and then use this code to move/clean the tags values and clear out the source attribute:
$Tags = $Tags+ ($categories.replace("/",";")); $categories=;It's worth noting that the user has no access to OPML->TB attribute mapping, which is why the extra steps are needed in the last example above.
Quote:Does OMPL allow for specifying links between items?
No and Yes. No, it doesn't expect/define linkage within the OPML <outline> items. Yes, in that use of the 'url' type attribute can define a line to the represented iyem via
some other protocol usch as HTTP or RSS. DevonThink, Bookends and some other apps extend accessibility further by (on the computers on which they're installed) by special protocols. For instance, on my Mac (only) this reference '
bookends://sonnysoftware.com/40489' opens a reference in my Bookends library; on a different Mac with Bookends it will open Library item 40489; on a Mac without Bookends nothing will happen. FWIW, I've searched but Zotero seems to lacks such an external reference protocol.
Tab-delimited import seems a much easier and simpler method to use for your Zotero -> TB needs. You configure you Zoerto export template, select the Zotero items of interest and export. The column headers you define in line #1 of the output file from Zotero become attributes in TB unless they simply map to existing TB attributes; the first column
always maps to $Name. Thus is would be trivial (assuming the Zotero techies will build the export mechanism for you) to export Zotero's item ID for a reference to $ZoteroID whilst the item would export the IDs of all other Zotero items to which is links as a semi-colon delimited list pointed at $ZoteroLinks. Then in TB is simple to set up an agent (i.e. do this job
once) whose query finds any note with a ZoteroID value and whose action looks at each note's ZoteroLinks and then links the note's original to the note(s) with each of the IDs in the list using
linkTo(). Pretty simple.
In summary, you'd ask your Zotero techs to write something that allowed you to map a Zotero field (attribute?) to a particular column in the export data. Perhaps a TXT file Zotero will read where each line is in the form
Zotero field{tab}TB attribute name. Zotero's export would also need to enclose in straight double quotes any Zotero value containing a Tab or line break character.
It strikes me that latter method is much more achievable in the short term than OPML as the TB end is all in place, you just need a Zotero exporter which you'd still need if going the XML route. Effort in TB is focussed on a new Cocoa based version so I suspect building a new OPML import interface might not sit at the top of the new feature list (especially in v5.x). I don't mean the latter unkindly, but if you want to do something
now, I'd look at the tab-delim route.