Open gkoum opened 6 months ago
I completely agree that this is an issue.
If I've understood correctly, I tried to describe the same (or perhaps, a similar) issue earlier, in issue #72 ... although, that issue is less eloquently expressed.
Could you give a concrete example of how this isCategory
would work?
Although I don't fully understand the approach, I fear that it might require all classes to be annotated with some isCategory
value.
An alternative approach might be to have a class that represents the "set of all actual techniques". For the sake of simplicity, let's call this set of all actual techniques the class ActualTechnique
.
We would update PaNET so that each of the most abstract PaNET terms that is an "actual technique" would be a subclass of the ActualTechnique
class.
Subsumption relationships (RDFS entailment) mean that any more specific technique is automatically also a subclass of the ActualTechnique
class, so is automatically identified as an "actual technique".
In the following example, both X-rayPowderDiffraction
and PowderDiffraction
are identified as actual techniques, while AtomicScaleDiffraction3dVolume3dPeriodic
and AtomicScaleDiffraction3dVolume
are not.
X-rayPowderDiffraction isA PowderDiffraction isA ActualTechnique
PowderDiffraction isA AtomicScaleDiffraction3dVolume3dPeriodic
AtomicScaleDiffraction3dVolume3dPeriodic isA AtomicScaleDiffraction3dVolume
Since (I imagine) most new terms will be a specialisation of some existing "actual technique", this automatic identification would be a desirable feature of this approach. For example, adding a new kind of x-ray powder diffraction would be a new subclass of X-rayPowderDiffraction
, so inheriting membership of ActualTechnique
from PowderDiffraction
.
One possible disadvantage of this approach is that we can't do the same trick for the categories, at least not currently. The problem is that categories also use subsumption relationships to identify matching actual techniques; for example,
X-rayPowderDiffraction isA X-rayProbe isA PhotonProbe
PhotonProbe isA DefinedByExperimentalProbe
If DefinedByExperimentalProbe
were a subclass of TechniqueCategory
then X-rayProbe
would also be a subclass of TechniqueCategory
:-(
However, we could changed this selection to a different relationship (let's call the relationship characterisedBy
), we would get the following:
X-rayPowderDiffraction characterisedBy X-rayProbe
X-rayProbe isA PhotonProbe
PhotonProbe isA DefinedByExperimentalProbe
Then we could have a class TechniqueCategory
(for example) that could be a superclass of DefinedByExperimentalProbe
. All subclasses of DefinedByExperimentalProbe
would then be identified as being more specific classes of TechniqueCategory
.
X-rayPowderDiffraction characterisedBy X-rayProbe
X-rayProbe isA PhotonProbe
PhotonProbe isA DefinedByExperimentalProbe
DefinedByExperimentalProbe isA TechniqueCategory
Similarly, we could also use this to identify AtomicScaleDiffraction3dVolume3dPeriodic
and AtomicScaleDiffraction3dVolume
as technique categories; e.g.,
X-rayPowderDiffraction isA PowderDiffraction isA ActualTechnique
PowderDiffraction characterisedBy AtomicScaleDiffraction3dVolume3dPeriodic
AtomicScaleDiffraction3dVolume3dPeriodic isA AtomicScaleDiffraction3dVolume
AtomicScaleDiffraction3dVolume isA TechniqueCategory
I totally agree that you can tell apart the actual techniques by just making them a subclass of a class like the ActualTechnique
you suggested. If you do that you don't even need to annotate the way I suggested the categories since these are the ones that are not ActualTechnique
: !ActualTechnique
.
For the other definition you propose using object properties I also agree but we better not use something so general as characterisedBy
since object properties should be used as if we would use the classes and the object property to write a sentence.
Below is how we will use object properties in ESRF ontology to define a class:
XRF: X-ray Fluorescence Spectroscopy
Definition:
experimental_technique
and (detectsPhenomenon some fluorescence)
and (hasDetectionMode some energy_dispersive_detection_mode)
and (hasProbe some x-ray)
For the above we also have some classes like Phenomenon
, DetectionMode
etc that are used for the domain and range
of our object properties. Adding object properties instead of the isA relationship is the way forward I think but then we break the taxonomial structure of PaNET as well.
Techniques that will actually be used in associating them to beamlines and publications can be distinguished from concepts helping us to create the PaNET taxonomy. This does not mean that the more general concepts cannot be used but more specific ones should be preferred. This can again be accomplished with a dataType property "isCategory" for those used to create our main branches in the taxonomy but are not specific enough.