variables with cardinality other than 1

[cmungall]

Can be separated into two distinct cases:

1. optional variables
2. card>1

For the first, in principle nothing need be done, as you can always fill in owl:Thing. However, although semantically fine, the resulting OWL is structurally unusual (could in principle be reduced to a simpler expression - standard libraries for this with the OWLAPI?). The textual generation would also be super-weird.

The 2nd case is harder. As we use a purely syntactic macro language it's hard to auto-detect how to generalize to cardinality of N. The best way may be to extend the syntax, e.g.

equivalentTo: %s and {{has-part some %s}}
vars:
   - genus
   - component

Where component is cardinality of *.

obviously this complicates implementing code, and is scope creep to a full templating language, and it's not clear that is the way we want to go (but if it is, better to use off-the-shelf, e.g. mustache? one that allows logic? multi-language support is key)

[dosumis]

Do you have some example cases where you want this?

Simplicity could be maintained simply by increasing the number of patterns. The worry then, of course, is keeping consistency between patterns. In my initial implementation, I played with having an (object) class hierarchy of patterns, with subclasses extending parent class by adding more clauses. Decided simplicity was better. It strikes me that we could generate class hierarchy of patterns by using them all to generate OWL in which the variable slots were filled by Thing (or by the class specified in the var range). This would allow us to easily keep track of and browse through related patterns.

[simonjupp]

We have two cases like this for both annotations and logical axioms. OPPL was quite powerful for this (although poorly documented)

1.We use this pattern for adding synonyms where if you instantiate synonym with a collection of values OPPL would create one axioms each.

?cellLine:CLASS,
?synonym:CONSTANT
BEGIN
ADD ?cellLine.IRI alternative_term "?synonym"
END;

1. There was also some built in functions in OPPL that we use for instantiating patterns like this where you have multiple parts

?cell:CLASS, 
?anatomyPart:CLASS, 
?partOfRestriction:CLASS = part_of some ?anatomyPart,
?anatomyIntersection:CLASS = createIntersection(?partOfRestriction.VALUES) 
BEGIN
ADD ?cell equivalentTo CL_0000000 and ?anatomyIntersection
END;

I wonder if some similar kind of nested variable could also be used

equivalentTo: %s and %s
vars:
   - genus : "Thing"
   - component : 'has-part some %s'

Would also be useful to be able to distinguish between creating a union or intersection of objects.

[cmungall]

Do you have some example cases where you want this?

PRO/complex-type use cases come to mind (not that they are using this, but they probably should)

I'm mostly just thinking ahead

Simplicity could be maintained simply by increasing the number of patterns. The worry then, of course, is keeping consistency between patterns.

Yes, especially if you get hit by the combinatorics, if you have N optional vars then that's 2^N patterns. Maybe at that stage you should be reconsidering if precomposition is right for you, but still good to be prepared.

Also for unbounded cardinality having M patterns where M is an arbitrary cutoff and patterns named complex-with-X-parts is a bit unsatisfactory.

(and just to stress, what is great about dosdps is the simplicity, this may be a perfectly acceptable tradeoff, as you say)

[cmungall]

@simonjupp I like your nesting idea. This could be extended to cover the reaction use case. Here each variable value could be an object rather than scalar. E.g. the input would be something like:

left:
  - stoi: 2
    chem: CHEBI:1234
  - stoi: 1
    chem: CHEBI:4567
right:
 ...

This could I think be done purely as a compatible extension to the existing yaml

[dosumis]

Still resisting the added complexity here. May reconsider once a more extensive implementation of DOSDPs for GO is in place and we can review use cases.

The full complexity of mustache would result in something far from simple, but it looks like adopting some parts of mustache (e.g. {{}} for optional ?) could be a good way to go for this. However, there's a serious danger of even this becoming hard to work with reliably when used to auto-generate text.

[dosumis]

This was fixed by #71