These have to be named graphs, or at least collections of triples which 
can be processed through workflows as a single unit.

In terms of LD there version needs to be defined in terms of:

(a) synchronisation with the non-bibliographic real world (i.e. Dataset 
Z version X was released at time Y)

(b) correction/augmentation of other datasets (i.e Dataset F version G 
contains triples augmenting Dataset H versions A, B, C and D)

(c) mapping between datasets (i.e. Dataset I contains triples mapping 
between Dataset J version K and Dataset L version M (and visa-versa))

Note that a 'Dataset' here could be a bibliographic dataset (records of 
works, etc), a classification dataset (a version of the Dewey Decimal 
Scheme, a version of the Māori Subject Headings, a version of Dublin 
Core Scheme, etc), a dataset of real-world entities to do authority 
control against (a dbpedia dump, an organisational structure in an 
institution, etc), or some arbitrary mapping between some arbitrary 
combination of these.

Most of these are going to be managed and generated using current 
systems with processes that involve periodic dumps (or drops) of data 
(the dbpedia drops of wikipedia data are a good model here). git makes 
little sense for this kind of data.

github is most likely to be useful for smaller niche collaborative 
collections (probably no more than a million triples) mapping between 
the larger collections, and scripts for integrating the collections into 
a sane whole.

cheers
stuart

On 28/08/12 08:36, Karen Coyle wrote:
> Ed, Corey -
>
> I also assumed that Ed wasn't suggesting that we literally use github as
> our platform, but I do want to remind folks how far we are from having
> "people friendly" versioning software -- at least, none that I have seen
> has felt "intuitive." The features of git are great, and people have
> built interfaces to it, but as Galen's question brings forth, the very
> *idea* of versioning doesn't exist in library data processing, even
> though having central-system based versions of MARC records (with a
> single time line) is at least conceptually simple.
>
> Therefore it seems to me that first we have to define what a version
> would be, both in terms of data but also in terms of the mind set and
> work flow of the cataloging process. How will people *understand*
> versions in the context of their work? What do they need in order to
> evaluate different versions? And that leads to my second question: what
> is a version in LD space? Triples are just triples - you can add them or
> delete them but I don't know of a way that you can version them, since
> each has an independent T-space existence. So, are we talking about
> named graphs?
>
> I think this should be a high priority activity around the "new
> bibliographic framework" planning because, as we have seen with MARC,
> the idea of versioning needs to be part of the very design or it won't
> happen.
>
> kc
>
> On 8/27/12 11:20 AM, Ed Summers wrote:
>> On Mon, Aug 27, 2012 at 1:33 PM, Corey A Harper <[log in to unmask]>
>> wrote:
>>> 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.
>> Yes, I wasn't saying that we could just plonk our data into Github,
>> and pat ourselves on the back for a good days work :-) I guess I was
>> stating the obvious: technologies like Git have made once hard
>> problems like decentralized version control much, much easier...and
>> there might be some giants shoulders to stand on.
>>
>> //Ed
>


-- 
Stuart Yeates
Library Technology Services http://www.victoria.ac.nz/library/