Addphyloref:apomorphy as an annotation property for describing an apomorphy

[gaurav]

In PR phyloref/phyx.js#72, we use an RDF property phyloref:apomorphy to indicate the apomorphy being used to define an apomorphy-based phyloreference. Eventually, we will probably want to turn this into a logical expression that can be determined by OWL reasoners to be identical to apomorphies defined elsewhere (such as in Phenoscape). For now, however, it merely points to some representation of an apomorphy, such as an instance of SIO_010056 ("phenotype") with a natural language definition.

Therefore, I don't think we should define phyloref:apomorphy as an OWL property for now. However, it might be worthwhile to define it as an annotation property, with a definition indicating how it should be used. If so, it might look something like this:

Proposed term: apomorphy (annotation property)
Superclass: None
Definition: The description of an apomorphy, i.e. a character that is unique to a particular clade. Used by subclasses of PhyloreferenceUsingApomorphy (#39) to describe the character being used to define that phyloreference.
See also: PhyloreferenceUsingApomorphy.

Competency questions:

• Which apomorphy is a particular apomorphy-based phyloreference defined by?
• Which phyloreferences are defined by a particular apomorphy?

[hlapp]

I'm not sure why this shouldn't be an object property. We can always create an anonymous instance as the value that only has a label, for example, or other annotation properties describing it.

[gaurav]

Yeah, that would be fine!

Would it make sense to do something similar with internal_specifiers and external_specifiers for a phyloref (see phyloref/phyx.js#78 (comment))?

[hlapp]

Would it make sense to do something similar with internal_specifiers and external_specifiers for a phyloref (see phyloref/phyx.js#78 (comment))?

I think that's more problematic. Their values would be collections, which are awkward to start with in RDF and/or OWL. It would seem more natural to connect TUs via a designated property, and then use a boolean-valued annotation property (is_internal_TU, for example), or a subclass (subClassOf <Internal_TU>, for example) to indicate what they are to be used as. Even that feels a little awkward though, so I'm not sure what a good approach would be.

[gaurav]

I think that's more problematic. Their values would be collections, which are awkward to start with in RDF and/or OWL. It would seem more natural to connect TUs via a designated property, and then use a boolean-valued annotation property (is_internal_TU, for example), or a subclass (subClassOf <Internal_TU>, for example) to indicate what they are to be used as. Even that feels a little awkward though, so I'm not sure what a good approach would be.

Good point about collections being awkward in RDF and OWL. I think we should ignore internal_specifiers and external_specifiers in RDF for now (I've removed them in PR phyloref/phyx.js#87). If we do need it, I think the subClassOf approach might be best -- if the example I've provided at phyloref/phyx.js#87 (comment) makes sense, let me know and I'll open an issue for that in the Phyx.js repository.