Q: Curie expansion by default?

[matentzn]

Should we use curie expansion for all values that correspond to curies with known prefixes? If so, this wont roundtrip (as you cant be sure whether, say, dbxref pointed to a curie or iri originally).

A dbxref 'FB:001' --> A dbxref 'http://flybase.org/reports/'

This is related to your solution presented here, but a bit more general.

Alternative to that is:

1) we treat CURIES as literals, and use a different solution than the one you suggest 2) we make the properties that should be curie expanded configurable (since there now is a config), the default being that they are not expanded. 3) We check whether a value of an annotation assertion looks like a curie (no matter whether its a dbxref or something else), and expand it. That could be slow over large graphs.

I tend to 2) as this is a natural extension to the current config file.

[dosumis]

What's the context for this? Expanding xrefs -> edges?

[matentzn]

no context, just general. You get this:

a dbref "HP:001", what do we do with it?

[dosumis]

Sorry - probably being dense here. What is the source of curies you are expanding?

[matentzn]

Dont worry, lets discuss tomorrow.. :) Will walk you through it

[dosumis]

Penny slowly dropping now I've clicked back to the ticket you linked to.

[dosumis]

Summary of issue:

• We need rules for when and how to expand xrefs.
• This is related to the problem of how we deal with annotation of AP axioms with value: literal. Xrefs on definitions and synonyms are a major source of annotated AP axiom with literal values in VFB (or any other resource loading OBO-ish ontologies). Xrefs on OWL entities ( OwlEntity hasDBXref literal) are not part of this problem.

The simplest generic solution fo annotated AP axioms with literal values is to embed a Neo Map or JSON string in a node value string. This can work for roundtripping. It may be sensible to implement this as the default.

Expanded xrefs will not roundtrip, but could still be used to produce useful OWL derivatives.

If expansion involves generating OWL entity nodes, we need rules for how those nodes will be typed in OWL (Class, Individual, AP, OP, DP) and in Neo (labels needed).

Which xrefs to expand will depend on use case. For some OBO world uses, it might be useful to expand all xrefs to OWL classes following standard expansion rules (GO xrefs_abbs?). This is not a priority as not needed for VFB.

For VFB, all we currently care about are expansion of FlyBase pub links. I agree that we should specify this with a simple config.

Aside - VFB has a separate type of expansion of xrefs, for use in linkouts:

OWL: fu hasDbXref 'DB:ACC'

-> NEO:

(fu)-[:hasDbXref { accession: ACC}]->(s:Site { short_form: DB, link_base: 'http://fu.bar/'})

This second type of expansion is currently driven by custom Python code. It expands for any xref (DB:ACC) for which a site node exists with short_form = DB.

[matentzn]

I was hoping you would not think about this... I have a longish post about this as well, but I want to discuss this in person.

[matentzn]

A ap B [ap X] A sub R some B [ap X] (A sub partof some B [dbxref X])

Solution: (n {iri: 'i', definition: [{value:def2,annotations: [dbxref: [], seeAlso: []] , {value:def3}]})

[matentzn]

Summary of call:

We allow a obo-assumption mode. If mode is active, xrefs on definitions and cross references are handled as a JSON blop consistently using the JSON blob syntax. So, even if we have no axiom annotation, we use JSON blop syntax. The obo-assumption mode is configurable to other properties.

[dosumis]

obo-assumption: xref annotations on definitions and the various flavours of OBO synonym are represented as JSON blobs. This is configurable for any other pairs of APs.

[dosumis]

Fixed/(partial duplicate?)