Re: Next Recommendation: Costs

Thinking about this...

I haven't had time to look at the latest version of the 'benefits' but
presumably this is complimentary to the 'costs'?
I think that the benefits of expressing 'traditional' library data as LD is
more than just discovery (and indeed, many 'discovery' benefits might be
realised without doing full LD representations) - so aspects of data re-use,
machine processable data etc. is part of this.

It might be worth exploring this question of native vs converted LD further.
I'm thinking there are probably different sets of costs. Doing basic LD
representations from MARC should be straightforward once a few have
trail-blazed and shared conversion routines etc.? However, cost of matching
entities etc is high.

Some of these costs go away when you create library data natively as LD -
but the associated costs of doing this feel v high (redeveloping systems to
cope etc.!)

Owen

On Wed, Apr 27, 2011 at 3:50 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:

> Owen, good point. So perhaps there needs to be something about discovery
> services ... and moving library data initially onto the SemWeb for
> discovery?
>
> The trick that I see to the idea that LD will be built on top of current
> systems (which I agree is likely to be the first step) is the question of
> how truly useful LD will be created if we continue to create MARC records in
> our systems. MARC can't handle any of the WEMI relationships ("is
> translation of") and so these would have to be coded outside of the library
> cataloging systems. This implies that we will actually be re-creating our
> data in an LD space, something that many will see as duplicate work.
>
> kc
>
>
> Quoting Owen Stephens <owen@ostephens.com>:
>
>  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
>>
>>
>
>
> --
> 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