search

INCATools / dead_simple_owl_design_patterns

A simple system for specifying OWL class design patterns for OBO-ish ontologies.
http://incatools.github.io/dead_simple_owl_design_patterns/
GNU General Public License v3.0
42 stars 5 forks source link

Combinatorial generation from term lists #7

Closed cmungall closed 9 years ago

cmungall commented 9 years ago

The nice thing about DOS-DP (I like this misspelling, in the spirit of WOL :-) is that it makes no assumption about whether we use them to make terms one-at-a-time TG style, en-masse (complete cross product) or something in between. E.g. it would be easy to write some kind of wrapper that made an entire E x Q cross-product from PATO and Uberon (whether it would be wise is another matter...)

I think it would be useful to have more selective generation, and have the source for certain modules in the ontology be small DSL files that are combinations of rules and termsets. This is getting into something tawny might do better, but there may be a case for something that is inbetween tawny and robot templates

For example, what if the transmembrane import template were to have a tag where we could list the transportee classes. The curator adds to this list when they want a new term. This is not a very GO-centric way of working where editors like to live in OE, but in other ontology projects, workflows are often very spreadsheet and term-list-centric.

dosumis commented 9 years ago

On 25 Sep 2015 21:17, "Chris Mungall" notifications@github.com wrote:

The nice thing about DOS-DP (I like this misspelling, in the spirit of WOL :-) is that it makes no assumption about whether we use them to make terms one-at-a-time TG style, en-masse (complete cross product) or something in between. E.g. it would be easy to write some kind of wrapper that made an entire E x Q cross-product from PATO and Uberon (whether it would be wise is another matter...)

The aim is to provide a simple, generic OWL pattern language that non-experts can understand and edit (at least the non logic bits)

I think it would be useful to have more selective generation, and have the source for certain modules in the ontology be small DSL files that are combinations of rules and termsets.

Decision is between this and meeting what we have half-way: terms tagged as using template; script checks match before changing if template updated. Choice might depend on ontology branch.

This is getting into something tawny might do better,

Agree. Have been considering writing a mapping to Tawny. Would go all the way with Tawny, but not convinced that Tawny templates will ever be easy for non-experts to understand.

but there may be a case for something that is inbetween tawny and robot templates

For example, what if the transmembrane import template were to have a tag where we could list the transportee classes. The curator adds to this list when they want a new term. This is not a very GO-centric way of working where editors like to live in OE, but in other ontology projects, workflows are often very spreadsheet and term-list-centric.

Think this should be separate from template.

— Reply to this email directly or view it on GitHub.