W3C home > Mailing lists > Public > public-lld@w3.org > April 2011

Re: Recommendation: Plan for migration

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Fri, 29 Apr 2011 09:27:42 -0700
Message-ID: <20110429092742.11196jomswavjxfi@kcoyle.net>
To: Emmanuelle Bermes <manue@figoblog.org>
Cc: public-lld <public-lld@w3.org>
I started doodling some diagrams of flows for the various steps  
(because that's how I think about things) and immediately ran into  
what seem to me to be huge issues.

If you are going to translate from a current library database to LD,  
you have the issue of assigned URIs to things that do not already have  
them. I'm going to use LCSH as an example. LC has assigned URIs to  
some headings and some "heading fragments" but much of what is in  
library data today does not have an identified equivalent in LCSH.  
Therefore the library will have to mint a URI as it translates the  
record. That in itself is not a problem.

The problem comes about with updates. Since the local database is not  
storing URIs, when a record is updated and must be re-translated,  
there is no easy way to re-capture the minted URI for the re-translate  
process. (I wonder what XC does in its iterative processes? Anyone  
know?)

This isn't insurmountable, but it does complicate things. In the end,  
it seems to me that the translate method will be difficult to maintain.

kc


Quoting Emmanuelle Bermes <manue@figoblog.org>:

> Such a plan could also involve 2 steps :
>
> Step 1. publish at least part of the data as Linked Data, without
> challenging the data production process
> Step 2. migrate all the data production process to LD technologies.
>
> The first step is quite straightforward & easy to accomplish.
> Do you think no plan is needed for this first step ? In that case, the
> plan you describe would be aimed only at achieving the complete
> migration. It needs to be explicit, though.
>
> Emma
>
>
>
> On Thu, Apr 28, 2011 at 11:33 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>> (You've probably noticed that these recommendations are not in any
>> particular order. I'm sending them out as we feel they have been
>> sufficiently worked over by the group.)
>>
>> ****
>>
>> Plan for migration to LLD: technical, managerial, and intellectual
>>
>> A migration to Linked Data for library and cultural heritage metadata will
>> likely be a lengthy and highly distributed effort. The length of time to
>> perform the migration will be large because of the number of activities:
>> emergence of best practices for LLD, creation and adoption of new software,
>> consensus on global identifiers and deduplication strategies, and so forth.
>> A plan must be drawn up that stages activities in ways that allow innovators
>> to participate sooner while paving the path for the late majority adopters
>> to make use of the work later. Adoption of the plan would also reduce
>> duplication of effort as the community moves from a self-contained,
>> record-based approach to a worldwide graph approach for bibliographic data.
>>
>> One question to be addressed in a plan is whether conversion can be done in
>> managed stages. For instance: First create globally unique URIs for each
>> record. Then, if necessary, automatically create WEMI URIs for each record.
>> Next, "map" attributes/fields to existing properties (or create appropriate
>> new ones). Lastly, "map" object values to existing URIs where appropriate,
>> etc.
>>
>> Another possible path is a pure MARC ontology to create linked data from
>> legacy records without thinking about linked data. That is, a very
>> preliminary, high-level map that produces triples like <my:RecordID>
>> <marc:100a> <"Jefferson, Thomas, 1743-1826"> without any attempt to
>> substitute an existing URI for the predicate or object. This would help very
>> large scale data dumps that others could subsequently work on.
>>
>> Each of these plans has costs and benefits that should be studied and
>> understood as part of the transition to linked data, taking into account the
>> investment that libraries have in their current systems and economic
>> factors.
>>
>> --
>> Karen Coyle
>> kcoyle@kcoyle.net http://kcoyle.net
>> ph: 1-510-540-7596
>> m: 1-510-435-8234
>> skype: kcoylenet
>>
>>
>>
>



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Received on Friday, 29 April 2011 16:28:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 29 April 2011 16:28:13 GMT