Skip to content

Redefinition of SAREF Core classes in SAREF4ENVI with same local name

In saref-portal#39 (closed) @garciacastro wrote:

Some classes from SAREF core are specialized in SAREF4ENVI.

In some cases, these subclasses use the same local name as the one used in SAREF core.

Maxime is against any specialization with the same local name such as s4agri:Device. He considers that this would be really confusing for the end users.

I see that two situations appear in the extensions:

  1. The specialization describes a new type of device. E.g., SAREF4WEAR that defines Wearable. We may have cases where we need to update the extension (e.g., could s4ener:Device be s4ener:Appliance?).
  2. The specialization is due to needing further restrictions on the SAREF core class, that are not in SAREF core but do not define a new type of Device. E.g., stating that a device is a geospatial feature. In some cases, these restrictions appear in SAREF core and can be removed from the extension (e.g., SAREF4ENVI), but until they appear there they have to be included in some class. In this case I would prefer to create the subclass with the same name; if not, we will create fictitious types (e.g., EnvironmentDevice, WearableMeasurement, etc.) which may not be good for understandability and usability.

@lefranois then wrote:

Having same local name in different ontologies is confusing (agreed: @bouter @lefranois )

Proposal: Agreed by @bouter @lefranois @garciacastro

  1. Extensions should not hijack SAREF entities (e.g., define new local restrictions on SAREF Core classes, or define new domain and ranges on SAREF Core properties). (it would good to have actual examples of this)
  2. Ideally, when developing an extension, if some new entity or axiom would be relevant for other extensions as well, the developers should open an issue on SAREF Core and propose to include them in SAREF Core.
    1. if the entity or axiom is generic enough and the SAREF team of developers accepts to include it in SAREF, a new version should be published.
    2. if they are not accepted, see point 3 below.
  3. If needed, the SAREF Core classes and properties may be specialized. In such cases, a different local name should be used.
  4. SAREF extensions should not define that existing SAREF Core classes are sub-classes of some other class.

For example: add a new property :firmwareVersion to saref:Device . The extension developer may define saref:Device as the domain of :firmwareVersion . It shall not add local restrictions to saref:Device.

And:

  • s4envi:Actuator is unrelated to saref:Actuator. It is defined as a sub-class of s4envi:Device with a universal restriction on s4envi:affectProperty to link to saref:Property.
  • s4envi:Device is a subclass of saref:Device, with additional restrictions for the specific use cases addressed in SAREF4ENVI:
    • has a frequency measurement which is of type s4envi:FrequencyMeasurement
    • has a transmission period which is of type s4envi:TransmissionPeriod
Edited by Maxime Lefrançois