Re: Versioning system for ontologies

Putting a zip file of text data in a Git repository is a particularly bad thing to do.

Git has very strong text diff tracking.  With properly formatted text data, this can be leveraged to do semantic interpretation. 
While it is probably better to do this in a more targeted way, there is some merit to layering on a very efficient system like 
git.  VersionIRIs could be mapped to git changesets through some mechanism, for instance.  Or to branches which would allow for 
updates without requiring bump of the versionIRI.

The git backend is distinct from the git client and how it is mapped to files.  At the core, git is a transactional changeset 
database that has integral support for branches, versioning, and dependency tracking.  A number of custom uses for this have 
been developed that use a standard git server but do something other than simple file handling on the client side.

bup is one example: https://github.com/apenwarr/bup

Considering git-as-database directly:
http://lanyrd.com/2012/devslovebacon/srfpx/
Mentions: madrox, gollum, gaskit.

https://github.com/gollum/gollum

Not necessarily what I would recommend long-term for ontologies or other semantic data, but a possible area to explore.

As one thought experiment, what if every definition were in a separate file (or "file")?  Or stored on a single, separate line, 
thereby making the cleanest use of text versioning?

Stephen

On 4/19/13 11:13 AM, Bernard Vatant wrote:
> Hi all
>
> +1 with Alan on this. Some quick figures to show that his recommandations are much needed ...
> Quick query on LOV aggregator database http://bit.ly/12sUtDA
> ... yields exactly 9 vocabularies (out of more than 300) using owl:versionIRI and optional owl:priorVersion
>
> There is room for improvement, clearly ...
>
> Regarding generalization of Github for maintaining ontologies. I must say I don't like it too much (but maybe because I'm not 
> used to Github otherwise), the main drawback I have found along my task of LOV curator is that it can lead to forget the 
> basics, as Alan points rightly, to begin by having the current version available directly from its URI, and not hidden 
> somewhere in a zip in some directory of Github, as seen too often.
>
> Actually using Github tends to make consider ontology management as similar to software management. There are important 
> differences, and URI (IRI) management and persistance not the least!
>
> Cheers
>
> Bernard
>
> PS : As far as I am concerned for small ontologies such as the ones I maintain at lingvoj.org <http://lingvoj.org>, I'm 
> totally happy with
> a good text editor and Turtle, plus online services for validation [1], sanity checking of namespaces [2] and even publication 
> [3].
> But I'm lazy :)
>
> [1] http://www.rdfabout.com/demo/validator/ , http://www.w3.org/RDF/Validator/
> [2] http://graphite.ecs.soton.ac.uk/checker/
> [3] http://ontorule-project.eu/parrot/parrot
>
>
>
>
>
>
> 2013/4/19 Alan Ruttenberg <alanruttenberg@gmail.com <mailto:alanruttenberg@gmail.com>>
>
>     Don't forget about OWL's versionIRI, which gives a way to express that different versions are of a single ontology. The
>     most basic version control is to periodically save a file, put it at a location, and make the versionIRI point to it. Keep
>     the ontologyIRI the same thoughtout. Use import with the version you care load. At the ontologyIRI put either the most
>     recent version or the most recent version you release.
>
>     There is no need for additional repository infrastructure, though that may add useful features. Whatever you do, make sure
>     that at a minimum you version using vanilla specifications, given that they can support that.
>
>     I generally recommend you do not change IRIs of terms as you change versions. Rather,  try to ensure that the referents of
>     your URIs refer to the same intended entities, and obsolete them if they no longer refer well.
>
>     Happy to discuss this offlist if you are interested in my experiences.
>
>     Best,
>     Alan
>
>     On Friday, April 19, 2013, Ali SH wrote:
>
>         I'm also very interested in hearing answers to this.
>
>         As Stephen mentions, treating an ontology analogously to source code (which is close enough) means that you can use
>         services such as github (or google code). The downside is that an ontology lifecycle management is /not/ equivalent to
>         source code management. Barring a native solution for ontologies, they do come quite close.
>
>         You might also be interested in following the development of the Open Ontology Repository [1]
>         (a fork of the BioPortal platform), which among other things will be addressing this issue as well.
>
>         [1] http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository
>
>         On Fri, Apr 19, 2013 at 11:57 AM, Stephen D. Williams <sdw@lig.net> wrote:
>
>             Do you want to version it like source code?  Everyone has, is, or will move to Git for that.
>             Or maintain the history of changes for reasoning and/or historical queries?  This is probably more needed for
>             actual statements, but could make sense here too: "Answer this query based on the ontology at time X."
>
>             Stephen
>
>
>             On 4/19/13 7:05 AM, Prateek wrote:
>>             Hello all,
>>
>>             I am trying to identify a system which will provide versioning and revision control capabilities specifically for
>>             ontologies. Does anyone have any experience and idea about which systems can help out or if systems like SVN, CVS
>>             can do the job?
>>
>>             Regards
>>
>>             Prateek
>>
>>             -- 
>>
>>             - - - - - - - - - - - - - - - - - - -
>>             Prateek Jain, Ph. D.
>>             RSM
>>             IBM T.J. Watson Research Center
>>             1101 Kitchawan Road, 37-244
>>             Yorktown Heights, NY 10598
>>             Linkedin: http://www.linkedin.com/in/prateekj
>>
>
>
>             -- 
>             Stephen D. Williamssdw@lig.net  stephendwilliams@gmail.com  LinkedIn:http://sdw.st/in
>             V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362  <tel:703.371.9362>  F:703.995.0407  <tel:703.995.0407>
>             AIM:sdw  Skype:StephenDWilliams  Yahoo:sdwlignet  Resume:http://sdw.st/gres
>             Personal:http://sdw.st  facebook.com/sdwlig  <http://facebook.com/sdwlig>  twitter.com/scienteer  <http://twitter.com/scienteer>
>
>
>
>
>         -- 
>
>
>         (•`'·.¸(`'·.¸(•)¸.·'´)¸.·'´•) .,.,
>
>
>
>
> -- 
> *Bernard Vatant
> *
> Vocabularies & Data Engineering
> Tel : + 33 (0)9 71 48 84 59
> Skype : bernard.vatant
> Blog : the wheel and the hub <http://bvatant.blogspot.com>
> --------------------------------------------------------
> *Mondeca*****
> 3 cité Nollez 75018 Paris, France
> www.mondeca.com <http://www.mondeca.com/>
> Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>
> ----------------------------------------------------------


-- 
Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: http://sdw.st/in
V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407
AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres
Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer

Received on Friday, 19 April 2013 18:50:22 UTC