Re: Next Recommendation: Costs

Owen, it sounds to me like you have outlined some of the issues that  
need to go into a cost/benefit analysis!

I'll see if I can get this into the wording on the recommendations  
page without it getting to be too specific or too long.

kc

Quoting Owen Stephens <owen@ostephens.com>:

> 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
>



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Wednesday, 27 April 2011 16:56:55 UTC