On 3/18/08, Christiaan Hofman <[EMAIL PROTECTED]> wrote:
>
> On 18 Mar 2008, at 5:28 PM, P Kishor wrote:
>
> > On 3/18/08, Christiaan Hofman <[EMAIL PROTECTED]> wrote:
> >>
> >> 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).
> >
> > I am assuming it is
> > http://bibdesk.sourceforge.net/scripts/LocalFileToLocal-UrlScriptHook.scpt
> >
> > however, I am getting the following error --
> >
> > An error has been encountered in accessing this page.
> >
> > 1. Server: bibdesk.sourceforge.net
> > 2. URL path: /scripts/LocalFileToLocal-UrlScriptHook.scpt
> > 3. Error notes: File does not exist:
> > /home/groups/b/bi/bibdesk/htdocs/scripts/LocalFileToLocal-
> > UrlScriptHook.scpt
> > 4. Error type: 404
> > 5. Request method: GET
> > 6. Request query string:
> > 7. Time: 2008-03-18 09:23:16 PDT (1205857396)
> >
>
>
> Fixed. URLs and paths are generally supposed to be case insensitive,
> so i don't know why this did not work.
>
Thanks Christiaan. Got it this time.
I have to bother you a bit more to figure out how to make this work. I
put the script in ~/Library/Application Support/BibDesk/Scripts.
Restarted BD for good measure. Selected all my entries, and chose to
run this script from the scripts menu in BD. Nothing happened. This
was what was obvious to me, but obviously this isn't the way to run
this script, no?
I have about 205 entries, and I want to sync local file to local URL
field for all of them.
Many thanks,
>
> >> From the bibtex file, there is no way to reconstruct the path.
> >
> > Hmmm... this is very worrying to *me* as it breaks down many other
> > potential tools. I routinely use Perl and its BibDesk modules to
> > access my library. The beauty of the .bib format is that it is plain
> > text, and all documented BibTex format. This divergence, that is also
> > irreversible without a fair bit of non-automate-able export sequence
> > of steps breaks all that.
> >
>
>
> It does not 'break' anything, it just is useless. Anyway, this has
> already been discussed to death.
>
>
> > I will continue trying to get the above mentioned script, and if that
> > works, I will consider rolling back to the BD version that was prior
> > to the current multi-attachment, Bdsk-file-? proprietary field
> > dependence. That was version 1.3.13 and earlier, no?
> >
> >
>
>
> You can have both.
>
>
> Christiaan
>
>
> >
> >>
> >>
> >>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
