local domain & range, storage and semantics

[dosumis]

Storage

These are currently stored as a space delimited lost of OBO identifier strings. This is horrible to read in any tool and is a pain to maintain. It would be much better if these were maintained as multiple statements, each with a URI as a value. We could then use imports to make sure that labels are displayed in Protege.

What steps would be needed to make this change?

What downsides would there be to it?

(One possible problem is that some terms share names (e.g. many ontologies have a term called cell).

Semantics

In OWL:
R domain D
X R Y => X subClassOf D
To police misuse, we then rely on any assertions of disjointness (or negation if we have it) combined with these inferences => inconsistencies.

Some possible interpretations of local domain and range:

local_domain: D E F
X R Y => X must be an asserted SubClass of (D or E or F) - Throw an error if not? (i.e. closed world interpretation)
X R Y => X subClassOf (D or E or F). To police misuse, we then rely on any assertions of disjointness etc… (although are these as useful given the use of disjunction?)

I would like to add some documentation of the intended meaning to the OWL file these annotation properties live in.

[cmungall]

On 12 Jun 2015, at 6:40, David Osumi-Sutherland wrote:

local_domain: D E F
X R Y => X must be an asserted SubClass of (D or E or F) - Throw an
error if not? (i.e. closed world interpretation)
X R Y => X subClassOf (D or E or F). To police misuse, we then rely on
any assertions of disjointness etc… (although are these as useful
given the use of disjunction?)

The first one seems more closely aligned with intent, and would be
easier to check using the tools where this is more relevant (p2go),
specifying these completely unambiguously due to the lack of a standard
language for both CWA and inference. Using an OPPL-like syntax:

X R Y => ASSERTED(X SubClassOf Z),INFERRED(Z SubClassOf* (D or E or 

F))

Or algorithmically:

If R has local_domain (D E F)
And X R Y
Then:
    foreach A in ReflexiveIsaAncestor(X)
      if A=D or A=E or A=F then Return OK
Return FAIL

The second is valid so we can retain it, although this will likely only
be checked further downstream, e.g. reasoner checks in the GAF pipeline.
Although we have to be careful about context. local_domain/range are
intended in the context of GO annotation extensions. Not sure of the
most elegant way to express this.

[dosumis]

@tonysawfordebi - Any coment on the storage proposal - moving to "multiple statements, each with a URI as a value" ?

If we were to make this move, how much notice would you need? Should we file tickets and if so where?

[dosumis]

Tony uses OBO version. Just checked the OBO conversion. It is very clean, so should be straightforward to parse.

    <owl:ObjectProperty rdf:about="http://purl.obolibrary.org/obo/RO_0002218">
        <go_annotation_extension_relations:local_range rdf:resource="http://purl.obolibrary.org/obo/CL_0000000"/>

->

[Typedef]
id: has_agent
...
property_value: local_range CL:0000000

[dosumis]

@cmungall @hdietze - what GO infrastructure would need to change if we were to store local domain and range as multiple axioms with value = subset URI.

Obviously need to round up all dependencies and then decide a time to switch.

The other issue is cases where terms used in local_range share labels with other terms. The standard way to deal with this is meant to be via OBO foundry uniquename, e.g. the term 'cell' from WBbt would get the OBO foundry uniquename 'C.elegans cell'. We could hack this together locally for the few terms affected, but it would be much better if this could be done through standard pipelines. (This is, of course, a more general issue that GO would benefit from fixing).

[hdietze]

Generic annotation assertions (such as http://purl.obolibrary.org/obo/go/extensions/go_annotation_extension_relations#local_range or http://purl.obolibrary.org/obo/go/extensions/go_annotation_extension_relations#local_domain) and the translation to property_value do not interfere with any of our GO pipeline or scripts.

@dosumis you can go ahead and replace the axioms.

[cmungall]

@dosumis should we create proper IDs for the local_domain/range APs (and map them in the obo using the xref trick?). I think a case could be made for having these in RO (just for centralizing documentation, we wouldn't need to bring them in as part of the module).

[dosumis]

Could do. What's the advantage? My main priority is to make sure the values
are owl class URIs.
On 6 Jul 2015 19:23, "Chris Mungall" [email protected] wrote:

@dosumis https://github.com/dosumis should we create proper IDs for the
local_domain/range APs (and map them in the obo using the xref trick?). I
think a case could be made for having these in RO (just for centralizing
documentation, we wouldn't need to bring them in as part of the module).

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

[cmungall]

Robustness. Current translation may be sensitive to original ontology IRI. But we can cross that bridge when we come to it

[dosumis]

Robustness. Current translation may be sensitive to original ontology
IRI.

Got it. In that case, I agree. Should we just use http://www.geneontology.org/formats/oboInOwl# - as for other OBO APs?

[cmungall]

I'd rather not extend this; my thoughts were to add under here:
http://purl.obolibrary.org/obo/RO_0002422

(the def of the root AP has the clarification "The logical expansion can
yield axioms expressed using any formal logical system, including, but
not limited to OWL2-DL.", I think that loc_d/r can be defined using
macros)

On 7 Jul 2015, at 4:03, David Osumi-Sutherland wrote:

Robustness. Current translation may be sensitive to original ontology
IRI.

Got it. In that case, I agree. Should we just use
http://www.geneontology.org/formats/oboInOwl# - as for other OBO APs?

---

Reply to this email directly or view it on GitHub:
#13 (comment)

[dosumis]

Hmmm... Feels wrong to me to use the RO namespace for an AP that is basically a hack for GO (as I see it, we're really just using it to crudely enforce a set of patterns). If you'd rather have a purl, then what about the GOREL namespace? I'd be happy with that as long as we ensure that it lives in the same file as all other GORELs so that we can avoid stomping on IDs ( GORELs already need consolidating #46).

[cmungall]

I'm ok with GOREL

[dosumis]

Also need to understand how this change will look in OBO as @tonysawfordebi still parsing straight from gorel.obo. Pretty sure http://www.geneontology.org/formats/oboInOwl# + readable shortForm could be used withouth affecting OBO, but this will not be the case if we switch to a purl + GOREL namespace.

[dosumis]

Seeems to work.

AnnotationProperty: rdfs:label
AnnotationProperty: <http://www.geneontology.org/formats/oboInOwl#shorthand>
AnnotationProperty: <http://purl.obolibrary.org/obo/SCRATCH_0098701>
    Annotations: 
        <http://www.geneontology.org/formats/oboInOwl#shorthand> "local_domain",
        rdfs:label "local_domain"@en

Class: <http://purl.obolibrary.org/obo/SCRATCH_0098704>
    Annotations: 
        <http://purl.obolibrary.org/obo/SCRATCH_0098701> <http://purl.obolibrary.org/obo/SCRATCH_0098702>,
        rdfs:label "rab"@en

Class: <http://purl.obolibrary.org/obo/SCRATCH_0098702>
    Annotations: 
        rdfs:label "bar"@en

-- >

[Term]
id: SCRATCH:0098702
name: bar

[Term]
id: SCRATCH:0098704
name: rab
property_value: local_domain SCRATCH:0098702

Clearly wouldn't roundtrip though, which makes me a bit nervous. Is there any way to have the AP have its own OBO Typedef ?