Closed gaurav closed 5 years ago
Especially for new properties (because property reasoning expressivity is quite limited), I'd like to ask for a supporting use case. More specifically, in ontology development terminology, a competency question (e.g., see Ren et al). I.e., in common language, present one or more questions that we should arguably care about for an application of this ontology, and that to be answered through a DL or SPARQL query need this property, as opposed to another one that we already have and that would arguably be the superproperty of the proposed one. For example, has_external_ref
.
I've tried adding competency questions to this property as well as #7 -- let me know if they make sense!
I don't think there's a relation between this term and has_external_ref
. To my mind, this term is more like a part of the definition encoded in the phyloreference, while has_external_ref
asserts that a taxonomic unit can be referred to by another URL (which makes it a bit like skos:closeMatch). What do you think?
I've edited the competency questions slightly to make it clear that the property carries additional (and important) semantics on top of the object type (or range constraint, if there were to be one, which, with the given label, there arguably should be).
I'm skeptical of the argument that there's no suitable superproperty. How about asking which specifiers are used by a given phyloreference. (A specifier matching method will likely start with this question, won't it?) Shouldn't there be a simple property answering that, rather than having to combine results from querying several (even if only 2) different properties?
I've edited the competency questions slightly to make it clear that the property carries additional (and important) semantics on top of the object type (or range constraint, if there were to be one, which, with the given label, there arguably should be).
Yes, there are definitely semantics being expressed here. Those competency questions sound good!
I'm skeptical of the argument that there's no suitable superproperty. How about asking which specifiers are used by a given phyloreference. (A specifier matching method will likely start with this question, won't it?) Shouldn't there be a simple property answering that, rather than having to combine results from querying several (even if only 2) different properties?
I think there are two possible views of the relationships between phyloreferences and taxonomic units that we might be interested in here:
In the phyloreference definitions, we need to identify the cdao:Nodes that the phyloreference should resolve to based on their ancestral relationships. For example, a phyloreference may resolve to a Node if the Node cdao:has_Descendant some (represents_TU value ncbitaxon:Homo_sapiens) and cdao:has_Descendant some (represents_TU value ncbitaxon:Ornithorhynchus_anatinus)
. Note that the taxonomic units can be as complex as needed, and may include verbatim descriptions, scientific names, taxon concepts or specimens. For this purpose, we don't need explicit has_internal_specifier/has_external_specifier
properties.
In the PHYX file, we'd like to record which specifiers were provided in the clade definition. For example, we might want to record that a phyloreference phyloref:has_internal_specifier ncbitaxon:Homo_sapiens
and phyloref:has_internal_specifier ncbitaxon:Ornithorhynchus_anatinus
. I do like that this is more human readable than the format above, but I'm not sure that it adds anything for machines that they can't get from the representation above. It might be cleaner for curators to record specifier-level annotations, but I suspect we'll still be able to do that at the taxonomic unit level if need be.
If we use only representation 1 above, we can eliminate the has_external_specifier
and has_internal_specifier
properties entirely and identify them by looking for specifiers/taxonomic units that are the object of a cdao:has_Descendant
or phyloref:excludes_lineage_to
clauses in the class expression. What do you think?
If we do decide we want an has_external_specifier
term, here are some possible candidates for superproperties from Ontobee:
inheres in
the phyloreference, since it doesn't have an independent existence outside of the phyloreference. We then match them to taxonomic units (which arguably inhere in nodes on a phylogeny) by using entities that do have independent existence, such as taxa or specimens.RO:contains
(RO_0001019) which might work well as a superproperty. Unfortunately, this term is used to describe independent continuants containing material entities, as per the definition of its inverse property. For example, UBERON uses it in definitions such as pituitary fossa subClassOf: contains some pituitary gland
.
contains
as a superproperty for has_internal_specifier
, i.e. :phyloref1 ro:contains ncbitaxon:Homo_sapiens
and (if possible) we could use not ro:contains
as the superproperty of has_external_specifier
.has
property (CDAO_0000178), but I don't think that would convey any semantic meaning if we were to use it as a superproperty.exclude
(CDAO_0000161), which acts as a superproperty for two properties: exclude_Node
and exclude_Subtree
. CDAO uses these in its definitions of PolyphyleticGroup
(which excludes some Node) and ParaphyleticGroup
(which excludes some subtree). Given those uses, I think they mean that the group excludes some descendant nodes or subtrees, rather than our use of the term to mean specifiers/taxonomic units that must be excluded from the clade. So I don't think this would make a good superproperty.Possibly related properties that I don't think apply here include RO:part_of
(BFO_0000050), RO:has derived by descendant
, and RO:determined by (system to material entity)
.
So, I think maybe inheres to
is our best bet? Let me know if there are other sources of published OWL terms I could look into!
It just struck me that maybe you just meant that we should have a has_specifier
superproperty for has_internal_specifier
and has_external_specifier
? In which case, yes, we can! I'll wait until we resolve the future of specifiers over in #5 before proposing that one though.
At our phone meeting this week, @hlapp and I decided that we should try to read internal and external specifiers directly from the property restriction used in a phyloreference. In order to do this:
clause 1 and clause 2 and ...
).cdao:has_Descendant some X
(indicating an internal specifier of X) or in the form phyloref:excludes_lineage_to some Y
(indicating an external specifier of Y). Restrictions not in this form cannot be classified as either internal or external specifiers, and cannot be displayed in a tool like the Curation Tool which is designed with those two specific cases in mind.X
and Y
in the previous example must resolve to cdao:Nodes. They will most likely represent taxonomic units, for example: cdao:represents_TU value ncbitaxon:Homo_sapiens
.We will test this in either the Clade Ontology or the Curation Tool. If this works, we can close #5 and #7.
In the Phyloref ontology revision in #29, this has given rise to phyloref:excludes_TU
. This would be the property used for expressing this part of a phyloreference (as a class expression). The reasoner also infers phyloref:excludes_TU
from excludes_lineage_to o represents_TU
.
The conclusion underlying this is that in reality almost all (or all?) clade definitions in the wild reference taxon concepts (instances of cdao:TU, formalized further in #28) for exclusion and inclusion. I.e., at least for the purposes of phylogenetic clade definitions, there is no discernible difference between a specifier and it being a referent to a corresponding taxon concept.
Here's an example using the proposed model:
ObjectSomeValuesFrom(phyloref:excludes_TU
ObjectSomeValuesFrom(tc:hasName
ObjectIntersectionOf(
ObjectHasValue(tn:nomenclaturalCode tn:ICZN)
DataHasValue(dwc:scientificName "Caiman crocodilus"))))
where tc
and tn
are the TDWG TaxonConcept and TaxonName vocabularies (see #28).
So I would argue that we've brought this to conclusion.
Done. Implementation will take place as part of phyloref/phyx.js#4.
Proposed term:
has_external_specifier
(object property) Definition: Associates an external specifier with a phyloreference. Domain: Phyloreference Range: Specifier Potential superproperties: none See also: scratch ontology, PHYX contextCompetency questions: