Exporting customized html reference list

Help
2008-02-13
2013-05-28
  • Hi,

    I am facing a small problem with the svn version of refbase.

    Here's my goal. I'd like to extract some of the references in my refbase serveur and generate a piece of html code that I can copy and paste in an external web page. The more automatic this is, the better for me :)

    My current approach is to use the refbase command-line client (http://wiki.refbase.net/index.php/Command_line_clients). This works fine for the query part and even provides some html output. However the generated html does not meet all my needs. I have thus started fiddling with citation styles. I managed to generate html blocks with clickable DOI links. However I still don't have access to several interesting field that I'd like to use (url, notes and abstract).

    If I specify '--showlinks=1' to the command line client, I do have access to the url field (and can generate clickable urls) but this has the drawback of displaying internal refabse links on the right of the page.

    According to the following message:
    http://sourceforge.net/forum/message.php?msg_id=3370193
    ////// quoting/////////
    That's because the abstract field isn't included in MySQL queries for cite output. You can easily add it in 'search.php' (line 4372), i.e instead of:

    $query = "SELECT type, author, year, ...

    write:

    $query = "SELECT abstract, type, author, year, ...

    Then, you can call the contents of the abstract field in script 'cite_PolarBiol_MarBiol_MEPS.php' like this:

    $row['abstract']
    ///////end quoting////////////

    I tried to modify 'search.php' as proposed but the line number has changed. I tried making the same king of changes on line 5161 but it didn't solve my problem. I still don't have access to the url, notes and abstract fields.

    I am wondering whether I should continue fiddling with the refbase code or if I should use another path.

    I thought about using the command line client to generate a bibtex file and then use a bibtex to html tool (but then I have to find a tool that does what I want). I also thought about using the command line client to generate MODS xml and then use an xsl stylesheet to generate the html. However I didn't find any such existing stylesheet to start from and my xsl stylesheet knowledge is basically null.

    What would be your advice?

    Best regards,
    Tom Vercauteren

     
    • Is there a reason that you wish to copy/paste the HTML?  Can you customize the result of the citations view to your liking (with header.php, footer.php, and CSS)?  Or can you include automatically-generated results through AJAX or an IFRAME?  Matthias talks about this later approach at:

      http://sourceforge.net/forum/message.php?msg_id=4404553

      You'd still need to fiddle with the style, though.  You don't mention if you are using the trunk or the bleeding-edge branch (though they aren't too different at this time).  The line is now 5161 & here is context:

      5157    // Depending on the chosen output format, construct an appropriate SQL query:
      5158         if ($displayType == "Cite")
      5159             {
      5160                 // for the selected records, select all fields that are visible in Citation view:
      5161                 $query = "SELECT type, author, year, title, publication, abbrev_journal, volume, issue, pages, thesis, editor, publisher, place, abbrev_series_title, series_title, series_editor, series_volume, series_issue, edition, language, author_count, online_publication, online_citation, doi";
      5162

      This route (making a custom style & using either show.php directly or an IFRAME or AJAX) seems to be the best.

      It seems like a waste to manually cut/paste unless you absolutely must.  refbase has features that hopefully make in unnecessary to set something up from scratch to turn bibtex or XML into HTML (that said, if you already had a tool that already had the output you wanted, it would be quick to do this & should work).

      --Rick

       
      • Hi Rick and Matthias,

        Thanks a lot for your fast answers ans sorry for not replying as promptly.

        Below is some partial follow-up.

        >  Is there a reason that you wish to copy/paste the HTML?  Can you customize the
        >  result of the citations view to your liking (with header.php, footer.php, and
        >  CSS)?  Or can you include automatically-generated results through AJAX or an
        >  IFRAME?  Matthias talks about this later approach at:
        http://sourceforge.net/forum/message.php?msg_id=4404553

        There are basically two reason why I need to copy and paste the citation list rather than having an automatically-generated result.
        1) The refbase server is on an intranet and the reference list is for internet (I don't want to put our refbase database on internet).
        2) I don't check every modification to the database. As any user can introduce a reference or modify an entry, it could potentially lead to a reference list that my boss wouldn't like to see on our website :) Having one manual check is better for production uses.

        Apart from that, thanks for the pointers, I have implemented such automatically-generated results on our intranet. I thus only keep a bookmark that lets me do the check and copy-paste very easily. I thus don' use the command-line anymore (sorry Matthias).

        >  You'd still need to fiddle with the style, though.  You don't mention if you
        >  are using the trunk or the bleeding-edge branch (though they aren't too different
        >  at this time).  The line is now 5161 & here is context:
        I am using the trunk branch. As I mentioned, changing line 5161 of search.php did not have any effect. But after looking some more into it, I found that changing line 505 of show.php (and not search.php) led to what I wanted.

          503         elseif ($displayType == "Cite") // select all fields required to build proper record citations:
          504         {
          505             $query = "SELECT type, author, year, title, publication, abbrev_journal, volume, issue, pages, thesis, editor, publisher, place, abbrev_series_title, series_title, series_editor, series_volume, series_issue, language, author_count, online_publication, online_citation, doi";

        got turned into

          503         elseif ($displayType == "Cite") // select all fields required to build proper record citations:
          504         {
          505             $query = "SELECT url, notes, abstract, type, author, year, title, publication, abbrev_journal, volume, issue, pages, thesis, editor, publisher, place, abbrev_series_title, series_title, series_editor, series_volume, series_issue, language, author_count, online_publication, online_citation, doi";

        >  Right, and I think that a method in the interface to copy the current results
        >  as simple HTML might be nice to have. This is probably best handled by an appropriate
        >  citation output style that can be easily adopted by the refbase admin.
        That would indeed be more user friendly than modifying the code :)

        >  Could you give us a full list of requirements which your desired HTML output
        >  should fulfill? I.e., something like: include citations plus abstracts & notes,
        >  with external links, but no internal (refbase-related) links.
        You guessed it right.

        >  That's correct. So I assume that you don't want to have any refbase-related
        >  links included in the HTML output? This is currently not possible via a direct
        >  URL parameter. However, if you've made a custom citation format file (similar
        >  to 'cite/formats/cite_html.php') you could pass a custom value as the first
        >  parameter of function 'printLinks()' in that file. I.e., in order to show file
        >  & external links but suppress refbase-related links in Cite view, use this function
        >  call:
        >   $recordTableData .= printLinks(array("file", "url", "doi", "isbn", "xref"),
        >  instead of this one:
        >   $recordTableData .= printLinks($showLinkTypesInCitationView, ...
        >  The above modification will only print links to available files as well as one
        >  of the links DOI/URL/ISBN/XREF (in that order of preference).
        Well I didn't need to do that modification since I only want to get the DOI and url links within the text (not on the right). However if both DOI and url are available I want to show them both. I basically chose to use the url field as a pointer to an open-access version of the papers (such as a preprint or a post-print) when there is one.

        >  Hmm, strange, I would have assumed that this would work. If you add, say, 'abstract'
        >  to the appropriate SQL query, you should be able to access the contents of the
        >  'abstract' field via '$row["abstract"]' within your custom citation format file.

        >  I just tested this with my local refbase dev version (which is newer than the
        >  refbase SVN version) and it worked fine, but I've made many changes to the code
        >  which I've yet to commit.
        Well I don't know much about refbase code but changing show.php instead of search.php did more on my installation...

        >  Building a custom citation format file is currently a reasonable path.

        >  Ideally, something like your goal would be easily achieved using a 'show.php'
        >  URL. Here's an example that comes close to your goals:
        http://polaris.ipoe.uni-kiel.de/refs/show.php?author=Granskog&submit=Cite&showLi
        >  nks=1&showRows=25&wrapResults=0
        >  Note the 'wrapResults=0' parameter that causes refbase to just return the results
        >  data (instead of the full HTML page). However, w.r.t. your goals, it's not yet
        >  perfect. The refbase-related links are still there, and there are no abstracts
        >  or notes. But as outlined above, if you've adopted the SQL query in 'search.php'
        >  and have made a custom citation format file, I *think* that you could accomplish
        >  your goals using the current SVN code.
        Thanks for the 'wrapResults=0' tip. I hadn't seen it before and it exactly does what I wanted!

        So here is the url that I use:
        http://refbase/show.php?contribution_id=MKT-TDI&without=dups&submit=Cite&showLinks=0&showRows=100&citeOrder=type-year&citeStyle=MKT&wrapResults=0

        >  W.r.t. future development, we've talked on the refbase dev list about adding
        >  a "Custom view" output to refbase (in addition to the existing List, Cite, Details
        >  and Export outputs). This would allow the admin to define the fields that would
        >  be included in HTML output when 'submit=Custom' is passed as URL parameter.
        >  A HTML template file could take care of the default formatting for this Custom
        >  view. Anyways, this isn't done yet.
        Seems like a good idea to me.

        Just to let you see I have put an example output here:
        http://tom.vercauteren.googlepages.com/test

        Thanks again for your nice software and your great support.

        Best,
        Tom

         
    • Hi Tom,

      thanks for your detailed problem description. I see that Rick did already reply to your post, I'll add some further suggestions below. Hope this helps...

      > Here's my goal. I'd like to extract some of the references in my
      > refbase serveur and generate a piece of html code that I can copy
      > and paste in an external web page.

      That's a reasonable task, and your posts shows that this isn't easy enough using the currently available refbase code. Sorry for the trouble.

      > The more automatic this is, the better for me :)

      Right, and I think that a method in the interface to copy the current results as simple HTML might be nice to have. This is probably best handled by an appropriate citation output style that can be easily adopted by the refbase admin.

      > My current approach is to use the refbase command-line client
      > (http://wiki.refbase.net/index.php/Command_line_clients). This
      > works fine for the query part and even provides some html output.

      It's nice to hear that the refbase CLI actually gets used. ;-)

      > However the generated html does not meet all my needs.

      Could you give us a full list of requirements which your desired HTML output should fulfill? I.e., something like: include citations plus abstracts & notes, with external links, but no internal (refbase-related) links.

      > I have thus started fiddling with citation styles. I managed to
      > generate html blocks with clickable DOI links. However I still
      > don't have access to several interesting field that I'd like to
      > use (url, notes and abstract).

      Right, abstracts & notes are currently not included in SQL queries that generate citation output.

      > If I specify '--showlinks=1' to the command line client, I do have
      > access to the url field (and can generate clickable urls) but this
      > has the drawback of displaying internal refabse links on the right
      > of the page.

      That's correct. So I assume that you don't want to have any refbase-related links included in the HTML output? This is currently not possible via a direct URL parameter. However, if you've made a custom citation format file (similar to 'cite/formats/cite_html.php') you could pass a custom value as the first parameter of function 'printLinks()' in that file. I.e., in order to show file & external links but suppress refbase-related links in Cite view, use this function call:

      $recordTableData .= printLinks(array("file", "url", "doi", "isbn", "xref"), ...

      instead of this one:

      $recordTableData .= printLinks($showLinkTypesInCitationView, ...

      The above modification will only print links to available files as well as one of the links DOI/URL/ISBN/XREF (in that order of preference).

      > According to the following message:
      > http://sourceforge.net/forum/message.php?msg_id=3370193
      [...]
      > I tried to modify 'search.php' as proposed but the line number has
      > changed. I tried making the same king of changes on line 5161 but
      > it didn't solve my problem. I still don't have access to the url,
      > notes and abstract fields.

      Hmm, strange, I would have assumed that this would work. If you add, say, 'abstract' to the appropriate SQL query, you should be able to access the contents of the 'abstract' field via '$row["abstract"]' within your custom citation format file.

      I just tested this with my local refbase dev version (which is newer than the refbase SVN version) and it worked fine, but I've made many changes to the code which I've yet to commit.

      > I am wondering whether I should continue fiddling with the refbase
      > code or if I should use another path.

      Building a custom citation format file is currently a reasonable path.

      Ideally, something like your goal would be easily achieved using a 'show.php' URL. Here's an example that comes close to your goals:

      http://polaris.ipoe.uni-kiel.de/refs/show.php?author=Granskog&submit=Cite&showLinks=1&showRows=25&wrapResults=0

      Note the 'wrapResults=0' parameter that causes refbase to just return the results data (instead of the full HTML page). However, w.r.t. your goals, it's not yet perfect. The refbase-related links are still there, and there are no abstracts or notes. But as outlined above, if you've adopted the SQL query in 'search.php' and have made a custom citation format file, I *think* that you could accomplish your goals using the current SVN code.

      W.r.t. future development, we've talked on the refbase dev list about adding a "Custom view" output to refbase (in addition to the existing List, Cite, Details and Export outputs). This would allow the admin to define the fields that would be included in HTML output when 'submit=Custom' is passed as URL parameter. A HTML template file could take care of the default formatting for this Custom view. Anyways, this isn't done yet.

      > I thought about using the command line client to generate a bibtex
      > file and then use a bibtex to html tool (but then I have to find a
      > tool that does what I want). I also thought about using the
      > command line client to generate MODS xml and then use an xsl
      > stylesheet to generate the html.

      Using export formats such as BibTeX or MODS XML plus some kind of conversion mechanism might be a useful workaround. That said, in the future there might be more/better options: I'm currently working on OpenSearch Atom XML ouput for refbase, which will give you a flexible output format that is easily converted into other formats (such as HTML) via a stylesheet or script, and from which you can grab stuff as needed.

      Also, though it doesn't meet your requirements for HTML output (such as links, abstracts & notes), I'd like to mention the Markdown output format here, which can be used to produce simple HTML.

      The Markdown format is a plain text format that can be easily converted to structurally valid (X)HTML using converter software available in a variety of languages (such as Perl, PHP, Python, Ruby, and others). See:

      http://daringfireball.net/projects/markdown/
      http://en.wikipedia.org/wiki/Markdown

      Here's an example of Markdown output from refbase:

      http://polaris.ipoe.uni-kiel.de/refs/show.php?title=delta&without=dups&submit=Cite&citeType=Markdown

      > What would be your advice?

      Currently, developing a custom citation format file may be your best option. I could offer you to have a look over your file if this is of any help.

      In the future, parsing (and generating output from) OpenSearch Atom XML may be better since that wouldn't require hacking the refbase code. You'd still need to write a converter script or XSLT stylesheet, though.

      Matthias

       
    • Hi Tom,

      thanks for the update, I'm glad to hear that you could find a solution! Your sample output looks nice.

      I agree that things like what you've been struggling with should get way easier in the future, i.e. the user shouldn't be required to hack the code. For applications like yours, we're not there yet, but hopefully so at some point in the not-so-distant future.

      And I'll try to remember to finally document *all* of the currently available 'show.php' options (such as the 'wrapResults=0' parameter) in our wiki.

      Regards, Matthias

       
      • Hi Rick and Matthias,

        Just a followup on the topic of exporting cool html reference lists. I was wondering whether bibliographic metadata could be embedded in html exports such as the one discussed in this thread.

        I have seen that refbase includes COinS (<span class="Z3988" ...></span>) within its web interface which is great. The problem is that these metadata get lost in my export process.

        If I use the show.php function with showLinks=0, the COinS metadata does not appear in the html anymore. Is there a workaround or should I post this on the feature request?

        Best regards,
        Tom

         
        • The only work-around would be to modify search.php.

          Any idea where to put the COinS?  None of the other columns are required & it is aesthetically pleasing to have them in the grid of links if LibX or a bookmarklet is to replace them with an icon....

          --Rick

           
          • Hi Rick,

            Thanks for your fast answer. Refbase support is definitely great!

            I sort of found an easy solution. Since I already use a custom style, I tried to simply add something like the code snippet below to my cite_CUSTOM.php file.
            ///////////////////////////
            $coins = coins($row);
            if  (!empty($coins))
            {
                $record .= coins($row);
            }
            ///////////////////////////
            I indeed get COinS tags within my reference list. The problem is that they are not correctly recognized by zotero. I get a "Could not save item. An error occured while saving this item. Check known translator issues..."

            It doesn't seem to be related to my modification as I get the same error trying to use zotero on my refbase web interface. In some cases though, it seems to work (with only a few  items).

            A problematic example is shown below:
            http://tom.vercauteren.googlepages.com/test

            Do you know if it is a zotero problem, a refbase one or a problem related to my modifications?

            Thanks,
            Tom

             
            • Hi Tom,

              Rick knows much more about COinS and Zotero, so I'll just point out a few things that I noticed...

              Using Zotero 1.0.3 I've tried to add records from your test page to Zotero, and I get the same error as you do.

              Then, I took a few records from your test page (those with PMIDs), fetched them from PubMed, and added them to the refbase beta database:

              <http://beta.refbase.net/show.php?records=861,862,863,864,865,866>
              <http://beta.refbase.net/show.php?records=861,862,863,864,865,866&submit=Cite&showRows=10>

              Zotero seems to import these records more or less[*] fine, both from List view (via unAPI) as well as from Cite view (via COinS). The generated COinS tags (from your test page and the refbase beta database) look quite similar to me so I don't really understand why your COinS tags would cause problems, and the ones from the beta database wouldn't. Which version of Zotero are you using?

              [*] However, I noticed that, for COinS import, Zotero seems to put the article's first author last. This isn't a problem with records imported from List view via unAPI. Since unAPI is also richer in content (and data model), we should probably add unAPI links to citation output as well (and I can't remember why we haven't done so, maybe it was just an oversight?).

              I later edited three of the above mentioned records (864,865,866) and changed their refbase type to "Conference Article". This will also change the type ('rft_val_fmt') value in the COinS tag from "journal" to "dc", which, in turn, causes Zotero 1.0.3 to incorrectly import these records as web pages. Rick may know better but I guess that the only work around for us will be to use unAPI instead.

              > It doesn't seem to be related to my modification as I get the same
              > error trying to use zotero on my refbase web interface. In some
              > cases though, it seems to work (with only a few  items).

              Can you check whether your problem only occurs with records whose refbase type is set to something other than "Journal Article", "Book Chapter" or "Book Whole"?

              Thanks, Matthias

               
              • Hi Matthias

                >  Using Zotero 1.0.3 I've tried to add records from your test page to Zotero,
                >  and I get the same error as you do.

                >  Then, I took a few records from your test page (those with PMIDs), fetched them
                >  from PubMed, and added them to the refbase beta database:

                >   <http://beta.refbase.net/show.php?records=861,862,863,864,865,866>
                >   <http://beta.refbase.net/show.php?records=861,862,863,864,865,866&submit=Cite&s
                >  howRows=10>

                >  Zotero seems to import these records more or less[*] fine, both from List view
                >  (via unAPI) as well as from Cite view (via COinS). The generated COinS tags
                >  (from your test page and the refbase beta database) look quite similar to me
                >  so I don't really understand why your COinS tags would cause problems, and the
                >  ones from the beta database wouldn't. Which version of Zotero are you using?
                Same as yours 1.0.3.

                >  [*] However, I noticed that, for COinS import, Zotero seems to put the article's
                >  first author last. This isn't a problem with records imported from List view
                >  via unAPI. Since unAPI is also richer in content (and data model), we should
                >  probably add unAPI links to citation output as well (and I can't remember why
                >  we haven't done so, maybe it was just an oversight?).
                I am just discovering these tools. Are you saying I should rather use unAPI than
                COinS if I can.

                >  I later edited three of the above mentioned records (864,865,866) and changed
                >  their refbase type to "Conference Article". This will also change the type
                >  ('rft_val_fmt') value in the COinS tag from "journal" to "dc", which, in turn,
                >  causes Zotero 1.0.3 to incorrectly import these records as web pages. Rick may
                >  know better but I guess that the only work around for us will be to use unAPI
                >  instead.

                >  Can you check whether your problem only occurs with records whose refbase type
                >  is set to something other than "Journal Article", "Book Chapter" or "Book
                >  Whole"?
                It seems that the problem is not related to Journal vs Conference or something
                else, but rather to some kind of interaction between items.

                I have added a "minimal" test case that fails.

                Zotero is happy with the following page:
                http://beta.refbase.net/show.php?records=867

                Zotero is happy with this page also:
                http://beta.refbase.net/show.php?records=868

                Zotero complains about the following one:
                http://beta.refbase.net/show.php?records=867,868

                As all of this is far beyond my knowledge, I am sorry I cannot really help you more
                than that.

                Best,
                Tom

                 
            • refbase's COinS support pre-dates the existence of Zotero.  The Zotero COinS "translator" seems to have some things which, as far as I can tell, are mostly unique to their own implementation.

              See http://forums.zotero.org/discussion/2240/

              I haven't actively pursued implementing this, as Zotero is NOT the only tool that uses COinS in existence.  I do agree with Matthias that, if you want Zotero support & can run it, unAPI is the way to go.  I also agree that it makes sense to try to generate valid COinS for every item, even if Zotero does not support it.

              Zotero's own HTML export does not generate COinS for conference papers.  Wikipedia does, by exporting to book & using the genre tag:

              http://en.wikipedia.org/wiki/Template:Cite_conference

              I'm not opposed to emulating this--before refbase had explicit support for this type, I used the book whole or book chapter type for conferences anyway.

              > [*] However, I noticed that, for COinS import, Zotero seems to put the article's
              > first author last

              Since our COinS is quite explicit in saying who the first author is, I consider this to be a Zotero bug.  I haven't tried to replicate it yet & I'll have to look at it in the future, though.

              > Zotero complains about the following one:
              > http://beta.refbase.net/show.php?records=867,868

              An apparent unAPI issue that we'll also have to explore.  Removing the UnAPI, the COinS import fine.  Thanks for the example.

              The three records that cause your test page to fail are apparently:

              * Mosaicing of Confocal Microscopic In Vivo Soft Tissue Video Sequences Improves Multimodality Approach.

              * In Vivo Imaging of the Bronchial Wall Microstructure Using Fibered Confocal Fluorescence Microscopy.

              * Towards Optical Biopsies with an Integrated
              Fibered Confocal Fluorescence Microscope.

              All three have the author 'Cavé' and removing the '%E9' from these fixes them.  It also works if you replace %e9 with the unicode character.

              I think that it is preferred that COinS are URL-encoded & that refbase is doing the right thing.  Ideally, Zotero should accept both encoded and unencoded entities.  At the very least, it shouldn't fail when it encounters such an entity.

              --Rick

               
              • >  The three records that cause your test page to fail are apparently:

                >  * Mosaicing of Confocal Microscopic In Vivo Soft Tissue Video Sequences Improves
                >  Multimodality Approach.

                >  * In Vivo Imaging of the Bronchial Wall Microstructure Using Fibered Confocal
                >  Fluorescence Microscopy.

                >  * Towards Optical Biopsies with an Integrated
                >  Fibered Confocal Fluorescence Microscope.

                Thanks for pointing out the entries that cause the problem.

                >  All three have the author 'Cavé' and removing the '%E9' from these fixes them.
                >  It also works if you replace %e9 with the unicode character.

                Is there a php function I can call within my custom style file do convert the
                characters? Or should I change the items from the refbase interface?
                (But then silly question how do I enter type these characters in the web interface?)

                >  I think that it is preferred that COinS are URL-encoded & that refbase is doing
                >  the right thing.  Ideally, Zotero should accept both encoded and unencoded entities.
                >  At the very least, it shouldn't fail when it encounters such an entity.

                Indeed it would be better if zotero could simply skip these COinS...

                Tom

                 
                • > Is there a php function I can call within my custom style file do convert the
                  > characters? Or should I change the items from the refbase interface?

                  It is up to you.  If it were my site, I'd look into fixing Zotero (because I think refbase does the right thing).  If you want to work around them, you can:

                  (1) Strip out the urlencode function from the COinS generator
                  (2) use urldecode in your custom style
                  (3) convert to the latin character equivalent (either within the database or for just the COinS)

                  [1] is probably not the way to go, since I don't think we'd adopt this & you'd have to change it.

                  [2] would fix zotero, but may break other tools that attempt to make resolvable URLs

                  [3] is a hack.  It may actually work better with some OpenURL resolvers with latin databases.  But it will put this wrong character everywhere.

                  > (But then silly question how do I enter type these characters in the web
                  > interface?)

                  You are already entering the correct character into the database.  Per [3], you could replace that particular character with a mere 'e', but it does not seem ideal.

                  >>  I think that it is preferred that COinS are URL-encoded & that refbase is
                  > doing
                  >>  the right thing.  Ideally, Zotero should accept both encoded and unencoded
                  > entities.
                  >>  At the very least, it shouldn't fail when it encounters such an entity.
                  >
                  > Indeed it would be better if zotero could simply skip these COinS...

                  There really is no reason that Zotero should not be able to import them in the future.

                  --Rick

                   
                  • Ok I should have read twice before answering (I need some coffee).

                    I do understand your point now. The best options seems indeed to wait for a bug fix from zotero.

                    Thanks again,
                    Tom

                     
    • Hi Tom,

      > > [*] However, I noticed that, for COinS import, Zotero seems to
      > > put the article's first author last. This isn't a problem with
      > > records imported from List view via unAPI. Since unAPI is also
      > > richer in content (and data model), we should probably add unAPI
      > > links to citation output as well (and I can't remember why we
      > > haven't done so, maybe it was just an oversight?).
      >
      > I am just discovering these tools. Are you saying I should rather
      > use unAPI than COinS if I can.

      I meant that refbase should offer unAPI links in Cite view, besides COinS tags (as it currently does for List view). This would allow clients such as Zotero to choose whatever it finds appropriate.

      Theoretically, COinS is fine for journals, chapters and books, but is less suitable for other document types (since it has no support for these types built in). Also, COinS can't include the abstract of an article. unAPI is more flexible, and is supported by Zotero. You could try to include unAPI links in your custom Citation style instead of (or in addition to) COinS tags. However, refbase should really include unAPI links in Cite view by default. More info about unAPI use in refbase is available at:

      http://unapi.refbase.net/

      > Zotero complains about the following one:
      > http://beta.refbase.net/show.php?records=867,868

      I see the same as you do. However, it's strange that Zotero does in fact import the very same records fine when importing them from within Cite view.

      AFAIK, Zotero prefers import via unAPI if unAPI links are present. If not, it checks for the presence of COinS tags. But in this case (your two test records displayed together in refbase List view), Zotero does not seem to use unAPI at all (Zotero puts "unAPI" in the 'Repository' field if a record was imported via unAPI).

      I cannot tell why Zotero behaves differently here. One probably would need to step thru the Zotero code to understand this better.

      Matthias

       
      • >  I meant that refbase should offer unAPI links in Cite view, besides COinS tags
        >  (as it currently does for List view). This would allow clients such as Zotero
        >  to choose whatever it finds appropriate.

        >  Theoretically, COinS is fine for journals, chapters and books, but is less suitable
        >  for other document types (since it has no support for these types built in).
        >  Also, COinS can't include the abstract of an article. unAPI is more flexible,
        >  and is supported by Zotero. You could try to include unAPI links in your custom
        >  Citation style instead of (or in addition to) COinS tags. However, refbase should
        >  really include unAPI links in Cite view by default. More info about unAPI use
        >  in refbase is available at:
        http://unapi.refbase.net/

        Ok thanks for the information. As far as I understand it, I cannot use unAPI in my
        case because my refbase server is on an intranet and my citation is to be put on
        an external web page...

        If I get it correctly, since COinS is not really suitable for conference papers, it
        would be better to only include it for journals.

        Tom

         
        • > As far as I understand it, I cannot use unAPI in my case because
          > my refbase server is on an intranet and my citation is to be put
          > on an external web page...

          Yes, that's correct. I forgot about that, sorry. The only workaround would probably be to use another unAPI-aware server as intermediate (such as the one at http://refbase.org ). Keeping your records in sync would mean some extra work, though. This may get easier when we eventually have full support for cross-site searching & importing and/or two-way record synching.

          > If I get it correctly, since COinS is not really suitable for
          > conference papers, it would be better to only include it for
          > journals.

          I wouldn't say so. For COinS output, refbase uses the generic type "dc" (dublin core) for anything that's not a journal article, book or book chapter. This isn't wrong and should be better than not including any COinS tags. It's just not guaranteed if (and how) COinS-aware clients will process these tags.

          Matthias