This guide is for Uberon core editors.

Contributing editors see README-contributing-editors.txt

Do you have an ID range in the idranges file (uberon-idranges.owl), in the src/ontology/ directory)? If not, Chris, David, or Nicole can add one for you.

Ensure that you have Protege configured to generate new URIs in your own range. Note that if you edit multiple files, you need to check this every time to ensure that the proper settings are in place. Uberon URIs should look like this: http://purl.obolibrary.org/obo/UBERON_0000061.

A word of caution about Protege auto-id functionality. Protege will allow reuse of a URI in your range according to the numbering scheme. It will keep track of what you did during last session, but does not check for use of the URI before assigning it. Therefore, if you switched between editing another ontology, Protege will not know not to start from the beginning. Some tips below to check to see where you are in your range. Note: if you only edit the UBERON and do not edit other ontologies, you will only need to set this up once, Protege will remember your last ID between sessions.

1. Go to Protege->Preferences, and click the New Entities tab (on the right).

• Start with: "Specified URI": http://purl.obolibrary.org/obo/
• Followed by: "/"
• End with: "autogenerated ID"
• Entity label (for use with Auto-generated ID): "custom label": http://www.w3.org/2000/01/rdf-schema#label
• Autogenerated ID: "numeric", prefix "UBERON_", digit count "7", start (next unused ID in your range), end (last ID in your range)
• Tick the box "remember last ID between Protege sessions"

For instance, Nicole's ID range is > 8000000 , <= 8199999

Protege should then remember your last used ID on the computer you are currently using for next time, though you should double check. (You can ignore this if you do not intend to create new classes.)

2. Go to Protege->Preferences, New Entities Metadata tab (on the left).

• Tick the box Annotate new entities with creator (user)
• Creator property: http://www.geneontology.org/formats/oboInOwl#created_by
• Creator value: Use ORCID (note, you will need to register with ORCID, if you have not already (orcid.org)
• Do not tick Annotate new entities with creation date/time
• Date value format: ISO-8601

The editors file is currently uberon_edit.obo

Workflow:

  git pull
  # edit uberon_edit.obo and save changes
  make uberon-qc
  git commit -m 'type message here'
  git push
  # check Jenkins - http://build.berkeleybop.org/job/build-uberon/

Releases:

  make uberon-qc
  make release
  cd trunk
  svn commit -m ''
  # then svn copy to release folder

For now the workflow is to hand edit the file in emacs with obo-mode on, using a variety of scripts and tools. ordering of stanzas in the obo file is optimized for hand-edits.

Releases need not be made after every edit. Eventually releases will be daily and automated via Jenkins.

The source for uberon lives in github, in the https://github.com/obophenotype/ project. We make use of sourceforge svn for release files, as there is no quota on file size or repository size.

The split is potentially confusing, and in future we may prefer to move to a maven-like system for releases.

Currently releases are made by typing "make uberon-qc". See the Makefile for the actual dependencies. This unleashes a massive pipeline, which involves

• Using OWLTools and Oort to pre-reason and check for unsats
• using a bevy of perl scripts to check for hand-edit derived errors
• performing a number of semantic verification steps using prolog
  • taxon checks (<--- now done with Elk)
  • disjoint violations, spatial disjointness checks
• making derived files
• merged (now done in owltools)
• composites
• bridge files

After which the editor must perform a complicate release process to sf.

This will be changed such as the majority of the release process can be carried out by Oort under Jenkins. This will use the majority of Oort's features:

• merge in external ontologies
• expand macros, in particular:
• spatially disjoint from
• taxon constraints
• expanding xrefs using treat-xrefs-XXs
• running reasoner for checks and pre-reasoning

Some checks will likely remain in perl (obo-scripts) for the immediate future.

There is a test Makefile for performing this in the build/ directory

There are a few things needing worked out in Oort:

• selective expansion of macros
• ensure mireoting of relations has correct behavior
• bridge files

Rather than having all information in one monolithic obo file we will progressively place certain subsets of information into owl files that can be imported using importer ontologies. These will be edited in P4.

NOTE: this has already been done for phenoscape-ext.owl

Eventually the core will switch to OWL and be edited in P4.

• depiction ontology

Translate:

id: X xref: http://.{png,jpg}

to

 NamedIndividual: <url>
  Type: foaf:image, depicts some <X>

Then we will manually add more detailed annotations. E.g

 NamedIndividual: <url>
  Type: foaf:image, 
   depicts some NCBITaxon_foo and has_part some (x and has_part some y and adjacent_to some z)

We will use Jim Balhoff's image plugin

• publication information?
• taxon bridging axioms
• external ontology bridging axioms: go, pr, cl...
• disjointness and spatial disjointness?

We will probably save the editors version in functional syntax

Blocked on:

• ID support in P4 (showstopper?)
• Do full testing of functional syntax
• Informative diffs (OntoVCS support?)
• deterministic order of elements in functional syntax (diffs)

The editors version will most likely owl-import other ontologies. Need to figure this into release process.

How does this work with CL? Synchronize this? Mutual imports?

Need to import CARO, but this will require some work particularly aligning FMA and others (we have removed the disjointness between material and immaterial in our current version).