Re: Next Recommendation: Costs

I don't have an issue with what is proposed here, but it feels like it
addresses the most extreme vision of library adopting linked data practices
- that is baking LD into library data at a low level in terms of metadata
practices.

However, most of the activity I'm aware of with LLD is taking existing
library data and expressing it as LD. I feel that there should be an
analysis of the cost/benefit of this approach as well - winning the argument
'start creating library data as linked data' feels too hard to win outright
and it may be a matter of justifying some incremental steps first?

Owen

On Tue, Apr 26, 2011 at 6:32 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:

> The recommendations are broken into three major sections, one of which
> speaks to management actions that are needed. Of these, the first addresses
> costs and return on investment. The group felt that without some kind of
> cost benefit, it would be hard to make a good case for LLD. At the same
> time, we don't really have a good grasp of what our current practices cost
> us. Thuus:
>
> *Identify costs of current practices, and costs and ROI to moving of LLD*
>
> There must be some measurement of the relative costs of current library
> data practices and the potential of Linked Data to aid in making decisions
> about the future of library data. There are various areas of library
> metadata practices that could be studied, either separately or together.
> Among these are:
>
>    * The relative costs of the Record v. statement approach: for editing by
> humans, as full record replacement in systems, and the capabilities for
> sharing
>    * The use of text versus identifiers approach has costs: actual records
> must change when displays change (Cookery to Cooking); international
> cooperation requires extensive language mapping processes; some needed data
> elements must be extracted from textual field using algorithms, which also
> hinders sharing; and some library data formats require catalogers to
> duplicate information in the record, providing both textual fields and coded
> data for same information.
>
> ---
>
> Again, comments, suggestions, alternate ideas are all welcome.
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
>
>


-- 
Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: owen@ostephens.com