- 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