Print

Print


It's still a LOT better than COinS for Zotero, I assume though. I'd like 
there to be better documentation to encourage more people to use unAPI 
instead of COinS; even the limited Zotero documentation there is admits 
that COinS is pretty limited.

Jonathan

Bill Dueber wrote:
> The unAPI support is also...non-ideal...in that you can't present
> preferences for the best format to use. For example, the Refworks
> Tagged format just plain has more tags (and hence more or
> more-finely-grained information) than other formats (e.g., Endnote),
> but Zotero will prefer Endnote just because it does. My RIS output is
> better than my endnote output, but there's no way for me to tell
> Zotero that.  For Mirlyn I ended up just having exactly one format
> listed in my unapi-server file. Which is dumb. But I'm not sure what
> else to do.
>
> On Tue, Apr 6, 2010 at 10:16 AM, Jonathan Rochkind <[log in to unmask]> wrote:
>   
>> Yeah, we need some actual documentation on Zotero's use of unAPI in general.
>> Maybe if I can figure it out (perhaps by asking the developer(s)) I'll write
>> some for them.
>>
>> Robert Forkel wrote:
>>     
>>> well, looks like a combination:
>>> in case of mods it checks for the namespace URL, in case of rdf, it
>>> looks for a format name of rdf_dc, ...
>>> and yes, endnote export would have to have a name of "endnote" (i ran
>>> into this problem as well with names like endnote-utf-8, ...). i think
>>> unapi would be more usable if there were at least a recommendation of
>>> common format names.
>>>
>>> On Tue, Apr 6, 2010 at 4:07 PM, Jonathan Rochkind <[log in to unmask]>
>>> wrote:
>>>
>>>       
>>>> Wait, does it actually recognize the format by the format _name_ used,
>>>> and
>>>> not by a mime content-type?  Like unless my unAPI server calls the
>>>> endnote
>>>> format "endnote", it won't recognize it?  That would be odd, and good to
>>>> know. I thought the unAPI format names were purely arbitrary, but
>>>> recognized
>>>> by their association with a mime content-type like "application/x-
>>>> /endnote/-refer".   But no, at least as far as Zotero is concerned, you
>>>> have
>>>> to pick format shortnames that match what Zotero expects?
>>>>
>>>>
>>>> Robert Forkel wrote:
>>>>
>>>>         
>>>>> from looking at line 14 here
>>>>> https://www.zotero.org/trac/browser/extension/trunk/translators/unAPI.js
>>>>> i'd say:
>>>>> ad 1. RECOGNIZABLE_FORMATS = ["mods", "marc", "endnote", "ris",
>>>>> "bibtex", "rdf"] also see function checkFormats
>>>>> ad 2. the order listed above
>>>>> ad 4.: from my experience the unapi scraper takes precedence over coins
>>>>>
>>>>> On Tue, Apr 6, 2010 at 3:48 PM, Jonathan Rochkind <[log in to unmask]>
>>>>> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Anyone know if there's any developer documentation for Zotero on it's
>>>>>> use
>>>>>> of
>>>>>> unAPI?  Alternately, anyone know where I can find the answers to these
>>>>>> questions, or know the answers to these questions themselves?
>>>>>>
>>>>>> 1. What formats will Zotero use via unAPI. What mime content-types does
>>>>>> it
>>>>>> use to recognize those formats (sometimes a format has several in use,
>>>>>> or
>>>>>> no
>>>>>> official content-type).
>>>>>>
>>>>>> 2. What is Zotero's order of preference when multiple formats via unAPI
>>>>>> are
>>>>>> available?
>>>>>>
>>>>>> 3. Will Zotero get confused if different documents on the page have
>>>>>> different formats available?  This can be described with unAPI, but it
>>>>>> seems
>>>>>> atypical, so not sure if it will confuse Zotero.
>>>>>>
>>>>>> 4. If both unAPI and COinS are on a given page -- will Zotero use both
>>>>>> (resulting in possible double-import for citations exposed both ways).
>>>>>> Or
>>>>>> only one? Or depends on how you set up the HTML?
>>>>>>
>>>>>> 5. Somewhere that now I can't find I saw a mention of a "Zotero RDF"
>>>>>> format
>>>>>> that Zotero would consume via unAPI. Is there any documentation of this
>>>>>> format/vocabulary, how can I find out how to write it?
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>           
>>>       
>
>
>
>