The way I'd think about it and approach it, adding the outside list
would be a lot easier with the API. But different developers in
different environments may find different things easier. They should
both be provided (I believe neither are right now).
I'd find it easier with an API, because you really only need the
_complete_ list at point of assignment. When a user is considering
adding a tag, you want to auto-complete or otherwise let them see the
FAST tags as options. An API is perfect for this, and much easier than
downloading the complete file, indexing it in a local system, and
keeping procedures to keep it up to date with any changes.
After they've assigned a tag, it of course goes into your database. But
when letting people explore your corpus with tags, you just need the
tags that actually ARE assigned in your database (which have to be there
neccesarily already), not the complete list of all possible FAST (the
ones that are not assigned in your corpus dont' matter for browsing,
although certainly matter for assigning new tags).
On 11/6/2012 12:50 PM, Karen Coyle wrote:
> On 11/6/12 8:25 AM, Jonathan Rochkind wrote:
>>
>> I think that's a great idea. It would be easy to implement if OCLC
>> would provide an API for looking up FAST headings. I believe right now
>> they only have such an API in a non-production 'research' service.
>
> I was just on a con call with someone whose view is that a downloadable
> file is key to providing pull-down lists in systems. Many systems do
> auto-complete based on their current pool of tags. Adding an outside
> list would be easier with a file dump - no? Which doesn't negate the
> need for an API, of course.
>
> kc
>
>>
>> Without that API, it makes it much more expensive to implement a
>> usable interface for the 'crowd' to 'tag' (ie 'catalog'!) with FAST
>> terms.
>>
>> FAST could be a really great resource, but it needs a bit more
>> centralized infrastructural support from someone, to have any chance
>> of realizing it's promise.
>
Received on Tue Nov 06 2012 - 14:00:49 EST