version IRI of OBO ontologies not resolving

[GoogleCodeExporter]

Hi,

I found many version IRI provided by OBO ontologies in the OWL file and 
displayed on ontobee.org does not work. For example,
CL:
http://purl.obolibrary.org/obo/cl/2012-11-04/cl.owl
PATO:
http://purl.obolibrary.org/obo/pato/2012-12-07/pato.owl
UBERON:
http://purl.obolibrary.org/obo/uberon/2012-12-10/uberon.owl
UO
http://purl.obolibrary.org/obo/uo/2012-08-30/uo.owl

Could it be fixed?

Thanks,

Jie

Original issue reported on code.google.com by mcour...@gmail.com on 17 Jan 2013 at 9:18

[GoogleCodeExporter]

I would like to propose a change to the id policy, to allow people the option 
of having release URIs

http://purl.obolibrary.org/obo/ONT/releases/YYYY-MM-DD/ONT.owl

This is very easy to manage. See the instructions I wrote here:

  www.obofoundry.org/wiki/index.php/Making_a_Google_Code_project_for_an_ontology

The release manager performs an svn copy to a /releases folder

There can be a generic purl partial redirect for each ontology

  http://purl.obolibrary.org/obo/ONT/releases/ --> $websvnroot/releases/

I cannot commit to registering every release artifact for every release using 
the OCLC interface, and I cannot ask others to do this either. We must make 
virtue the path of least resistance.

Jie for now you can go to the svn folder for the above

Original comment by cmung...@gmail.com on 17 Jan 2013 at 10:34

[GoogleCodeExporter]

Could the release manager be configured to create the PURL at the same time it 
does the SVN copy?

If that's not possible then the above would work.

Original comment by mcour...@gmail.com on 18 Jan 2013 at 4:56

[GoogleCodeExporter]

The "release manager" is currently either a human or a periodically invoked 
cron or jenkins job, depending on the ontology.

For human-triggered releases, the human could create a partial redirect for the 
datestamp to the svn release copy, but this is busy work, everyone has enough 
on their plate.

In theory someone could add an extension to Oort to talk to the OCLC API but we 
have no plans for this.

Personally I don't like clogging up the OCLC database with an entry for every 
release, it's hard enough to search and figure out what's going on as it is, 
our dependence on OCLC makes me nervous enough already.

Original comment by cmung...@gmail.com on 19 Jan 2013 at 2:34

[GoogleCodeExporter]

Depending 1/2 on one and 1/2 on another is the worst of all possibilities. 
Adding API access to OCLC or a PURL server isn't a large task. Can it be added 
to the task list? I'd like us to have a single solution. The requirement for 
that solution is that it is possible to delegate maintenance to the ontology 
developers (that's part of the architecture). Alternatives are to run our own 
purl server, or to try out Callimachus which I'm told will have partial url 
redirects in the next version.

What language does the implementation need to be in order to work with Jenkins?

I Callimachus works out then perhaps we can deploy it on Amazon free level of 
service and take Berkeley out of the loop.

I'll start a separate issue proposing that we deploy to AWS

Original comment by alanruttenberg@gmail.com on 21 Jan 2013 at 6:53