Distinguish actual techniques from categories

[gkoum]

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.

[paulmillar]

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

[gkoum]

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.