singleton intersection_of tags

[GoogleCodeExporter]

singleton intersection_of tags are disallowed. These are currently being 
generated when we have an equivalence axiom between two named classes; eg.

   <owl:Class rdf:about="http://purl.obolibrary.org/obo/HP_0001646">
        <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Abnormality of the aortic valve</rdfs:label>
        <owl:equivalentClass rdf:resource="http://purl.obolibrary.org/obo/MP_0002747"/>

(note that logically single intersection_of tags are a valid way of stating 
equivalence between two named entities, but obo-format explicitly forces you to 
use equivalent_to instead)

Original issue reported on code.google.com by cmung...@gmail.com on 28 Feb 2011 at 10:52

[GoogleCodeExporter]

see test_resources/equivtest.obo

we need a junit that does a roundtrip on an obofile and checks contents before 
and after

Original comment by cmung...@gmail.com on 28 Feb 2011 at 11:07

[GoogleCodeExporter]

Original comment by shahid.m...@gmail.com on 16 Jun 2011 at 6:16

[GoogleCodeExporter]

You're right, seems to be no longer a problem. I added a Junit:

EquivalentToTest

However, there is a related(?) issue with reciprocal equivalence axioms - see 
the tests that fail in the above

Original comment by cmung...@gmail.com on 22 Jun 2011 at 7:27

[GoogleCodeExporter]

single intersection_of tags are produced by this test:

UnmappableExpressionsTest

Original comment by cmung...@gmail.com on 25 Jun 2011 at 1:21

[GoogleCodeExporter]

also try testing on caro_2.owl (see issue 46).

I have diagnosed the issue:

the general principle is: if you can't translate any part of an axiom, drop the 
entire axiom (in future we can look at weakening the axiom, but for now, drop 
it)

see method beginning line 653 of Owl2Obo.java:

    private void tr(OWLEquivalentClassesAxiom ax) { ...

The problem here is that we start building intersection_of clauses and adding 
them to the frame straight away - then when we encounter an expression that 
can't be converted, we return, with a partial axiom (there is *not* a 1:1 
correspondence between clauses and axioms, unfortunately)

This method should build up a list of clauses. It should only add the list of 
clauses to the frame on successful completion of converting the whole axiom. If 
any part of the conversion fails, then the warning should be generated, and 
*no* clauses should should be added to the frame.

Original comment by cmung...@gmail.com on 13 Jul 2011 at 10:27

[GoogleCodeExporter]

If you drop an axiom, do you save the OBO stanza in an annotation so it 
roundtrips?

Original comment by alanruttenberg@gmail.com on 14 Jul 2011 at 7:23

[GoogleCodeExporter]

Fixed by Shahid.

alan, can you add a feature request for this? I now think the untranslateable 
owl axioms should be dumped in a separate owl file, there is no benefit to 
keeping them in the same obo file

Original comment by cmung...@gmail.com on 14 Jul 2011 at 10:49

• Changed state: Fixed

[GoogleCodeExporter]

I thought roundtrip was already considered a requirement. Do you want a feature 
request for an implementation detail?

Original comment by alanruttenberg@gmail.com on 15 Jul 2011 at 5:51

[GoogleCodeExporter]

Compared to roundtrip OWL > OBO > OWL, roundtrip OBO > OWL > OBO is both 
simpler, given the greater expressiveness of OWL, and much more needed, given 
that the ontology world is not exactly full of people who want to move from OWL 
to OBO.  For OWL to OBO, storing untranslate-able OWL axioms somewhere seems 
useful, and I agree that dumping them in a separate OWL file seems most 
sensible. But I think this is a lower priority than supporting the complete 
expressiveness of OBO in OBO > OWL > OBO roundtrips.

Original comment by dosu...@gmail.com on 15 Jul 2011 at 9:08

[GoogleCodeExporter]

SingleIntersectionOfTagTest added to prevent any future occurrences of single 
intersection_of tags. Also added check() methods to model, and includes this 
test. Note that this is called by default by the writer, to make it impossible 
to write an invalid obo document

Original comment by cmung...@gmail.com on 15 Jul 2011 at 8:25

[GoogleCodeExporter]

either an OBO file can generate separate files for good reasons (which this is 
not) and then this becomes one of several cases, or it doesn't in which case 
dumping them to a separate file is not acceptable as given their perception as 
not useful to OBO users they would be discarded and not remembered when going 
back to OWL.

As for OWL->OBO->OWL being important it certainly is, at least until everyone 
is conversant in equally using OBO and OWL editors. For the CL we already have 
a situation in which the primary development has been in OBO but new people 
want to edit in OWL.

Original comment by alanruttenberg@gmail.com on 18 Jul 2011 at 11:46