Karen,

I think there's a useful distinction here. Ed can correct me if I'm
wrong, but I suspect he was not actually suggesting that Git itself be
the user-interface to a github-for-data type service, but rather that
such a service can be built *on top* of an infrastructure component
like GitHub.

I agree that there's a barrier to use if we just plunk a bunch of our
bib data in GitHub and call it done, but the version control model and
implementation there could definitely provide a good bit of the
library-version-control stack down below the UI layer.

Cheers,
-Corey

On Mon, Aug 27, 2012 at 8:49 AM, Karen Coyle <[log in to unmask]> wrote:
> Actually, Ed, this would not only make for a good blog post (please, so it
> doesn't get lost in email space), but I would love to see a discussion of
> what kind of revision control would work:
>
> 1) for libraries (git is gawdawful nerdy)
> 2) for linked data
>
> kc
> p.s. the Ramsay book is now showing on Open Library, and the subtitle is
> correct... perhaps because the record is from the LC MARC service :-)
> http://openlibrary.org/works/OL16528530W/Reading_machines
>
>
> On 8/26/12 6:32 PM, Ed Summers wrote:
>>
>> Thanks for sharing this bit of detective work. I noticed something
>> similar fairly recently myself [1], but didn't discover as plausible
>> of a scenario for what had happened as you did. I imagine others have
>> noticed this network effect before as well.
>>
>> On Tue, Aug 21, 2012 at 11:42 AM, Lars Aronsson <[log in to unmask]> wrote:
>>>
>>> And sure enough, there it is,
>>> http://clio.cul.columbia.edu:7018/vwebv/holdingsInfo?bibId=1439352
>>> But will my error report to Worldcat find its way back
>>> to CLIO? Or if I report the error to Columbia University,
>>> will the correction propagate to Google, Hathi and Worldcat?
>>> (Columbia asks me for a student ID when I want to give
>>> feedback, so that removes this option for me.)
>>
>> I realize this probably will sound flippant (or overly grandiose), but
>> innovating solutions to this problem, where there isn't necessarily
>> one metadata master that everyone is slaved to seems to be one of the
>> more important and interesting problems that our sector faces.
>>
>> When Columbia University can become the source of a bibliographic
>> record for Google Books, HathiTrust and OpenLibrary, etc how does this
>> change the hub and spoke workflows (with OCLC as the hub) that we are
>> more familiar with? I think this topic is what's at the heart of the
>> discussions about a "github-for-data" [2,3], since decentralized
>> version control systems [4] allow for the evolution of more organic,
>> push/pull, multimaster workflows...and platforms like Github make them
>> socially feasible, easy and fun.
>>
>> I also think Linked Library Data, where bibliographic descriptions are
>> REST enabled Web resources identified with URLs, and patterns such as
>> webhooks [5] make it easy to trigger update events could be part of an
>> answer. Feed technologies like Atom, RSS and the work being done on
>> ResourceSync also seem important technologies for us to use to allow
>> people to poll for changes [6]. And being able to say where you have
>> obtained data from, possibly using something like the W3C Provenance
>> vocabulary [7] also seems like an important part of the puzzle.
>>
>> I'm sure there are other (and perhaps better) creative analogies or
>> tools that could help solve this problem. I think you're probably
>> right that we are starting to see the errors more now that more
>> library data is becoming part of the visible Web via projects like
>> GoogleBooks, HathiTrust, OpenLibrary and other enterprising libraries
>> that design their catalogs to be crawlable and indexable by search
>> engines.
>>
>> But I think it's more fun to think about (and hack on) what grassroots
>> things we could be doing to help these new bibliographic data
>> workflows to grow and flourish than to get piled under by the errors,
>> and a sense of futility...
>>
>> Or it might make for a good article or dissertation topic :-)
>>
>> //Ed
>>
>> [1] http://inkdroid.org/journal/2011/12/25/genealogy-of-a-typo/
>> [2] http://www.informationdiet.com/blog/read/we-need-a-github-for-data
>> [3] http://sunlightlabs.com/blog/2010/we-dont-need-a-github-for-data/
>> [4] http://en.wikipedia.org/wiki/Distributed_revision_control
>> [5] https://help.github.com/articles/post-receive-hooks
>> [6] http://www.niso.org/workrooms/resourcesync/
>> [7] http://www.w3.org/TR/prov-primer/
>
>
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet



-- 
Corey A Harper
Metadata Services Librarian
New York University Libraries
20 Cooper Square, 3rd Floor
New York, NY 10003-7112
212.998.2479
[log in to unmask]