- From: Thomas Baker <tbaker@tbaker.de>
- Date: Wed, 16 Feb 2011 10:56:50 -0500
- To: public-xg-lld <public-xg-lld@w3.org>
Dear all, Thursday will be our 29th telecon, with 14 more remaining in the charter period for the LLD XG. We have passed the two-thirds mark...! As discussed in last week's call, we are obliged -- or rather compelled by time constraints -- to focus now on the final report. Starting from the use-case clusters -- the core substance of our work to date -- we need to work outwards to an analysis of: -- benefits -- problems and limitations ("costs") -- recommendations ("next steps") Writing an executive summary (the "elevator pitch") will be the very last step. As I expected, transcluding all of the separate documents into one big document [1] -- thank you, Jodi! -- results in a rambling text 36 pages long, with much too much detail, too many bullet points, too little readable narrative text, and no text at all on crucial elevator-pitch issues. Reviewers are needed now to look at this rambling manuscript from several perspectives, outlined below, and to propose how the material at hand should be moved or reused. As it stands, roughly half of the active XG members have participated in authoring text, and half have participated though not as authors. In order to share the burden and increase the number of eyeballs focused on the text, it would be great if those of you who have not authored sections would consider putting their names in Thursday's call to one of the eight topics listed below. If you would like to claim a section but cannot attend Thursday's call, please drop me a line. This message completes our joint action: ACTION: Antoine, Emma, TomB to send a call for reviewers to the list [recorded in http://www.w3.org/2005/Incubator/lld/minutes/2011/02/10-lld-minutes.html#action14] The first quarter of Thursday's call will be reserved for discussion with Jon Voss; the rest for assigning names to the eight reviewing tasks listed below. Tom [1] http://www.w3.org/2005/Incubator/lld/wiki/DraftReportWithTransclusion [2] http://www.w3.org/2005/Incubator/lld/wiki/DraftReport [3] http://www.w3.org/2005/Incubator/lld/wiki/DraftReportWithTransclusion#International_Cataloging_Rules [4] http://www.w3.org/2005/Incubator/lld/wiki/Library_standards_and_linked_data [5] http://www.w3.org/2005/Incubator/lld/wiki/DraftReportAppendix @@@@ to be created ---------------------------------------------------------------------- We need reviewers for the following issues: 1) What to do with the use cases themselves. In the cluster texts, summaries of case-study "scenarios" are an important intermediate step between the raw use cases and the "extracted use cases" (synthetic summaries). Should these intermediate analyses find their way into the final report? For example, should there be a section in the appendix with a one-sentence summary of each use case, with links both to the original source and to the (to-be-frozen) use-case description in the wiki, followed by bullet points extracted from the cluster analyses? 2) How to characterize the "datasets". According the current outline, datasets are supposed to be handled in sub-section 1.4.2. of the section "available data". The reviewer for this section should propose a short text describing CKAN and its processes. Should we bother trying to list datasets in the Appendix, knowing that the list will already be obsolete at the time of publication? The answer to this question should perhaps depend on what we do with the use-case summaries (review #1). 3) How to charaterize the "vocabularies". As in #2, vocabularies are currently penciled in as section 1.4.1. under "available data". The use-case clusters list vocabularies used. Should these lists be consolidated into one long, annotated list? And should that list be included in the body of the report or relegated to an appendix and summarized in the body of the report? What sorts of observations or conclusions about vocabularies derived from the cluster analyses would be appropriate to include in the body of the report? 4) Where to fit Gordon's analysis of library standards (starting at [3]). Should the discussion and update on ISBD, FR, RDA, AACR, MARC, etc be summarized in the body of the report, and if so, where? It would seem to belong in the section describing available vocabularies and data sources, but in that case, should the section be called "available data" or something more inclusive, such as "the Ingredients of Library Linked Data" (I hesitate to call them "elements" :-)? Would the introduction to this section be the place to include our hard-won and useful pragmatic distinctions between Element Sets, Value Vocabularies, and Datasets? Or are these discussions of recent developments too detailed for the body of the report and best handled in an appendix? 5) Getting a start on Problems and Limitations (section 1.5). This reviewer should read the use-case clusters from the perspective of problems and limitations and propose how to merge the scattered observations into a coherent section. One very important wiki page overlooked in the current transcluded draft is Gordon's analysis Library_standards_and_linked_data [4]. 6) How to handle "relevant technologies". Use-case cluster analyses list them. Do we want to present a consolidated list? In the body of the report or in an appendix? What would be the point of a section specifically about relevant technologies; do we need one? How would it relate to the section on Problems and Limitations? 7) Extracting the "benefits". The reviewer should read through the entire draft and synthesize a first-draft high-level list of benefits from using a Linked Data approach. 8) Curating the Appendix. It is clear that alot of the detail should be relegated to an Appendix. Someone should take ownership of the Appendix, creating [5] and devising for it a structure, such as: -- List of annotated use cases. -- List of annotated vocabularies -- List of annotated technologies used (if so concluded on the basis of review #6). -- List of use cases, briefly described and characterized, or a longer list of datasets based on CKAN. We may decide that individual sections of the appendix need separate curators; the job of the Appendix curator will simply be to get this section outlined and started. -- Tom Baker <tbaker@tbaker.de>
Received on Wednesday, 16 February 2011 15:57:30 UTC