On 7 Apr 2015, at 9:46, Todd Detwiler wrote:
> Hey Chris,
> Thank you for responding. In your forum post you recommended moving
> away from OBO format, in spite of its predictable serialization.
I've spent a lot of time over the last few years helping people migrate
but one thing we really got right with obo was developing a
serialization that works in conjunction with a VCS, including
visualizing diffs easily without additional layers. over its history GO
has frequently had multiple concurrent editors, with some working on
branches that are later merged in.
> So I have not experimented with that particular serialization format.
> I did try using functional syntax, but the owldiff tool had trouble
> loading it (memory problems if I recall correctly)
odd.
> and the owl2diff tool couldn't read it at all.
anything based off the owlapi should handle it
I would be immediately suspicious of any owl-level tool not built off
the owlapi
> I will take another look at functional syntax and see if I made any
> errors (and try using the purely text based diff tools).
>
> Regarding modularizing the ontology, our problem has always been to
> determine the correct modularization. To use an anatomical approach,
> for example body regions like head, thorax, abdomen, upper limbs, ...
> seems sensible. But someone working on the arterial system will be
> working across modules. We have also considered the approach you
> suggested, to break up the ontology based on axiom type. The problem
> with that is that an author trying to flush out all of the details of
> a particular class would potentially touch all or many of the modules.
> This is a problems only because:
>
> 1. As you suggested, new axioms tend to end up in the open ontology
> (e.g. parent ontology in a network of imports) in Protege. To get each
> axiom to go into the right place, to fill in the details of a class,
> would potentially require each axiom module to be opened individually.
well I was imagining a root importer ontology. yes, it would be terrible
to have to open each individually.
of course with a root importer it's easy for new axioms to end up here
accidentally, but in theory a bit of post-processing could take care of
this
> 2. If all authors are touching all or most modules, we end up with a
> lot more potential conflict management than you might expect from
> modularized ontologies.
perhaps. but if spurious diffs are minimized (as should hopefully happen
with this approach), VCS-level conflicts are rarer.
> That said, we do think that modularization is a good idea. There are
> just some lingering details that we have not worked out.
'lingering details' is probably an understatement :-(
> Anyway, I'm not being contrary, I'm just commenting on the
> difficulties I've encountered. I appreciate your feedback/suggestions
> on this. I can tell from your post that you've given this a great deal
> of thought and effort. I will explore further.
no worries, no contrariness detected, we're all in similar boats here
(though you're in the slightly deeper end as the FMA in OWL is that bit
larger than some of the others). FOr what it's worth, I'd recommend
commenting on some of the Protege/OWLAPI tracker issues, if only to let
people know this is important. A few tickets:
*
https://github.com/owlcs/owlapi/issues/332
*
https://github.com/owlcs/owlapi/issues/375
*
https://github.com/owlcs/owlapi/issues/273