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
