An object property for identifying the component classes of a phyloreference

[gaurav]

We need some way of linking phyloreferences to its component classes in order to ensure that they can be read as RDF in the generated JSON-LD files (see https://github.com/phyloref/phyx.js/issues/78 for context).

I think the best property to use for this would be has_part (obo:BFO_0000050): a component class is certainly a part of a phyloreference, and the phyloreference can't function unless all its component classes are part of the OWL ontology.

Otherwise, we might want to define our own term:

Proposed term: has_component_class Definition: Indicates that the logical expression underlying a phyloreference depends upon a component class that contains some part of that logical expression. A component class may be a sub class of the phyloreference, in which case it represents one possible topology that would satisfy the phyloreference, or it might represent some part of a possible topology that would satisfy the phyloreference. Note that a phyloreference will not resolve correctly unless all of its component classes are included in the reasoner. Domain: Phyloreference Range: owl:Class

Competency questions:

• Which component classes are used to define a particular phyloreference?
• How many component classes represent a part of the logical expression underlying a phyloreference? (This would be those component classes that are not direct sub classes of the phyloreference.)
• Which phyloreferences share component classes?

[hlapp]

So I thought we generate these only at the time we need them for subclass definitions. I.e., they wouldn't have to be recorded in the JSON-LD format, i.e., Phyx. Or do you mean something else here?

We should think hard about whether and how we need these. I don't think the competency questions you listed are meaningful (i.e., they are made up from what having the property might allow answering, rather than driven by questions that need to be answered due to actual supporting use cases or personas). Both domain and range of OWL properties are always individuals, not classes, and using a class as the object anyway introduces punning (i.e., using the same IRI for both an individual and a class).

[gaurav]

So I thought we generate these only at the time we need them for subclass definitions. I.e., they wouldn't have to be recorded in the JSON-LD format, i.e., Phyx. Or do you mean something else here?

Yup, that's right -- this term is only needed in the OWL/JSON-LD representation, and will never appear in a Phyx file. The only reason we need an RDF property here is so that it can be read by RDF readers like Protege and JPhyloRef -- I do believe that has_part (obo:BFO_0000050) will be the best property to use here, but I wanted to document this discussion here in this repository in case there are benefits to defining our own property that I can't see.

We should think hard about whether and how we need these. I don't think the competency questions you listed are meaningful (i.e., they are made up from what having the property might allow answering, rather than driven by questions that need to be answered due to actual supporting use cases or personas).

Agreed! The problem is that this property will only exist in the generated ontologies (the OWL/JSON-LD file), so the competency questions can only really be based on use-cases where somebody is trying to access this information in RDF rather than in Phyx. This is not something we do ourselves (the closest we get is the Open Tree Resolver, which reads OWL/JSON-LD, not RDF), so it's hard to imagine why anybody would want to do this. However, without this property (or some other RDF property, such as has_part), the only way for someone looking only at the RDF to figure out which classes are component classes would be by looking at the IRI (component classes have IRIs in the form #phyloref0_component0), so there are questions that can't be answered without it -- just, as you say, not particularly meaningful ones.

Both domain and range of OWL properties are always individuals, not classes, and using a class as the object anyway introduces punning (i.e., using the same IRI for both an individual and a class).

Ah, I didn't know this! That's interesting. I guess if we do want to create this property, it would need to be an annotation property then?

[gaurav]

We came up with a better solution to this in https://github.com/phyloref/phyx.js/pull/87 -- inserting the component classes directly into the logical expressions or listing them as subclasses of the phyloreference. We therefore no longer need this term. Closing.