Scribe to Zotero RDF not working

I have Scribe which I use regularly but have a number of sources I want to import to Zotero. When I try to import the RDF using the documentation process, I get an error and the sources won't import.

Help if you can. This may be a 2.0 bug because I didn't have this problem before.
  • What kind of error are you getting?
  • I would be happy to tweak Scribe export to get rid of the error. If you email me your exported rdf file I'll try to figure out the problem. However, I can't guarantee success given that Zotero can't even correctly import Zotero RDF exported from a Zotero database--see this forum and this ticket (this problem is different from yours though so it still does make sense to email me your file).
  • the same: export from Zotero 2.02 and import to 2.0.2 (Firefox 3.6.3 portable):

    Report-ID: 2059329215
    [JavaScript Error: "[Exception... "Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIFileURL.file]" nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)" location: "JS frame :: chrome://zotero/content/xpcom/translate.js :: anonymous :: line 1365" data: no]" {file: "file:.../_a/zottest/translators/RDF.js" line: 0}]

    [JavaScript Error: "[Exception... "Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsIFileURL.file]" nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)" location: "JS frame :: chrome://zotero/content/xpcom/translate.js :: anonymous :: line 1365" data: no]" {file: "file:///.../_a/zottest/translators/RDF.js" line: 0}]

    www.zotero.org : potentially vulnerable to CVE-2009-3555

    www.zotero.org : potentially vulnerable to CVE-2009-3555

    www.zotero.org : potentially vulnerable to CVE-2009-3555

    www.zotero.org : potentially vulnerable to CVE-2009-3555

    www.zotero.org : potentially vulnerable to CVE-2009-3555

    ssl.google-analytics.com : potentially vulnerable to CVE-2009-3555

    www.zotero.org : potentially vulnerable to CVE-2009-3555

    www.one.com : potentially vulnerable to CVE-2009-3555

    www.one.com : potentially vulnerable to CVE-2009-3555

    www.one.com : potentially vulnerable to CVE-2009-3555

    www.one.com : potentially vulnerable to CVE-2009-3555

    www.one.com : potentially vulnerable to CVE-2009-3555

    www.one.com : potentially vulnerable to CVE-2009-3555

    server.iad.liveperson.net : potentially vulnerable to CVE-2009-3555

    server.iad.liveperson.net : potentially vulnerable to CVE-2009-3555

    www.zotero.org : potentially vulnerable to CVE-2009-3555

    www.zotero.org : potentially vulnerable to CVE-2009-3555

    www.zotero.org : potentially vulnerable to CVE-2009-3555

    www.zotero.org : potentially vulnerable to CVE-2009-3555

    www.zotero.org : potentially vulnerable to CVE-2009-3555

    www.zotero.org : potentially vulnerable to CVE-2009-3555
  • edited March 3, 2013
    I have a similar problem, whenever I try to import my "exporteditems.rdf" into Zotero I get a "the selected file is not in a supported format" error. I tried to use the "zap gremlins" function of BBedit on the exporteditems file but this didn't solve the problem.

    Is there any other way to find out what's wrong with the rdf-file?

    (I'm using the latest version of Scribe, MacOS 10.6.8., Firefox 19.0, latest Zotero Plugin; Debug ID should be D1978021816.)

    ETA: I've debugged the file using Oxygen and found some invalid characters, but even after removing them, I get the same error message.
  • Can somebody point me in any direction I haven't looked at yet?

    What I've tried with the rdf so far:
    - BBEdit's Zap Gremlins function
    - Tried to clean up the file with Oxygen
    - Tried to open the file in Firefox and solved all problems til it would open in FF
    - Tried to import my library batch for batch, but it's just too big and I still haven't figured out what the entrys that won't import have in common...

    Is it possible that there is a translator error? Parts of the Zotero debug report include this:

    "(2)(+0002128): Translate: Detect using Bibliontology RDF failed:
    thrown exception => Translate: No RDF found
    url => /Applications/Scribe3/exporteditems.rdf
    downloadAssociatedFiles => true
    automaticSnapshots => false

    (4)(+0000000): Translate: Parsing code for MODS

    (4)(+0000237): Translate: Parsing code for Bookmarks

    (4)(+0000006): Translate: Parsing code for CSL JSON

    (3)(+0000034): 'message' => "JSON.parse: unexpected character"
    'fileName' => "/Users/XXXXXXXXXXX/Library/Application Support/Firefox/Profiles/cdav1xiz.default/zotero/translators/CSL JSON.js"
    'lineNumber' => 35
    'columnNumber' => 2

    detectImport@/Users/XXXXXXXXXX/Library/Application Support/Firefox/Profiles/cdav1xiz.default/zotero/translators/CSL JSON.js:35"

    and this:
    "(3)(+0000008): Translate: WARNING: new Zotero.Translate() is deprecated; please don't use this if you don't have to"
  • none of these are translator errors, no, this is just what you'd expect when Zotero doesn't recognize a format.

    If you can create a minimal Scribe export that doesn't import in Zotero and post it to gist.github.com as a public gist I can take a look. Unfortunately scribe hasn't been developed for almost five years and Elena isn't at GMU anymore, so no guarantees.
  • Thanks! Here's a tiny one that doesn't import:
    https://gist.github.com/anonymous/ba7b03ed0a5fc9ace672
  • edited March 7, 2013
    In the last code snippet I posted the following part of a URL (the google books URL) was the problem:
    /books?id=9RGoH6niqPcC&pg=PA38&lpg=PA38&dq=%22Biologie+der+%C3%A4sthetischen+Wahrnehmung%22&source=bl&ots=pcRHTLsBkw&sig=bwyubgsWA3wc2U6SMh20_nra-28&hl=de&ei=Jpf7TMaBM4zNswaQ6KGUBA&sa=X&oi=book_result&ct=result&resnum=2&ved=0CB8Q6AEwAQ#v=onepage&q=%22Biologie%20der%20%C3%A4sthetischen%20Wahrnehmung%22&f=false

    But not all of the entries that wont import contain links or google books links and not all entries that contain links are unimportable... back to trial and error it is (*§$%&/ this is so frustrating...)
  • so this is a Scribe bug. The reason the URL fails is that it contains unescaped ampersands (&), which is illegal in XML - they should be escaped as & amp; (without the space).

    There are only five protected characters in XML, so fixing this via search and replace shouldn't be hard. Here the characters and their escapes - again you'd have to remove the space after &:
    " & quot;
    ' & apos;
    < & lt;
    > & gt;
    & & amp;
  • btw. you can validate XML files e.g. here:
    http://www.xmlvalidation.com/
    if that throws an error Zotero likely won't accept it.
  • Thanks a lot! I guess I know how I'll spend my weekend then... :D
  • this shouldn't take more than a couple of hours using search&replace. Try escaping ampersands first, those would be the most common, though perhaps the hardest to escape properly.

    I believe quotation marks should only occur either after an = or before a space or newline. < should be preceded by a space, a newline, or> and similarly > should be followed by space, newline or <.
    Using a regex capable text editor would facilitate this:
    http://chronicle.com/blogs/profhacker/coming-to-an-elementary-school-near-you-regular-expressions/38340
  • Thanks a lot!!!! It finally worked!

    In case anybody else encounters this error, this is what I did:
    I used the xml-validator adam suggested, removed everything the validator "complained" about until it validated as having no errors.

    After that Zotero still wouldn't import the file so I also followed adams suggestions and escaped/removed the leftover protected XML characters.

    After that Zotero STILL refused to import and it turned out I had overlooked 4 html-tags (< i > etc), after I removed these it worked fine.

    Thanks again!
  • Help!
    I get the following error when I try to import my exported Scribe files into Zotero: "The selected file is not in a supported format."

    I have next to no xml knowledge, but following the advice above I managed to plug the file into an xml validator and painstakingly over many hours fix all the assorted problems it had (and there were MANY)…except one in the very last line, which I can only assume is still causing the thing not to import properly into Zotero (same error message as above):

    "This page contains the following errors:
    error on line 83563 at column 11: Opening and ending tag mismatch: URI line 0 and RDF"

    Does anyone know what to do with this?? I really want to get my work out of this no-longer-updated software and into something else! Thanks!
  • That error message should be fairly self explanatory, though it might be hard to find where the mismatch occurred.

    If you don't mind sharing the file publicly, you can upload it to Dropbox or something similar and paste the link here. Otherwise, you can send a private link to support@zotero.org with a link to this thread. We can take a quick look.
  • Thanks. I'm sure that if I actually understood xml it would be self-explanatory, but since I know just enough to recognize that most of the other problems were with formatting, special characters, and URLs, I have no idea how to fix the last line which I am just guessing refers back to something I haven't touched way at the beginning (it should be closing off the whole thing, right?). I'll see if I can figure it out but will likely have to send a link.
  • I got the file from kleb. Here are the issues that had to be fixed (the file was already processed, so not sure how much of this is coming from Scribe directly):

    1. There were a couple missing slashes for empty elements. e.g. <dcterms:URI RDF:about="..." RDF:value="..."/> (the slash in bold was missing)

    2. A number of bib:Memo -> RDF:value elements contained unescaped HTML formatting (specifically <u> and <i>)

    3. The file was encoded in UTF-16BE, which shouldn't have been an issue per se, but there is a bug in Zotero. which prevents Zotero from automatically detecting this encoding. That should be fixed by this patch in an upcoming Zotero version, but in the mean time, it is possible to specify the correct character encoding in Preferences -> Export -> Import Character Encoding.
Sign In or Register to comment.