On 18 Mar 2008, at 5:06 PM, P Kishor wrote: > On 3/18/08, Christiaan Hofman <[EMAIL PROTECTED]> wrote: >> >> On 18 Mar 2008, at 3:26 PM, P Kishor wrote: >> >>> Hi folks, >>> >>> I have never had good experience importing data into another program >>> that I have exported from BibDesk. I love BibDesk for many of its >>> capabilities and flexibility, but it just doesn't fit my workflow >>> for >>> now. This, of course, is my failing, not BibDesk's. I just haven't >>> found a good workflow. More on that in another email; for now, the >>> BibDesk format -- >>> >>> I exported my library, and tried to import it into Zotero, but the >>> import just wouldn't work, not with the entire library, not with a >>> few >>> records from the library, not even with one record from the library. >>> >> >> >> That is a problem of Zotero, as BibDesk export completely valid >> bibtex. Have you tried export as minimal bibtex? > > yes, even minimal bibtex failed. The only thing that succeeded was > bib2xml (MODS XML) and then into Zotero. >
And have you tried turning off the template in the Files pref pane? It might be that they can't handle comments. >> >> >>> Eventually I used bib2xml [1] to convert to MODS XML, and then >>> imported that into Zotero. Of course, none of my attached (linked) >>> files came through. >>> >>> I tried the same with Sente. Fortunately, Sente was able to read the >>> BD export, but again, none of the attachments came through. >>> >>> When I open the .bib file, I don't see any human readable >>> information >>> for my linked file. I do see uuencoded kind of binary-to-text >>> gibberish. Here is an example -- >>> >>> @article{Chapin_2004_aa, >>> Author = {Mac Chapin}, >>> Date-Added = {2007-01-23 10:05:03 -0600}, >>> Date-Modified = {2007-12-29 11:56:46 -0600}, >>> Journal = {World Watch Magazine}, >>> Local-Url = >>> {file://localhost/Users/punkish/Documents/BibDesk/chapin-challenge_to_conservationists.pdf >>> }, >>> Month = {11}, >>> Title = {A Challenge to Conservationists}, >>> Year = {2004}, >>> Abstract = {As corporate and government money flow into the >>> three big >>> international organizations that dominate the "world's conservation >>> agenda," their programs have been marked by growing conflicts of >>> interest---and by a disturbing neglect of the indigenous peoples >>> whose land they are in business to protect.}, >>> Bdsk-File-1 = >>> {YnBsaXN0MDDUAQIDBAUGCQpYJHZlcnNpb25UJHRvcFkkYXJjaGl2ZXJYJG9iamVjdHMSAAGGoNEHCFRyb290gAFfEA9OU0tleWVkQXJjaGl2ZXKoCwwXGBkdJCVVJG51bGzTDQ4PEBEUViRjbGFzc1dOUy5rZXlzWk5TLm9iamVjdHOAB6ISE4ACgAOiFRaABIAGWWFsaWFzRGF0YVxyZWxhdGl2ZVBhdGjSDRobHFdOUy5kYXRhgAVPEQHsAAAAAAHsAAIAAARpYmlzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADCKq12SCsAAAEaFlcfQSBDaGFsbGVuZ2UgdG8gQ29uc2UjNURDNkVBLnBkZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF3G6sJWQV8AAAAAAAAAAAABAAUAAAkgAAAAAAAAAAAAAAAAAAAABDIwMDQAEAAIAADCKvPGAAAAEQAIAADCVoevAAAAAQAYARoWVwEaFlYAXcZdAAfZCAAH2PsADroyAAIAUGliaXM6VXNlcnM6cHVua2lzaDpEb2N1bWVudHM6QmliRGVzazpDaGFwaW46MjAwNDpBIENoYWxsZW5nZSB0byBDb25zZSM1REM2RUEucGRmAA4ATgAmAEEAIABDAGgAYQBsAGwAZQBuAGcAZQAgAHQAbwAgAEMAbwBuAHMAZQByAHYAYQB0AGkAbwBuAGkAcwB0ACgAYQBhACkALgBwAGQAZgAPAAoABABpAGIAaQBzABIAUlVzZXJzL3B1bmtpc2gvRG9jdW1lbnRzL0JpYkRlc2svQ2hhcGluLzIwMDQvQSBDaGFsbGVuZ2UgdG8gQ29uc2VydmF0aW9uaXN0KGFhKS5wZGYAEwABLwAAFQACAA7//wAA0h4fICFYJGNsYXNzZXNaJGNsYXNzbmFtZaMhIiNdTlNNdXRhYmxlRGF0YVZOU0RhdG >>> FYTlNPYmplY3RfEEcuLi9Eb2N1bWVudHMvQmliRGVzay9DaGFwaW4vMjAwNC9BIENoYWxsZW5nZSB0byBDb25zZXJ2YXRpb25pc3QoYWEpLnBkZtIeHyYnoicjXE5TRGljdGlvbmFyeQAIABEAGgAfACkAMgA3ADoAPwBBAFMAXABiAGkAcAB4AIMAhQCIAIoAjACPAJEAkwCdAKoArwC3ALkCqQKuArcCwgLGAtQC2wLkAy4DMwM2AAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAA0M=}} >>> >>> >>> Of course, the double-quotes in the Abstract give rise to Tex errors >>> (" not allowed at top-level or some nonsense like that). Getting >>> back >>> to the location of the linked file, however, I might be missing >>> this, >>> but I can't see any helpful information. In the previous >>> generation of >>> BD, I had the "Local-Url" which very clearly stated that the file >>> was >>> at >>> file://localhost/Users/punkish/Documents/BibDesk/chapin-challenge_to_conservationists.pdf >>> . >>> Of course, now with the new way of doing things, it is actually at >>> "~/Documents/BibDesk/Chapin/2004/A Challenge to >>> Conservationist(aa).pdf" but I don't see that information anywhere >>> in >>> the above record. Of course, it could be that gibberish, the value >>> of >>> "Bdsk-File-1" but this way is too opaque for me. >>> >>> Perhaps this is causing neither Zotero nor Sente to figure out where >>> the linked file is located. The Sente folks are being really nice >>> and >>> are helping me with "pre-sales support" trying to figure out how to >>> import this correctly, but I am now wondering about the logic of >>> such >>> a opaque way of storing things. >>> >>> How do I extract from the above record the location of my linked >>> file? >>> >>> [1] http://www.scripps.edu/~cdputnam/software/bibutils/bibutils.html >>> >>> -- >>> Puneet Kishor http://punkish.eidesis.org/ >>> Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ >>> Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ >> >> >> These fields have been discussed on this list already several times. >> The Bdsk-File-* fields are opaque and specific to BibDesk (though we >> only use standard encodings and standard Cocoa and Carbon >> functionality, nothing truly custom), so no other program will be >> able >> to make sense out of it, unless they specifically add it. This allows >> much better and reliable tracking of files, as it is not restricted >> to >> the fragile relative or absolute path of the file. > > So, is there any way to re-construct the location of the linked file? > I don't have any issues with achieving better capability through the > use of BD-specific, Cocoa-specific encodings, as long as the encoded > information can be decoded upon export. > In BibDesk you can get it through copy/paste and AppleScript. You can also automatically synchronize a text field such as Local-Url with the first linked file using a script hook (there is one available on the Wiki). From the bibtex file, there is no way to reconstruct the path. > How does some other tool figure out where the linked file is stored? > That is the issue here, I guess. > They need to know how it is stored (which can be figured out from the source of BibDesk) and actually do it. > Many thanks for your assistance. > > >> >> Christiaan >> ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users