[Obo-format] On the ugliness of IAO metadata properties in the OWL->OBO translation, and proposal to ameliorate this

[Alan Ruttenberg]

I was looking at an OORT generated OBO version of OBI and was struck by how unnecessarily (afaik) unpleasant rendering. Here's the example:

Before:

[Term]

id: BFO:0000004

name: independent continuant

def: "A continuant  that is a bearer of quality  and realizable entity  entities, in which other entities inhere and which itself cannot inhere in anything." []

property_value: IAO:0000111 "independent continuant" xsd:string

property_value: IAO:0000112 "a chair" xsd:string

property_value: IAO:0000112 "a heart" xsd:string

property_value: IAO:0000112 "a leg" xsd:string

property_value: IAO:0000112 "a person" xsd:string

property_value: IAO:0000112 "a symphony orchestra" xsd:string

property_value: IAO:0000112 "an organism" xsd:string

property_value: IAO:0000112 "the bottom right portion of a human torso" xsd:string

property_value: IAO:0000112 "the lawn and atmosphere in front of our building" xsd:string

property_value: IAO:0000118 "substantial entity" xsd:string

is_a: BFO:0000002 ! continuant

Here's  what I think it should look like. Comments below. Is there a reason it can't look like this? It seems that the benefit of OBO, something that we should retain, is that it's possible to read and author it in a text editor.

[Term]

id: BFO:0000004

name: independent continuant

def: "A continuant  that is a bearer of quality  and realizable entity  entities, in which other entities inhere and which itself cannot inhere in anything." []

example_of_usage: "a chair" 

example_of_usage: "a heart" 

example_of_usage: "a leg" 

example_of_usage: "a person" 

example_of_usage: "a symphony orchestra" 

example_of_usage: "an organism" 

example_of_usage: "the bottom right portion of a human torso" 

example_of_usage: "the lawn and atmosphere in front of our building" 

synonym: "substantial entity" EXACT

is_a: BFO:0000002 ! continuant

Notes: 

Don't repeat name as IAO:0000111 - they mean the same thing.

IAO:0000118 'alternative term' means the same thing as exact synonym

property_value: IAO:0000112 means example of usage. I use a tag that says that. Is there a reason that the generic tag is necessary/desirable in someone's view?

One doesn't need to ever write xsd:string, since that's the only type of string there is. When there is provision for language tags that will merit some extra markup.

While there may be some controversy on a small set of the IAO metadata tags, particularly non-exact "synonyms", most of the metadata terms we envisioned as fitting comfortably in OBO syntax. The other ones I would add as built-in tags are (perhaps not exclusively - but these make sense on quick glance)

editor-note:

curation-note:

curation-status:

term-editor: 

obsolescence-reason:

imported-from:

denotator-type:

first-order-logic-expression: 

While the field values of some of these are supposed to be taken from enumerated sets (e.g. curation_status is (currently) one of {'example to be eventually removed' , 'metadata complete' , 'organizational term' , 'ready for release' , 'metadata incomplete' , uncurated , 'pending final vetting' , 'to be replaced with external ontology term' , 'requires discussion'} there's no reason why the translation rules can't take these from strings to their instances.

Some of these tags could be construed to be equivalent to properties in other vocabularies, e.g. 'alternative term' -> skos:altLabel. When there was a wider discussion of this issue a number of years ago, the thought was 1) The other vocabulary terms are often poorly defined or ambiguous 2) that we should have, at least, annotation properties that are defined how we want them to be 3) That we should, in those cases where we defined a property that has a close cognate in a popular semweb vocabulary,  as a matter of courtesy, have property assertions for both the foundry defined annotation property as well as the external vocabulary property. Hence OBI mirrors labels (via script) between 'editor preferred name' and refs:label. Our  OBO->OWL mapping could do the same.

 

-Alan

[Erick Antezana]

I would think the owl2obo for that term should look like the following
(assuming that "alternative term" (IAO) = exact synonym):

[Term]
id: BFO:0000004
name: independent continuant
def: "A continuant that is a bearer of quality and realizable entity
entities, in which other entities inhere and which itself cannot
inhere in anything." []

property_value: example_of_usage "a chair" xsd:string
property_value: example_of_usage "a heart" xsd:string
property_value: example_of_usage "a leg" xsd:string
property_value: example_of_usage "a person" xsd:string
property_value: example_of_usage "a symphony orchestra" xsd:string
property_value: example_of_usage "an organism" xsd:string
property_value: example_of_usage "the bottom right portion of a human
torso" xsd:string
property_value: example_of_usage "the lawn and atmosphere in front of
our building" xsd:string

synonym: "substantial entity" EXACT []
is_a: BFO:0000002 ! continuant

or something like the following if we have extra instances or terms:

[Term]
id: BFO:0000004
name: independent continuant
def: "A continuant that is a bearer of quality and realizable entity
entities, in which other entities inhere and which itself cannot
inhere in anything." []

property_value: example_of_usage chair
property_value: example_of_usage heart
property_value: example_of_usage leg
property_value: example_of_usage person
property_value: example_of_usage symphony_orchestra
property_value: example_of_usage organism
property_value: example_of_usage XYZ:0000011
property_value: example_of_usage XYZ:0000012

synonym: "substantial entity" EXACT []
is_a: BFO:0000002 ! continuant

where 'chair', 'heart', 'leg', ..., XYZ:0000011 (=the lawn...) are IDs
of an instance or term/universal...

I think that some terms will have other kind of example_of_usage's
where their type could be a date (xsd:date) or a positive integer
(xsd:positiveInteger)... if so, explicitly having xsd:string might
still be useful...

cheers,
Erick

> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Obo-format mailing list
> Obo-f...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/obo-format
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Obo-format mailing list
Obo-f...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obo-format

[Alan Ruttenberg]

On Mon, Feb 25, 2013 at 5:35 PM, Erick Antezana <erick.a...@gmail.com> wrote:

I would think the owl2obo for that term should look like the following
(assuming that "alternative term"  (IAO) = exact synonym):

[Term]
id: BFO:0000004
name: independent continuant
def: "A continuant  that is a bearer of quality  and realizable entity
 entities, in which other entities inhere and which itself cannot
inhere in anything." []

property_value: example_of_usage "a chair" xsd:string
property_value: example_of_usage "a heart" xsd:string
property_value: example_of_usage "a leg" xsd:string
property_value: example_of_usage "a person" xsd:string
property_value: example_of_usage "a symphony orchestra" xsd:string
property_value: example_of_usage "an organism" xsd:string
property_value: example_of_usage "the bottom right portion of a human
torso" xsd:string
property_value: example_of_usage "the lawn and atmosphere in front of
our building" xsd:string

synonym: "substantial entity" EXACT []
is_a: BFO:0000002 ! continuant

Why the extra "property value:" and xsd:string noise?

 

or something like the following if we have extra instances or terms:

[Term]
id: BFO:0000004
name: independent continuant
def: "A continuant  that is a bearer of quality  and realizable entity
 entities, in which other entities inhere and which itself cannot
inhere in anything." []

property_value: example_of_usage chair
property_value: example_of_usage heart
property_value: example_of_usage leg
property_value: example_of_usage person
property_value: example_of_usage symphony_orchestra
property_value: example_of_usage organism
property_value: example_of_usage XYZ:0000011
property_value: example_of_usage XYZ:0000012

synonym: "substantial entity" EXACT []
is_a: BFO:0000002 ! continuant

where 'chair', 'heart', 'leg', ..., XYZ:0000011 (=the lawn...) are IDs
of an instance or term/universal...

I think that some terms will have other kind of example_of_usage's
where their type could be a date (xsd:date) or a positive integer
(xsd:positiveInteger)... if so, explicitly having xsd:string might
still be useful...

I agree that having type information is useful. But default the common case, which is xsd:string. Or better have some way to map strings to instances, so the mapping can be imported in different places. Or use the approach that manchester syntax does, which is that if it looks like a number it, it *is* a number. Could do the same with dates.

OWL can't do defaulting or dwimming, but OBO can. 

[Chris Mungall]

Sorry for the rushed response, at a meeting, comments inline

On Feb 24, 2013, at 11:26 PM, Alan Ruttenberg wrote:

> I was looking at an OORT generated OBO version of OBI and was struck by how unnecessarily (afaik) unpleasant rendering. Here's the example:
>
> Before:
>
> [Term]
> id: BFO:0000004
> name: independent continuant
> def: "A continuant that is a bearer of quality and realizable entity entities, in which other entities inhere and which itself cannot inhere in anything." []
> property_value: IAO:0000111 "independent continuant" xsd:string
> property_value: IAO:0000112 "a chair" xsd:string
> property_value: IAO:0000112 "a heart" xsd:string
> property_value: IAO:0000112 "a leg" xsd:string
> property_value: IAO:0000112 "a person" xsd:string
> property_value: IAO:0000112 "a symphony orchestra" xsd:string
> property_value: IAO:0000112 "an organism" xsd:string
> property_value: IAO:0000112 "the bottom right portion of a human torso" xsd:string
> property_value: IAO:0000112 "the lawn and atmosphere in front of our building" xsd:string
> property_value: IAO:0000118 "substantial entity" xsd:string
> is_a: BFO:0000002 ! continuant

Yeh, not too pretty. (but not too bad when compared to the rdf/xml!)

This shouldn't be too surprising though. The property_value tags have been in obo-format since 2004 as an extensible generic mechanism for this kind of thing. As IAO uses numeric identifiers, this is what you see in the property value tag.

> Here's what I think it should look like. Comments below. Is there a reason it can't look like this? It seems that the benefit of OBO, something that we should retain, is that it's possible to read and author it in a text editor.

I'm not sure how much benefit there is. I do author obo format in a text editor but thankfully I'm in a small minority. Most users of obo format see the ontology through the prism of oboedit. Unfortunately there isn't much support for anything beyond the core metadata tags in OE. We may have some support for the generic property_value tag if there is enough demand. So actually the generic tags are the best bet for getting more oboedit users to adopt additional metadata schemas.

>
> [Term]
> id: BFO:0000004
> name: independent continuant
> def: "A continuant that is a bearer of quality and realizable entity entities, in which other entities inhere and which itself cannot inhere in anything." []
> example_of_usage: "a chair"
> example_of_usage: "a heart"
> example_of_usage: "a leg"
> example_of_usage: "a person"
> example_of_usage: "a symphony orchestra"
> example_of_usage: "an organism"
> example_of_usage: "the bottom right portion of a human torso"
> example_of_usage: "the lawn and atmosphere in front of our building"
> synonym: "substantial entity" EXACT
> is_a: BFO:0000002 ! continuant

Various reasons, including:

- the spec has been relatively stable for a while.

- you don't gain much (see above). In fact due to the way OE is engineered there is more likely to be generic support for the generic property_value tags than special blessed tags.

- I'm not sure if you're suggesting extending the BNF to account for an additional set of blessed properties, or generically extending it to allow for open ended sets of annotation properties. If the former, why example_of_usage over many other useful annotation properties? How do we know when we have the final set? My goal is to freeze the spec. If the latter, this would make the BNF and spec even more complicated than it already is.

> Notes:
> Don't repeat name as IAO:0000111 - they mean the same thing.

The translated obo-format is just reflecting what's in the input ontology. If the input ontology repeats the rdfs:label in the IAO_0000111 assertion then that's what the translated form shows.

> IAO:0000118 'alternative term' means the same thing as exact synonym
> property_value: IAO:0000112 means example of usage. I use a tag that says that. Is there a reason that the generic tag is necessary/desirable in someone's view?

The generic tag is useful if we want a way to roundtrip arbitrary ontologies.

> One doesn't need to ever write xsd:string, since that's the only type of string there is. When there is provision for language tags that will merit some extra markup.

In terms of roundtripping to/from OWL surely this is required? To distinguish plain literals from xsd:strings.

It's been this way in obo-format since 2004:
http://www.geneontology.org/GO.format.obo-1_2.shtml

(Modeled after the rdf spec)

> While there may be some controversy on a small set of the IAO metadata tags, particularly non-exact "synonyms", most of the metadata terms we envisioned as fitting comfortably in OBO syntax. The other ones I would add as built-in tags are (perhaps not exclusively - but these make sense on quick glance)
>
> editor-note:
> curation-note:
> curation-status:
> term-editor:
> obsolescence-reason:
> imported-from:
> denotator-type:
> first-order-logic-expression:

I could probably come up with a few dozen more. In another year, a dozen more. That's why an extensible syntax (complete with typing for literals) is a good idea.

> While the field values of some of these are supposed to be taken from enumerated sets (e.g. curation_status is (currently) one of {'example to be eventually removed' , 'metadata complete' , 'organizational term' , 'ready for release' , 'metadata incomplete' , uncurated , 'pending final vetting' , 'to be replaced with external ontology term' , 'requires discussion'} there's no reason why the translation rules can't take these from strings to their instances.

One reason is that this set of obsolescence reasons above is incomplete, and we don't want to have to introduce a new specification with a new BNF every time IAO introduces a new obsolescence reason instamce.

(I have a lot of issues with these values but that's probably an issue with the IAO list)

> Some of these tags could be construed to be equivalent to properties in other vocabularies, e.g. 'alternative term' -> skos:altLabel.

This is an issue for IAO surely?

> When there was a wider discussion of this issue a number of years ago, the thought was 1) The other vocabulary terms are often poorly defined or ambiguous 2) that we should have, at least, annotation properties that are defined how we want them to be 3) That we should, in those cases where we defined a property that has a close cognate in a popular semweb vocabulary, as a matter of courtesy, have property assertions for both the foundry defined annotation property as well as the external vocabulary property. Hence OBI mirrors labels (via script) between 'editor preferred name' and refs:label. Our OBO->OWL mapping could do the same.

Sorry, I'm not sure I understand this.

[Chris Mungall]

On Feb 25, 2013, at 5:35 PM, Erick Antezana wrote:

> I would think the owl2obo for that term should look like the following
> (assuming that "alternative term" (IAO) = exact synonym):
>
> [Term]
> id: BFO:0000004
> name: independent continuant
> def: "A continuant that is a bearer of quality and realizable entity
> entities, in which other entities inhere and which itself cannot
> inhere in anything." []
> property_value: example_of_usage "a chair" xsd:string
> property_value: example_of_usage "a heart" xsd:string
> property_value: example_of_usage "a leg" xsd:string
> property_value: example_of_usage "a person" xsd:string
> property_value: example_of_usage "a symphony orchestra" xsd:string
> property_value: example_of_usage "an organism" xsd:string
> property_value: example_of_usage "the bottom right portion of a human

To do this either we have to hardcore the IAO label into the BNF, or we have to implement a complex translation rule involving a lookup to IAO and translating spaces to underscores.

Maybe I'm missing something, do you want to suggest specific changes to the spec?

> torso" xsd:string
> property_value: example_of_usage "the lawn and atmosphere in front of
> our building" xsd:string
> synonym: "substantial entity" EXACT []
> is_a: BFO:0000002 ! continuant
>
> or something like the following if we have extra instances or terms:
>
> [Term]
> id: BFO:0000004
> name: independent continuant
> def: "A continuant that is a bearer of quality and realizable entity
> entities, in which other entities inhere and which itself cannot
> inhere in anything." []
> property_value: example_of_usage chair
> property_value: example_of_usage heart
> property_value: example_of_usage leg
> property_value: example_of_usage person
> property_value: example_of_usage symphony_orchestra
> property_value: example_of_usage organism
> property_value: example_of_usage XYZ:0000011
> property_value: example_of_usage XYZ:0000012
> synonym: "substantial entity" EXACT []
> is_a: BFO:0000002 ! continuant
>
> where 'chair', 'heart', 'leg', ..., XYZ:0000011 (=the lawn...) are IDs
> of an instance or term/universal...

I like the idea of providing links to actual recommended usages (of course you can get all actual usages via OntoBee pretty easily).

I would suggest first working out how you would represent this in OWL and then the obof translation would follow from that (assuming it's within the subset of OWL expressible in obof)

[Chris Mungall]

This would be a non-backwards compatible change. I'm hesitant to do this unless there's strong demand.

[Erick Antezana]

On 25 February 2013 23:50, Alan Ruttenberg <alanrut...@gmail.com> wrote:
>
>
> On Mon, Feb 25, 2013 at 5:35 PM, Erick Antezana <erick.a...@gmail.com>
> wrote:
>>
>> I would think the owl2obo for that term should look like the following
>> (assuming that "alternative term" (IAO) = exact synonym):
>>
>> [Term]
>> id: BFO:0000004
>> name: independent continuant
>> def: "A continuant that is a bearer of quality and realizable entity
>> entities, in which other entities inhere and which itself cannot
>> inhere in anything." []
>> property_value: example_of_usage "a chair" xsd:string
>> property_value: example_of_usage "a heart" xsd:string
>> property_value: example_of_usage "a leg" xsd:string
>> property_value: example_of_usage "a person" xsd:string
>> property_value: example_of_usage "a symphony orchestra" xsd:string
>> property_value: example_of_usage "an organism" xsd:string
>> property_value: example_of_usage "the bottom right portion of a human
>> torso" xsd:string
>> property_value: example_of_usage "the lawn and atmosphere in front of
>> our building" xsd:string
>> synonym: "substantial entity" EXACT []
>> is_a: BFO:0000002 ! continuant
>
>
> Why the extra "property value:" and xsd:string noise?

I agree that "xsd:string" could be the default data type, thus
reducing unnecessary stuff.. Regarding "property_value", I would
prefer to have it as an indicator of a value associated to a given
term so that the differenciantion between (pre-)defined OBO tags (e.g.
name, relationship, synonym) and other "relationships:properties"
(e.g. example_of_usage) be easier to read and parse.

agree if the data follows strict formatting to be recognised by OBO
parsers, for intance if the dates follow the ISO 8601 or any other
"standard" that could be detected while parsing.

[Erick Antezana]

On 26 February 2013 00:31, Chris Mungall <cjmu...@lbl.gov> wrote:
>
>
>
> On Feb 25, 2013, at 5:35 PM, Erick Antezana wrote:
>
>> I would think the owl2obo for that term should look like the following
>> (assuming that "alternative term" (IAO) = exact synonym):
>>
>> [Term]
>> id: BFO:0000004
>> name: independent continuant
>> def: "A continuant that is a bearer of quality and realizable entity
>> entities, in which other entities inhere and which itself cannot
>> inhere in anything." []
>> property_value: example_of_usage "a chair" xsd:string
>> property_value: example_of_usage "a heart" xsd:string
>> property_value: example_of_usage "a leg" xsd:string
>> property_value: example_of_usage "a person" xsd:string
>> property_value: example_of_usage "a symphony orchestra" xsd:string
>> property_value: example_of_usage "an organism" xsd:string
>> property_value: example_of_usage "the bottom right portion of a human
>
> To do this either we have to hardcore the IAO label into the BNF, or we have to implement a complex translation rule involving a lookup to IAO and translating spaces to underscores.
>
> Maybe I'm missing something, do you want to suggest specific changes to the spec?

no, I prefer to keep it as it is: support for generic property_value's
(otherwise not only the spec/BNF needs to be updated but also OBO
parsers). The OBO lines above (and below) are my interpretations of
the OBO spec for that specific owl2obo translation.

[Alan Ruttenberg]

Do I recall correctly that parsers are supposed to ignore tags they don't understand?

If so, adding new tags would at least not hurt old parsers. 

I would be in favor of allowing arbitrary tag value pairs, if that's the case, ideally with a mechanism for adding metadata about them, e.g. Something like tagdef. 

I don't see the goal of OBO as necessarily being full OWL 2 roundtripping. I'll try to write an explanation of why this is perhaps unnecessary, and if not what benefits relaxing this constrain might bring. Roughly we could define a pair of OWL and OBO files and merge operations from OBO into OWL and OWL into OBO for the subset of features that oboedit can comfortably handle. The. Editing could happen in either, with the OBO being in sync only over a subset of the expressivity. What you can't express easily in OBO you don't see in OBO, just in OWL. 

-Alan 

[Chris Mungall]

On Feb 26, 2013, at 2:53 AM, Erick Antezana wrote:

> On 26 February 2013 00:31, Chris Mungall <cjmu...@lbl.gov> wrote:
>>
>>
>>
>> On Feb 25, 2013, at 5:35 PM, Erick Antezana wrote:
>>
>>> I would think the owl2obo for that term should look like the following
>>> (assuming that "alternative term" (IAO) = exact synonym):
>>>
>>> [Term]
>>> id: BFO:0000004
>>> name: independent continuant
>>> def: "A continuant that is a bearer of quality and realizable entity
>>> entities, in which other entities inhere and which itself cannot
>>> inhere in anything." []
>>> property_value: example_of_usage "a chair" xsd:string
>>> property_value: example_of_usage "a heart" xsd:string
>>> property_value: example_of_usage "a leg" xsd:string
>>> property_value: example_of_usage "a person" xsd:string
>>> property_value: example_of_usage "a symphony orchestra" xsd:string
>>> property_value: example_of_usage "an organism" xsd:string
>>> property_value: example_of_usage "the bottom right portion of a human
>>
>> To do this either we have to hardcore the IAO label into the BNF, or we have to implement a complex translation rule involving a lookup to IAO and translating spaces to underscores.
>>
>> Maybe I'm missing something, do you want to suggest specific changes to the spec?
>
> no, I prefer to keep it as it is: support for generic property_value's
> (otherwise not only the spec/BNF needs to be updated but also OBO
> parsers). The OBO lines above (and below) are my interpretations of
> the OBO spec for that specific owl2obo translation.

The spec states that the ID form of the URI for the annotation property goes into the property_value field - hence IAO:nnnn rather than an underscore-separated label.

However, there is a "trick" in obo-format where you can specify a shorthand symbol in place of the property symbol. If you do this:

[Typedef]
id: my_internal_label
is_metadata: true
is_class_level: true
xref: IAO:nnnnnn

Then you can say

property_value: my_internal_label "...." xsd:string

But this isn't going to buy you much. For users such as yourself I would be focusing on the best W3 OWL syntax for your uses. Your tools all import OWL don't they?

[Chris Mungall]

Unfortunately this will introduce compatibility problems. Since 2005 there have been both 2 and 3 argument forms, corresponding to rdf objects and literals respectively.

Syntax:
http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html#3.3

Translation:
http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html#5.6

Unfortunately this original design leads to problems with language literals. We may need to introduce some changes here in a way that doesn't break parsers (not that there are many native obo format ontologies that use these generic tags).

The most conservative change is to allow rdfs:Literal in the final argument, or opening this up further to other datatypes.

See above. The spec states that if no 3rd argument is present then it's an object and its translated according to different rules. All versions of oboedit in existence also assume this.

>> Or better have some way to map strings to instances, so
>> the mapping can be imported in different places. Or use the approach that
>> manchester syntax does, which is that if it looks like a number it, it *is*
>> a number. Could do the same with dates.
>
> agree if the data follows strict formatting to be recognised by OBO
> parsers, for intance if the dates follow the ISO 8601 or any other
> "standard" that could be detected while parsing.

The grammar could get rather complex (in addition to breaking compatibility)

>>
>> OWL can't do defaulting or dwimming, but OBO can.

I wouldn't pin your hopes on obo-format becoming the perl of ontology languages (well, maybe it already is)....

[Chris Mungall]

On Feb 26, 2013, at 7:59 AM, Alan Ruttenberg wrote:

Do I recall correctly that parsers are supposed to ignore tags they don't understand?

Your answer can be found here:

http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html#3.3

In obof1.4 it's not conformant if there's an unrecognized tag. The official parser will throw an error if it doesn't recognize a tag (and at the moment there's no way to override this).

Now the story is a bit more complex - in obof guides 1.2 and 1.0 the parser guidelines were to ignore unrecognized tags, as we wanted to make the parsers work with future extensions. We didn't know what was on the horizon.

In contrast we do know the future for obo-format now. The end. 1.4 should be the last version of obo-format. "obo format 2.0" is likely to be some extension of OWL manchester syntax or similar.

I had hoped we would be further on the path to transitioning ontology projects to OWL by this stage. Unfortunately the tools are not there yet, and version control in OWL is horrible after you're used to this in obo-format. This is slowly changing (see for example [1] [2])[3], but in the interim there is wiggle room in the spec for features editors critically need.

The story is different for software developers - new software should consume OWL (directly or via the obo2owl translation). Of course for legacy software it's always possible to translate back. I'm happy to talk with anyone and give recommendations for your own favorite language or environment.

If so, adding new tags would at least not hurt old parsers. 

I would be in favor of allowing arbitrary tag value pairs, if that's the case, ideally with a mechanism for adding metadata about them, e.g. Something like tagdef. 

A neat idea that should have been implemented way back, but to do this in a satisfactory way would probably end up breaking existing code (.e.g you'd probably want to introduce a new stanza type to define your extended syntax)

I'm not sure who would benefit from this. What's the scenario you have in mind?

I think Erick wants obo-format to be like perl, you want it to be like lisp, when in fact the reality is that it's more like COBOL :-(

I don't see the goal of OBO as necessarily being full OWL 2 roundtripping.

Agreed.

I'll try to write an explanation of why this is perhaps unnecessary, and if not what benefits relaxing this constrain might bring. Roughly we could define a pair of OWL and OBO files and merge operations from OBO into OWL and OWL into OBO for the subset of features that oboedit can comfortably handle. The. Editing could happen in either, with the OBO being in sync only over a subset of the expressivity. What you can't express easily in OBO you don't see in OBO, just in OWL. 

The roundtripping probably deserves another email...

Cheers

Chris

[1] http://wiki.geneontology.org/index.php/Ontology_editor_plugins

[2] http://lists.w3.org/Archives/Public/public-owled/2012Aug/thread.html#msg0

[3] http://www.russet.org.uk/blog/2040?

...and many more