Closed gaurav closed 3 years ago
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.
Yeah, that would be fine!
Would it make sense to do something similar with internal_specifiers
and external_specifiers
for a phyloref (see https://github.com/phyloref/phyx.js/issues/78#issuecomment-792373978)?
Would it make sense to do something similar with
internal_specifiers
andexternal_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.
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
, 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 https://github.com/phyloref/phyx.js/pull/87). If we do need it, I think the subClassOf approach might be best -- if the example I've provided at https://github.com/phyloref/phyx.js/pull/87#issuecomment-800672052 makes sense, let me know and I'll open an issue for that in the Phyx.js repository.
In PR https://github.com/phyloref/phyx.js/pull/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: