mapping-commons/sssom

Inverse mappings

Opened this issue · 7 comments

cmungall commented

I have seen some SSSOMs in the wild with a predicate field that contains a property expression, e.g. inverseOf(P). Should we standardize this?

Note I'd prefer to use SPARQL syntax, e.g. ^ for inverted predicate

See also biolink/biolink-model#440

The other option is to have an explicit field such as invert: boolean, but the danger is that this is ignored and we get the wrong semantics

matentzn commented

I totally forgot this was an open ticket;

Note that I am using sssom:superClassOf in COB:
https://github.com/OBOFoundry/COB/blob/master/cob-to-external.tsv

cmungall commented

So our strategy is to always force naming of expressions?

We will need a notEquivalentTo (note this is distinct from owl:differentFrom which induces punning)

It may be useful to differentiate subClassOf from properSubClassOf. One way is by expressions like subClassOf+ (which the reflexive case being subClassOf* or (subClassOf|equivalentTo)

If we could have a stricter probability field this would obviate the need for named predicates / expressions for complementOf (this would be distinct from confidence; having low confidence that A=B is not the same as high confidence A!=B)

matentzn commented

Hmm... as I said on slack, I am not that keep on having such expressions in sssom, as this introduces a burden for a naive treatment of the tsv files (without sssom-py). Doesnt it make it hard to interpret the file? What should someone do that just downloads a tsv and wants to ingest it into their KG (its trivial to load sssom.tsv with a generic LOAD CSV in neo4j, for example, which this extension here would make kind of hard..).

Lets say we add sssom:properSubClassOf -> what does this mean for the rdf serialisation? What other relations would be needed?

I am not sold either way yet, just wondering...

cmungall commented

I hear you, not sold either way either

My thought was that naive treatments can continue to be naive and just pass things on, treat the expression as a named predicate

matentzn commented

So we will allow class expressions in any case on the subject and object_ids. Maybe we can allow this for predicate_id as well.

I think we can safely allow these:

  • sssom:superClassOf
  • inverseOf(owl:subClassOf) (sssom:superClassOf being a specific instance of this that is useful, because so often used)

Now these are a-whole-nother matter:

  • sssom:notEquivalentTo
  • sssom:properSubClassOf
  • sssom:properSuperClassOf

In owl, they wont mean anything. The latter two would end up to be rdfs:subClassOf axioms, which are indistinguishable from the normal (non"proper") case. I am very keen to have all of SSSOM translation preserve OWL semantics.. :/

Note that sssom:notEquivalentTo cannot be translated at all (at least not for tbox, for abox you could slot in owl:differentIndividuals).

Now with regards to this:

  • subClassOf+ (which the reflexive case being subClassOf* or (subClassOf|equivalentTo)

Hmmm.. It will be so complicated to reason mentally over the sssom files.. I was a bit kinda sympathetic to say ok to property chains (inheres-in o partof), but reflexive and non reflexive relations? I don't know. Maybe lets keep this as a research project until we have a compelling use case mapped out for this..

cmungall commented
cmungall commented