Fwd: W3C Library Linked Data XG - request for review

Some additional comments on the report.

Thanks a lot for this, Jonathan, that's much appreciated. We'll come back to you on this in the coming weeks!


---------- Forwarded message ----------
From: Jonathan Rees <jar@creativecommons.org>
Date: Fri, Jul 29, 2011 at 4:10 PM
Subject: Re: W3C Library Linked Data XG - request for review
To: Thomas Baker <tom@tombaker.org>

Some thoughts on the report (which you can relay)

- It's not clear who the audience is (I realize this was a TBD). It
reads a bit as if it's the XG talking to those who are already sold on
the idea of LD for libraries. The report *I* would like to see is more
ambitious - it would be written for conservative library IT directors
who may be skeptical of linked data.

- The 'scope' section is not related to benefits so should be put separate

- Every benefit of *any* technology comes with some cost. So the
'benefits' section IMO ought to be a 'value proposition' section -
what benefits do you get, at what cost. I know this is covered later,
so maybe 'benefits' should be shortened and turned into an
introduction, with a promise of more depth later on.

- The benefits section is too gung-ho for my taste, e.g. the use of
the word 'significant' with no justification. It also does not provide
a comparison or null model. If you do LD you're not doing something
else. Are the alternatives (including doing nothing, using XML or jSON
or SOAP, etc) just as good? Why not?

- You could do some of the cheerleading by reference to other
documents that promote LD, thus saving space here

- The whole social issue is ignored in the benefits section. Using
someone else's linked data is a liability (cost): they might go
offline, or they might decide to change the format. Unless you have a
contract of some kind there is no protection against these. Similarly,
if you make a promise to the community around uptime, updates, or
stability, that is a liability to your organization. So LD in the long
run, as part of infrastructure design, can have a huge cost due to its
social fragility. To recover this cost requires fame or thank-you
notes or citations that you can bring to your trustees, or fee for

Cost of coordination is also ignored. Sure, one can unilaterally do
RDF design and publish, but this can lead to lost opportunities if
it's not exactly what a partner needs, or if it's incompatible with
information coming from a similar but independent source. Without
coordination, RDF really gives little benefit over XML.

These are things that library administrators need to know. By being
skeptical and transparent yourself, you'll gain credibility.

On the other hand LD for one-off projects is a great thing.

- what does 'a.o.' stand for?

- 'an sign'

- Section on bulk access should mention the value of doing joins,
which only work well when you've done a bulk load into some kind of
query engine (triple store, etc).

- In 'front ends' where XSLT is mentioned you might want to mention
GRDDL (although I don't know whether it's used)

- I'm not sure the microdata discussion is in scope, esp. given that
microdata is nowhere close to Rec status... there's nothing here
specific to libraries

- need reference for 'resource oriented architecture'

- Is Drupal your only example of a CMS?  Would be nice to at least
mention a 2nd one.

- Re 'web services for LLD', why would you *want* to refactor API
capabilities using the LD stack?  You're assuming too much knowledge
on the part of the reader

- The whole section 'implementation challenges and barriers to
adoption' comes off as a criticism of library culture: "resists
change"... "out of step"... "understaffed"... "do not adapt".  This is
unnecessary and seems like biting the hand that feeds you. It's
possibly even alienating and counterproductive. Yes, we know that
libraries are endangered, and that this is partly because they haven't
found their place on the web, partly because they don't innovate, and
so on. But libraries have good reasons to be conservative and these
have to be respected. You're proposing an innovation that *has a cost*
that you don't acknowledge. You have to show that compared to the null
hypothesis (status quo) the benefit will outweigh the cost.

So please rephrase in positive terms. LD "can reduce the cost of
innovation"... "create new economies"... "help make better use of
scarce staff"... "help libraries take advantage of new technological
opportunities"... and so on. This section should again be about costs
and benefits: what will libraries need to do, *if* they choose to go
down this path. They would need to broaden the set of vendors they
work with, train staff, interact with other communities, etc. Costs +
benefits in each case. Overall, the goal is to help to enable informed

If LLD is worthwhile, then ways will be found to use it. If not, then
it *shouldn't* be adopted.

How this is written depends of course on the audience. If the audience
is people who have already decided they want to do LD, and the idea is
to help them push it through their organizations, that's a different
pitch. But as I said what I think you want is a document aimed at the
skeptical but open-minded reader.

- 'web communities' - I don't think there's any such thing; please specify

- The discussion of bottom-up standards needs some explanation.
Definition and examples. I don't really understand why you'd say HTML5
isn't bottom-up; most of what's in it has originated with some single
browser ("bottom") and then gone "up". I think you're trying to say
that bottom-up is the norm for RDF (with a few exceptions such as
RDFS), for some definition of bottom-up.

- "Library standards are limited" - examples would help people like me
who are not immersed.

- ROI - you're trying to talk about costs of the status quo separately
from its benefit and from the costs and benefits of LD. I think this
will in the end mean you are talking about the same issues in multiple
separated sections of the document. I would prefer a structure more
like the following: for each issue, explain what problem is to be
solved, how it is solved by the status quo (how successfully and at
what cost), and how it is solved using linked data (how successfully
and at what cost).

- Re data rights issues, these are important enough that I think they
should be summarized in your report, even if you have a citation to a
more comprehensive document. (Factual information not protected in US,
sui generis database rights in Europe, etc.)

- "Cultivate an ethos of innovation" - again you're somehow assuming
that an organization's scarce innovation dollars should go to LD
instead of to something else. That this argument has to be made,
should be admitted.

- "Assign unique identifiers" - you're glossing the issue of cost and
responsibility here. We tried to address this in life sciences with
the shared names project, which has yet to kick in due to lack of
attention and funding. This is really hard because maintenance of URIs
in perpetuity is both difficult to understand and a hot potato.

- The problem of domain name loss and/or loss of service for a domain
name is touched on, and that's good. Backup copies are great, but then
tools need to be able to get at them after the primary is lost. It's
probably too early to specify just how this should happen (XML
catalogs? Memento?) but the problem needs to be acknowledged as
something we'll have to face (and pay for) in the future.


On Tue, Jun 7, 2011 at 4:28 AM, Thomas Baker <tom@tombaker.org> wrote:
> Dear Jonathan,
> We are contacting you as a member of the W3C Library Linked Data Incubator
> Group (LLD XG) to request your help in reviewing the draft deliverables of the
> XG, which need to be published in final form by the end of August.
> Specifically, we would appreciate if you could read a three-page section of the
> report called "Benefits of the Linked Data Approach" [1].  Getting the
> arguments in this section of the report right will be key to the success of the
> deliverable as a whole.  You can see the section in the context of the draft
> report as a whole at [2].
> It would be very helpful to the work of the group if you could post comments to
> the public-lld mailing list [3] -- if possible by Monday, 20 June.  If you are
> able to do this, please drop us a line so that we can plan accordingly (or find
> an alternative reviewer).  If you have additional or alternative reviewers to
> suggest, please let us know!
> We want to ensure that the deliverables reflect the rough consensus of the XG
> members as a whole, so any input you could offer at this stage would be most
> valuable.
> Many thanks and best regards,
> Tom Baker, Antoine Isaac, Emmanuelle Bermes
> Co-Chairs, W3C Library Linked Data Incubator Group
> [1] http://www.w3.org/2005/Incubator/lld/wiki/Benefits#Benefits_of_the_Linked_Data_approach
> [2] http://www.w3.org/2005/Incubator/lld/wiki/DraftReportWithTransclusion#Benefits
> [3] http://lists.w3.org/Archives/Public/public-lld/
> --
> Tom Baker <tom@tombaker.org>

Received on Saturday, 30 July 2011 08:10:40 UTC