[New metadata element]: `sparql_expansion`

[matentzn]

Element id (e.g. creator_id, mapping_tool_version): (Must be lower case and contain only letters and underscores.)

sparql_expansion

Value data type (e.g. URI, URL, text, xsd:boolean):

xsd:string

Description

A SPARQL expansion in line with the specification provided by ROBOT expand. A sparql query is defined which binds to subject_id, object_id, predicate_id and predicate_modifier, and than expands to a construct, see example below.

Example

"""
   CONSTRUCT { 
      ?subject_id rdfs:subClassOf [
               owl:onProperty ?predicate_id ;
               owl:someValuesFrom ?object_id ]
   } WHERE { 
      ?subject_id ?predicate_id ?object_id 
   }""" 

This expands the mapping (?subject_id ?predicate_id ?object_id) in the SSSOM table to the complex RDF expression in the CONTRUCT clause.

You can imaging more complex examples, including taxon constraints (expanding skos:exactMatch to owl:subClassOf(?subject,?object_id and ro:part_of some ncbitaxon:human) for cross species matches for example.

Notes

• In the original expand proposal, the WHERE clause is explicit. Here, this is not so relevant, as the where clause is always the same (a SPARQL match of ?subject_id, ?object_id, ?predicate_id and ?predicate_modifier. I would suggest we reduce the value space just to a construct.
• Another idea is to keep the WHERE clause and allow expansions into arbitrary languages, including OWL class expressions, Common Logic, SPARQL. You could the prefix the actual value of the expansion like sparql:CONSTRUCT { ...} and owl:subClassOf(...). Not sure if we would ever support that in the sssom toolkit, bit we could keep this open.
• This property serves a niche use case that will probably not be used very much other by specialised groups - but it is needed for some use cases and can cover quite a lot of sub-problems of #36 (not all).
• The advantage of this is that we can keep mappings themselves simple (still correct), and power users may chose to expand the mappings automatically with standard toolkits into the form they need.
• This does not at all address the issue of multiple subjects to one object (eg Uberon:head + in:Mouse=MA:head). This is harder to solve as you need to somehow mind multiple ids. Difficult, I don't think that needs to be discussed here.