Re: Recommendation: Plan for migration

I'm tempted to say that updates/re-translations are somewhat out-of-scope except to mention them as an issue.  A system that performs the translation that you describe will likely need some sort of "super" record in its internal system to track the URIs assigned to parts of the MARC record.  The reason it would be out-of-scope for us is because that "super record" does not need to be transmitted or shared; it is something unique to whatever system is doing the translation and the internal processes it uses to do that translation.


Peter


On Apr 29, 2011, at 12:27 PM, Karen Coyle wrote:
> 
> 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.

-- 
Peter Murray         Peter.Murray@lyrasis.org        tel:+1-678-235-2955                 
Ass't Director, Technology Services Development   http://dltj.org/about/
Lyrasis   --    Great Libraries. Strong Communities. Innovative Answers.
The Disruptive Library Technology Jester                http://dltj.org/ 
Attrib-Noncomm-Share   http://creativecommons.org/licenses/by-nc-sa/2.5/ 

Received on Monday, 2 May 2011 18:00:25 UTC