do you mean something like either:

   property_value: latest_modification_by "MYO:erick" xsd:string

or this:
   property_value: latest_modification_by MYO:erick

   where 'erick' is an instance in an ontology with 'MYO' as IDSpace, such as:

     id: MYO:erick
     name: Erick Antezana
     instance_of: person

I think I will go initially for the string solution, so that I don't have to create instances for my users....

On the other hand, I prefer to use "latest" instead of "last", since 'last' conveys the idea that there will be no more modifications; on the contrary, 'latest' keeps the door open for further improvements/changes.

I agree with the 4 points you suggested for ontology maintainers; however, I am afraid that without the appropriate tooling for ontology maintainers, it won't be possible to encourage people to capture all that information...which is a pity since in the future only the contributors who will have the appropriate tools will be duly acknowledged (the rest simply ignored...).


On 31 October 2012 19:02, Chris Mungall <> wrote:

Hi Erick,

I cc'd Phil and Matt as this is veering into discussion of assigning credit to ontology contributors, and they have some ideas here. Comments below.

On Oct 31, 2012, at 3:07 AM, Erick Antezana wrote:

> Hi,
> I will implement (in my pipeline) a way to capture those entries as
> property_value's so that the generated ontologies capture the id/name
> of the person who modified a term as well as the date of its *latest*
> modification (ISO-8601 format as for the creation_date), for instance:
>  property_value: latest_modification_by "MYO:erick"

you should explicitly model yourself as a string (use xsd:string as an initial arg) or as an entity (no additional arg, but unquote yourself)

This is not well standardized across ontologies yet. GO has a registry of editors who are denoted by a GOC:nnn ID. In future we may add researcherids/orcids to this or encourage using such globally unique IRIs directly

>  property_value: latest_modification_date "2012-10-30T08:40:22Z" xsd:date
> where:
>  MYO = namespace of my ontology holding the instance "erick"
>  erick = instance
>  'latest_modification_by'  and 'latest_modification_date' = two
> relationship type id's to keep track of the latest (not last) entry
> modification
>  "2012-10-30T08:40:22Z" = date in ISO 8601 format
>  xsd:date = datatype identifier


> As mentioned by Chris, there could be indeed several other ways to
> capture/model those elements, e.g. storing multiple dates reflecting
> the dates the entry (term/relationship) has been modified...I do not
> see too many advantages of doing it so...terms/relationships will get
> "polluted" or overloaded of "unnecessary" data...?

The only advantage is if you are tracking *each* modification plus person-modifying (n per term), rather than last_modification (a functional property, 1 per term)

> Nonetheless, I
> recall that many years ago we discussed in a meeting about giving
> credit to people/groups who contributed with new terms or simply
> refined them (e.g. improved definition, extra references, extra
> synonyms,..) ...with such a "multiple-date/multiple-user" modelling we
> could clearly give credit to ALL the contributors. In my particular
> case, we are interested in keeping track of the latest date an entry
> has been modified as well as the person who performed that
> modification. Having that latest person's name/id is as having
> somebody *responsible* for the current contents of that entry. I would
> be curious to see how other team approached those aspects... any
> thoughts/ideas are very welcome!

The current practice would be to add these to the definition dbxref field, but this doesn't really indicate the nature of the contribution, the time of the contribution etc.

In these cases, sometimes a separate GO_REF is created, e.g.

These can be treated as mini publications, and associated with relevant metadata such as authors, author contributions, dates, etc.

The GO_REF system is not perfect - I find the abstracts too high level, and they don't describe the actual rationale for modeling something a certain way on the ontology. Plus they are low visibility as far as credit is concerned.

I would advocate a kind of 4 level process for ontology maintainers:

1. As a minimum, each class and the ontology as a whole can be annotated using a dc:contributor or dc:creator property. This is now possible in obo-format (but not oboedit, as yet)

2. Keep ontology discussions on public fora such as mailing lists and trackers, and link to these from the ontology where appropriate (also - get a purl for your tracker)

3. Any ontology contributions involving a piece of unique non-trivial biology or ontology modeling is often deserving of at least a small article published on a pre-print site. The ontogenesis kblog ( ) is ideal for this. The article can then be linked from the originating ontology, or indeed from other ontologies, publications and so on. I recommend that anyone involved in making ontologies (everyone on this list I expect) read Robert Steven's and others excellent ontology articles published on this forum ( ), and considers writing an article on their own ontology for publication and community comments here.

By all means follow the traditional publication route too but it's harder to publish ontology papers and the traditional review process can be at odds with the goal of getting comprehensive documentation out there, even in venues like PLoS ONE.

4. As in software engineering, an ontology should include comprehensive in-line documentation, stating why things are modeled a certain way. The primary goal here is maintainability and long-term sustainability, but it also serves as an audit trail and potential mechanism of credit. Note that there is some level of overlap between 4 and 3 - it may be the case that these are combined, with a high level summary article on the kblog accompanying detailed ontology-specific documentation embedded in the ontology.

As yet the mechanism for achieving #4 is under discussion, but inspired by systems developed by David OS and Matt Brush, the basic idea is:

* Maintain a separate 'ontology' that contains individual articles or design decisions; for owl users, this can be directly imported.

* Each article entity has a dc:description field that contains text formatted in a lightweight format such as markdown

* Each artcile entity has all the metadata you'd expect such as creator, contributor, date, article type, etc

* Articles are linked to from the main ontology via a to-be-decided list of properties. For example, there might be an article type of "modeling pattern", and individual classes may be tagged as either conforming to or in the process of being refactored to conform to this modeling pattern. Matt's REO ontology has some good examples of this.

* HTML can be generated from this for end users, and ontology editing environments may in future better support creation of this kind of metadata, but in the absence of these the system is still extremely useful.

We have a demo of a lightweight system stitched together from some 3rd party components (e.g. using pandoc to generate the html) using some of the documentation on the uberon multi-species ontology

An example article:


Index of articles:


(note that many of these are currently placeholders)

Meta-article describing documentation system:


> On the other hand, It would indeed be great if Protege and OBOEdit
> could handle those properties somehow; nevertheless, w.r.t. Melanie's
> comment (users asking to store how the term was *before* the
> modification), I think that goes beyond of what we should keep in an
> ontology file... In my opinion, those things should be managed by
> tools such as OORT (

Yes, the ontology editing environment should automatically generate all required edit info. OE currently stamps the created_by/date fields, but no others. It would be useful to extend to last_modification

One problem with the current property_value system is that currently these are neither visible nor editable within OE, which limits some of the above, requiring some workarounds.


> cheers,
> Erick
> On 30 October 2012 17:44, Chris Mungall <> wrote:
>> creation_date and created_by are already built into the obo syntax - they just map to oboInOwl annotation properties at the moment.
>> On Oct 30, 2012, at 9:29 AM, Melanie Courtot wrote:
>>> On a side note, we did something like date in the context of SBO. After a little while, we realized that the date was not enough and that users wanted to actually store what the last modification was (e.g., store the term as it was before the modification) It probably depends on what you want to achieve by storing the modification date.
>>> If I remember correctly, we also store the date at which the term was created. Maybe we could have a similar system were one term could have several properties "modification_date" and then annotations on this one for the name of the modifier and the previous version of the term.
>>> Melanie
>>> On 2012-10-30, at 8:42 AM, Chris Mungall wrote:
>>>> Hi Erick
>>>> I recommend you use property_value tag and request the properties
>>>> below from IAO. The modification date would be an xsd:date.
>>>> Given that there may be multiple modification I suggest requesting
>>>> "last modification date", or modeling each modification as a separate
>>>> entity (outside what can be done easily in obo-format).
>>>> It's not clear how this would be used - at the moment neither Protege
>>>> not OE tracks this (though it may be useful for them to do so)
>>>> On Tue, Oct 30, 2012 at 12:42 AM, Erick Antezana
>>>> <> wrote:
>>>>> Hi,
>>>>> I would like to request the addition of two new tags: modified_by and
>>>>> modification_date (unless there is a better way/practice to keep track
>>>>> of atomic/term modifications...)
>>>>> modified_by: erick
>>>>> modification_date: 2012-10-30T08:40:22Z
>>>>> I recall those tags were at some point present in TO
>>>>> (!topic/obo-format/de0vV-2KrxQ)...
>>>>> cheers,
>>>>> Erick
>>>>> ------------------------------------------------------------------------------
>>>>> Everyone hates slow websites. So do we.
>>>>> Make your web apps faster with AppDynamics
>>>>> Download AppDynamics Lite for free today:
>>>>> _______________________________________________
>>>>> Obo-format mailing list
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> _______________________________________________
>>>> Obo-format mailing list