- From: Owen Stephens <owen@ostephens.com>
- Date: Tue, 3 May 2011 10:50:36 +0100
- To: Jodi Schneider <jodi.schneider@deri.org>
- Cc: Karen Coyle <kcoyle@kcoyle.net>, Emmanuelle Bermes <manue@figoblog.org>, public-lld <public-lld@w3.org>
I like the term 'translation' - this is definitely how I'd describe the activity we've undertaken in Lucero in representing bibliographic records as LD - and chimes with the three points outlined by Jodi Owen Owen Stephens Owen Stephens Consulting Web: http://www.ostephens.com Email: owen@ostephens.com Telephone: 0121 288 6936 On 29 Apr 2011, at 18:03, Jodi Schneider wrote: > I was not thinking that you would intentionally do the same translation multiple times -- just that the perspective of "translation" makes clear that > (a) there are multiple approaches > (b) some approaches may be more or less suitable for certain outcomes/intended uses (i.e. there may not be one "best") > (c) there may be differences in the richness/paucity of expression; translations will have to mitigate this to function as intended > > In the example you describe, an intermediate database which *does* store the URIs would be expected. > > -Jodi > > On 29 Apr 2011, at 17:27, 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. >>>> >>>> -- >>>> 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 Tuesday, 3 May 2011 09:51:08 UTC