saref4bldg issueshttps://labs.etsi.org/rep/saref/saref4bldg/-/issues2024-03-20T15:34:22Zhttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/32Moving Measurement to PropertyValue2024-03-20T15:34:22ZMauro DragoniMoving Measurement to PropertyValueWhile addressing Issue #7, I noticed that, given the patterns provided in TS 103 548 and the updated definitions provided in SAREF Core v4.1.1, the `Measurement` concept is deprecated.
Hence, I suppose that the deprecation of all usages ...While addressing Issue #7, I noticed that, given the patterns provided in TS 103 548 and the updated definitions provided in SAREF Core v4.1.1, the `Measurement` concept is deprecated.
Hence, I suppose that the deprecation of all usages of the `Measurement` concept should be propagated to all extensions and replaced with the adoption of the `PropertyValue` concept as shown in Clauses 5.2.2.2 and 5.6.4 of TS 103 548.
However, there are a couple of aspects that made me doubtful about how to proceed.
Let me use this example, the definition of the `VibrationIsolator` concept:
```
s4bldg:VibrationIsolator rdf:type owl:Class ;
rdfs:subClassOf saref:Device ,
[ rdf:type owl:Restriction ;
owl:onProperty s4bldg:height ;
owl:allValuesFrom saref:Measurement
] ,
[ rdf:type owl:Restriction ;
owl:onProperty s4bldg:isolatorCompressibility ;
owl:allValuesFrom saref:Measurement
] ,
[ rdf:type owl:Restriction ;
owl:onProperty s4bldg:isolatorStaticDeflection ;
owl:allValuesFrom saref:Measurement
] ,
[ rdf:type owl:Restriction ;
owl:onProperty s4bldg:supportedWeightMax ;
owl:allValuesFrom saref:Measurement
] ,
[ rdf:type owl:Restriction ;
owl:onProperty s4bldg:vibrationTransmissibility ;
owl:allValuesFrom saref:Measurement
] ;
[the labels and comments are omitted]
```
Since the concept `Measurement` is deprecated in favor of the adoption of the `PropertyValue` one, my doubts, after checking also the TS 103 548, are the following.
Doubt 1:
Is it enough to replace `saref:Measurement` with `saref:PropertyValue` in the concepts' definition like the one shown above?
I guess that the answer is **No** because in this case, we should also re-define the properties (e.g., `supportedWeightMax` as a subclass of `hasPropertyValue`, but this operation is forbidden due to what is explained in Clause 5.6.5 of TS 103 548.
Doubt 2:
Is it necessary to define subclasses of `saref:PropertyValue` by starting from the property names like the ones shown above?
This means that, for example, the block with `supportedWeightMax` would be updated as follows:
```
[ rdf:type owl:Restriction ;
owl:onProperty saref:hasPropertyValue ;
owl:allValuesFrom s4bldg:supportedWeightMax
] ,
```
where `s4bldg:supportedWeightMax` would be a subclass of `saref:PropertyValue`.
Probably, this second option is the more correct.
Please let me know what do you think.V2.1.1_stableMaxime LefrançoisRaul Garcia-CastroMaxime Lefrançoishttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/31Property Values2024-02-29T12:40:16ZMauro DragoniProperty ValuesSAREF4BLDG links a feature of interest to a measurement first, which is then linked to the value and the property kind. It could be simpler to link features of interest directly to a property value.
The class s4auto:Movement contains fi...SAREF4BLDG links a feature of interest to a measurement first, which is then linked to the value and the property kind. It could be simpler to link features of interest directly to a property value.
The class s4auto:Movement contains five instances such as s4auto:crossingLeft and s4auto:crossingRight. These may be considered different possible values for the property s4auto:Movement. Their modelling could be updated in harmonization with the modelling of postures in SAREF4EHAW.
SAREF4EHAW defines one sub-class of saref:Property, s4ehaw:Posture, which has five instances such as s4ehaw:Walking. These may be considered different possible values for the property s4auto:Posture, which should be modelled as an instance of saref:Property. Their modelling could be updated in harmonization with the modelling of postures in s4auto:Movement.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/30Proper reuse of PROV-O2024-02-29T12:40:14ZMauro DragoniProper reuse of PROV-OSAREF4AGRI uses the W3C Provenance ontology (PROV-O). It declares prov:hadPrimarySource as an AP, while in PROV-O this entity is declared as an OP. This may induce inconsistencies. Furthermore, this entity is not used anywhere else in SA...SAREF4AGRI uses the W3C Provenance ontology (PROV-O). It declares prov:hadPrimarySource as an AP, while in PROV-O this entity is declared as an OP. This may induce inconsistencies. Furthermore, this entity is not used anywhere else in SAREF4AGRI. It may be deleted.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/29Use of SKOS in extensions2024-02-29T12:40:16ZMauro DragoniUse of SKOS in extensions
In SAREF4CITY, the accessibility of the event (s4city:hasAccesibility - contains a typo) is only provided as skos:Concept. A concept scheme should be provided or linked to.
SAREF4INMA redefines and specializes the class skos:ConceptSch...
In SAREF4CITY, the accessibility of the event (s4city:hasAccesibility - contains a typo) is only provided as skos:Concept. A concept scheme should be provided or linked to.
SAREF4INMA redefines and specializes the class skos:ConceptScheme from the W3C Simple Knowledge Organization System (SKOS) vocabulary. It considers that s4inma:ID is a sort of concept scheme, like taxonomies, thesaurus, etc.
SAREF4AGRI uses the W3C Simple Knowledge Organization System (SKOS) ontology. It declares skos:definition and skos:prefLabel, but do not use them elsewhere in the ontology. These declarations could be deleted.
The class of s4watr:WaterUse is populated by a set of instances. Many occurrences of such as pattern are found in other extensions. This could be a candidate for defining a pattern where skos:Concept and skos:ConceptScheme may be used.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/28Position as property ?2024-02-29T12:40:16ZMauro DragoniPosition as property ?The class s4city:Event describes temporal and scheduled events organized by some agent, that take place at a certain time and at a certain facility. This class discards events that take place in a moving facility such as buses or boats. ...The class s4city:Event describes temporal and scheduled events organized by some agent, that take place at a certain time and at a certain facility. This class discards events that take place in a moving facility such as buses or boats. The position of moving facilities could be considered a saref:Property, and be measured by devices.
OP s4auto:detectsPosition links a device to the position it can detect. If positions were modelled as properties, this OP could be replaced by saref:measuresProperty. Similarly, OPs s4auto:hasDestination, s4auto:hasPosition, s4auto:hasOrigin, s4auto:hasEstimatedRendezvousLocation, could all be modelled as subproperties of saref:hasProperty, or as instances of saref:Property (with some renaming). By the way, the same position could be measured or evaluated in different ways: absolutely with a latitude and a longitude, relatively to some point of interest, or relatively to some other point of interest.
OP s4agri:isLocatedIn applies for example to s4agri:Animal or s4agri:AnimalGroup to express the physical location of the entity. As such, the location of the animal cannot change. It may be useful to model the location of an entity using a saref:Property, that can be measured.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/27DPs with enumerated values are objects in SAREF4BLDG2024-02-29T12:40:15ZMauro DragoniDPs with enumerated values are objects in SAREF4BLDGIn SAREF4BLDG, some of the DPs seem to accept enumerated values as objects, but these are only defined in the comment (ex. s4bldg:refrigerantClass) or not defined at all (ex. s4bldg:pipeConnectionEnum). They could therefore be modelled f...In SAREF4BLDG, some of the DPs seem to accept enumerated values as objects, but these are only defined in the comment (ex. s4bldg:refrigerantClass) or not defined at all (ex. s4bldg:pipeConnectionEnum). They could therefore be modelled following a common pattern to be decided for the whole SAREF. For example, as an OP with as a range a sub-class of skos:Concept.
Also, some of the DPs (19) have a local name that ends with “type”. This may be considered as a bad naming choice as types are usually modelled as classes in OWL. Some DPs explicit the expected values (ex. s4bldg:circuitType), other do not (ex., s4bldg:integratedLightingType).V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/26Strange pattern for DPs in SAREF4BLDG2024-02-29T12:40:15ZMauro DragoniStrange pattern for DPs in SAREF4BLDGSAREF4BLDG introduces many DPs, with no domain and a XSD Datatype as a range (xsd:string (53), xsd:boolean (18), or xsd:integer (9), xsd:nonNegativeInteger (1)).
SAREF4BLDG defines architectural ODPs that, given a DP p typically applied...SAREF4BLDG introduces many DPs, with no domain and a XSD Datatype as a range (xsd:string (53), xsd:boolean (18), or xsd:integer (9), xsd:nonNegativeInteger (1)).
SAREF4BLDG defines architectural ODPs that, given a DP p typically applied to a Class c with a certain datatype d, defines this DP with a range d, and a universal restriction on c that all values for p are d. In other words, declared sub-classes of s4bldg:Device have universal local restrictions on these DPs, and re-state the datatype is always what it should be. For example:
⊤ ⊑ ∀ s4bldg:frameSize . xsd:string
s4bldg:ElectricMotor ⊑ ∀ s4bldg:frameSize . xsd:string
This second axiom is useless and could be deleted to avoid redundancy.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/25Decoupling kinds of evaluations and kinds of properties2024-02-29T12:40:15ZMauro DragoniDecoupling kinds of evaluations and kinds of propertiesFrom TR 103 781:
SAREF4BLDG introduces many OPs that are used in universal restrictions on devices or physical objects to link to measurements, for example s4bldg:flowCoefficient, s4bldg:faceArea, etc. Other ontologies would introduce i...From TR 103 781:
SAREF4BLDG introduces many OPs that are used in universal restrictions on devices or physical objects to link to measurements, for example s4bldg:flowCoefficient, s4bldg:faceArea, etc. Other ontologies would introduce instances of saref:Property in place of these OPs. Some harmonization is required.
Some of these OPs actually represent different kinds of measurements/evaluations for the same property. For example, s4bldg:airFlowRateMax, s4bldg:airFlowRateMin, s4bldg:nominalAirFlowRate, s4bldg:primaryAirFlowRateMin, s4bldg:primaryAirFlowRateMax, s4bldg:secondaryAirFlowRateMin, s4bldg:secondaryAirFlowRateMax.
Some of these OPs actually represent the same kind of measurement for different properties. For example:
- s4bldg:operationTemperatureMax, s4bldg:outletTemperatureMax , s4bldg:pumpFlowRateMax link to a measurement of the maximal allowable value for the property.
- s4bldg:fluidFlowRateMax, s4bldg:powerOutputMax, s4bldg:supportedWeightMax link to a measurement of the maximal possible value for the property.
- s4bldg:nominalSupplyVoltage, s4bldg:nominalPressureDrop, s4bldg:nominalPowerRate link to a measurement of the nominal value for the property.
Some of these OPs actually contain the name of the type of saref:FeatureOfInterest it is applies to. For example, s4bldg:basinReserveVolume, s4bldg:bladeThickness, s4bldg:coilLength, s4bldg:coilWidth, (different properties for the same type of feature of interest), s4bldg:electricMotorEfficiency, s4bldg:electricGeneratorEfficiency (same property for different types of feature of interest).
SAREF4INMA defines an architectural ODP that consists in sub-classing s4inma:Measurement to specify the kind of measurement that is performed: s4inma:ActualMeasurement and s4inma:ExpectedMeasurement. Both subclasses end with string “Measurement” (naming ODP pattern). This could be generalized for other types of measurements such as temporal or logical aggregates, like “MinimumMeasurementOverTemporalInterval”, etc.
**Proposal:** separate the hierarchy of features of interest, the taxonomy of property kinds, and the taxonomy of evaluation kinds. As an initial list, the latter could contain:
- maximal allowable value
- maximal possible value
- nominal valueV2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/24PhysicalObject in SAREF ?2024-02-29T12:40:15ZMauro DragoniPhysicalObject in SAREF ?From TR 103 781:
There is:
- Class s4envi:PhysicalObject, aligned with the DUL top-level ontology.
- Class s4bldg:PhysicalObject, aligned with the DUL top-level ontology. Exact same definition as in SAREF4ENVI, but different axiomatiza...From TR 103 781:
There is:
- Class s4envi:PhysicalObject, aligned with the DUL top-level ontology.
- Class s4bldg:PhysicalObject, aligned with the DUL top-level ontology. Exact same definition as in SAREF4ENVI, but different axiomatization:
s4envi:PhysicalObject ⊑ ∀ s4envi:isContainedIn . s4envi:PhysicalObject, while
s4bldg:PhysicalObject ⊑ ∀ s4bldg:isContainedIn. (s4bldg:PhysicalObject ⊔ s4bldg:BuildingSpace)
- SAREF4INMA reuses s4bldg:PhysicalObject
- OP s4bldg:contains has a different definition than s4envi:contains.
- OP s4bldg:isContainedIn has a different definition than s4envi:isContainedIn.
SAREF4INMA reuses some classes from SAREF4BLDG such as s4bldg:Building, s4bldg:BuildingSpace, s4bldg:PhysicalObject, and specialize them as s4inma:Factory, s4inma:Area, s4inma:Site, s4inma:ProductionEquipment.This is a case for promoting some of the most generic SAREF4BLDG concepts to SAREF Core.
Proposal:
1. promote saref:PhysicalObject to SAREF Core.
2. explicit that saref:Device is a subclass of saref:PhysicalObject.
Open question: should saref:FeatureOfInterest be a subclass of saref:PhysicalObject ? I assume this would be too restrictive.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/23Spatial ontologies2024-02-29T12:40:15ZMauro DragoniSpatial ontologiesFrom TR 103 781:
- SAREF4ENVI uses the W3C Basic Geo Vocabulary. It copies the definition of geo Point, geo:SpatialThing, and add disjoint axioms to many classes in SAREF. Other ontologies use the OGC GeoSPARQL standard instead. One uni...From TR 103 781:
- SAREF4ENVI uses the W3C Basic Geo Vocabulary. It copies the definition of geo Point, geo:SpatialThing, and add disjoint axioms to many classes in SAREF. Other ontologies use the OGC GeoSPARQL standard instead. One unique choice should be made for all SAREF.
- SAREF4BLDG copies the definition of the geo:location from the W3C Basic Geo Vocabulary, but it does not use it. Other ontologies use the OGC GeoSPARQL standard instead. One unique choice should be made for all SAREF.
- SAREF4CITY:
- uses the W3C Basic Geo Vocabulary. It declares class geo:SpatialThing, copies the definition of geo:location, geo:lat, geo:long, geo:alt, geo:Point. These concepts are not further used in the ontology and could be deleted. geo:Point is hijacked and defined as a subclass of geosp:Geometry.
- uses the OGC GeoSPARQL standard. It copies the definition of geosp:hasGeometry, geosp:sfContains, geosp:sfWithin, geosp:Feature, geosp:Geometry, geosp:SpatialObject. Some classes in SAREF4CITY are defined as subclasses of geosp:Feature. Class saref:Device is hijacked and defined as a subclass of geosp:Feature.
- SAREF4AGRI:
- SAREF4AGRI uses the W3C Basic Geo Vocabulary, like SAREF4CITY but with a different prefix wgs84:. It declares class geo:SpatialThing, copies the definition of geo:location, geo:lat, geo:long, geo:alt, geo:Point. These concepts are not further used in the ontology and could be deleted. In particular, geo:long is defined as an OP in SAREF4AGRI while it is defined as a DP in SAREF4CITY. Therefore, using these two ontologies together would lead to an inconsistency. geo:Point is hijacked and defined as a subclass of geosp:Geometry.
- SAREF4AGRI uses the OGC GeoSPARQL standard, like SAREFCITY but with a different prefix geo:. It copies the definition of geosp:hasGeometry, geosp:sfContains, geosp:sfWithin, geosp:Feature, geosp:Geometry, geosp:SpatialObject. Some classes in SAREF4CITY are defined as subclasses of geosp:Feature. Class saref:Device is hijacked and defined as a subclass of geosp:Feature.
- SAREF4AUTO:
- uses the W3C Basic Geo Vocabulary, with no prefix. It copies the definition of geo:location, geo:lat, geo:long, geo:alt, geo:Point and geo:SpatialThing. These concepts are used in the ontology in the definition of s4auto:Point and s4auto:AbsolutePosition.
- uses the OGC GeoSPARQL standard, with prefix geosp:. It copies the definition of geosp:hasGeometry, geosp:Feature, geosp:Geometry, geosp:SpatialObject. These concepts are used in the ontology in the definition of s4auto:Point and s4auto:ParkingSpot.
- SAREF4WEAR:
- SAREF4WEAR uses the W3C Basic Geo Vocabulary, with prefix geo:. It copies the definition of geo:location, geo:Point. These concepts are not further used in the ontology and could be deleted. geo:Point is hijacked and defined as a subclass of geosp:Geometry.
- SAREF4WEAR uses the OGC GeoSPARQL standard with prefix geosp:. It copies the definition of geosp:hasGeometry, geosp:sfContains, geosp:sfWithin, geosp:Feature, geosp:Geometry, geosp:SpatialObject. Some classes in SAREF4WEAR are defined as subclasses of geosp:Feature. Or geosp:SpatialObject.
Proposals:
- only allow the reuse of OGC GeoSPARQL. with one unique prefix geo:
- never use W3C Basic Geo.
- introduce saref:PhysicalObject, allow its instances to also be of type geo:SpatialObjectV2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/22Stop hijacking SAREF Core terms2024-02-29T12:40:14ZMauro DragoniStop hijacking SAREF Core termsSome extensions like SAREF4ENVI imposes several disjointWith axioms, including across SAREF Core entities. These axioms should either be promoted to SAREF Core, or deleted from SAREF4ENVI.Some extensions like SAREF4ENVI imposes several disjointWith axioms, including across SAREF Core entities. These axioms should either be promoted to SAREF Core, or deleted from SAREF4ENVI.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/21Extensions copy declarations and definitions from SAREF Core2024-02-29T12:40:14ZMauro DragoniExtensions copy declarations and definitions from SAREF CoreSituation: many extensions copy declarations and definitions of entities from SAREF Core or other SAREF extensions.
Sometimes the copy is partial, or wrong.
It is unnecessary to copy definitions if the reused ontology is imported. These ...Situation: many extensions copy declarations and definitions of entities from SAREF Core or other SAREF extensions.
Sometimes the copy is partial, or wrong.
It is unnecessary to copy definitions if the reused ontology is imported. These could be deleted to limit the number of changes necessary when SAREF Core evolves.
Examples:
- SAREF4CITY defines saref:controlsProperty with wrong comment and no rdfs:isDefinedBy metadata.
- SAREF4CITY keeps some axioms from SAREF V2.1.1 that were deleted in SAREF V3.1.1. For example it still contains a universal restriction on saref:measurementMadeBy to only instances of the saref:Device class. In fact, saref:Device is now the range of saref:measurementMadeBy so this local restriction was considered useless, and deleted in SAREF V3.1.1.
- In SAREF4AGRI saref:FeatureOfInterest contains rdfs:comment <https://saref.etsi.org/core/>, which is wrong.
Affects: SAREF4ENER, SAREF4ENVI, SAREF4BLDG, SAREF4CITY, SAREF4INMA, SAREF4EHAW, SAREF4WEAR, SAREF4WATR
Proposal: SAREF ontologies should import SAREF ontologies when relevant. Definitions should not be copied.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/20Use the same local name in specializations2024-02-29T12:40:15ZMauro DragoniUse the same local name in specializationsIn many cases, classes from SAREF core are specialized into an extension.
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 s4ag...In many cases, classes from SAREF core are specialized into an extension.
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.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/19SAREF4BLDG-2. Subclass appears in figures but not in the ontology2024-02-29T12:40:15ZMauro DragoniSAREF4BLDG-2. Subclass appears in figures but not in the ontologySituation: In the figures PhysicalObject is defined as a subclass of geo:SpatialThing. However, this axiom does not appear in the ontology implementation (it appears in the examples).
Proposal: There are two options: either to remove th...Situation: In the figures PhysicalObject is defined as a subclass of geo:SpatialThing. However, this axiom does not appear in the ontology implementation (it appears in the examples).
Proposal: There are two options: either to remove the subclass relation from the figures or to add it to the ontology.
Status: To be discussed.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/18SAREF4BLDG-1. The extension defines restrictions on saref:Device2024-02-29T12:40:14ZMauro DragoniSAREF4BLDG-1. The extension defines restrictions on saref:DeviceSituation: The extension defines a restriction on saref:Device: that it is a subclass of s4bldg:PhysicalObject.
Proposal: To specialize saref:Device in the extension (unless it is interesting to talk about physical objects in SAREF core...Situation: The extension defines a restriction on saref:Device: that it is a subclass of s4bldg:PhysicalObject.
Proposal: To specialize saref:Device in the extension (unless it is interesting to talk about physical objects in SAREF core and the restriction can be moved there.
Status: To be discussed.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/17Harmonise naming of properties "hasX" versus "X"2024-02-29T12:40:15ZMauro DragoniHarmonise naming of properties "hasX" versus "X"Many properties are named as "hasX", where X is the concept that's the range of the property. There are also many properties that are simply named X, where X usually is the uncapitalised name of the range of the property.
The choice bet...Many properties are named as "hasX", where X is the concept that's the range of the property. There are also many properties that are simply named X, where X usually is the uncapitalised name of the range of the property.
The choice between "hasX" and "X" often seems arbitrary, especially to a non-expert. Can we form a best-practice on when to format a property as "hasX" and when not to?
Considerations:
- On multiple occasions I have heard people who are IT experts but novicein ontology express doubts about this naming convention. They expect a boolean when for the property "hasX", but the actual concept for a property "X".
- Being consistent is probably more important than whichever choice we make.
- The ERA Vocabulary, a modern ontology which I esteem highly, already follows the best practice of only using "hasX" when the intended domain is a boolean, at least when it comes to datatype properties.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/16ISSUE A: use SHACL ? ISSUE B: When to define domains and ranges2024-02-29T12:40:15ZMauro DragoniISSUE A: use SHACL ? ISSUE B: When to define domains and rangesThe various SAREF extensions take different views on the how to specify the intended domain and range of various properties.
Some use rdfs:domain and rdfs:range throughout, some use those predicates sparingly, and others use owl:restri...The various SAREF extensions take different views on the how to specify the intended domain and range of various properties.
Some use rdfs:domain and rdfs:range throughout, some use those predicates sparingly, and others use owl:restriction. Several use a combination of these approaches. Some leave the intended domain and range implicit by mentioning it just in the rdfs:comment.
Additionally, there are other ways to specify the domain and range of a property that are not used (yet) in extensions:
- SHACL constraints: these can indicate constraints of various severity levels (violation, warning, info)
- schema:domainIncludes and schema:rangeIncludes: this can indicate a domain/range such that multiple is interpreted as a union instead of an intersection
Can we take a moment to discuss the implications of rdfs:domain and rdfs:range? And to form an opinion on which type of domain/range specification would be most applicable in which situation? Afterall, the RDFS constructs indicate inference rules instead of restrictions in the common sense. We as ontology experts may be aware of that, but it becomes quite complicated towards less experienced users. Compare for example the following quotes:
Hogan, the web of data (2020) p.118:
"A common misconception is that rdfs:domain and rdfs:range�act as a form of constraint, ensuring respectively that the subject or�object resource of a given relation is typed with a given class. This is not�directly the case in RDF(S), where data are assumed to be incomplete�and such definitions are used to “complete” the data by inferring the�appropriate type rather than to flag the data as missing a type. Another�related misconception is that rdfs:domain and rdfs:range are used to�check that the type of a subject or object resource is “correct”: this is�not always the case since a resource can be typed under multiple classes. [...] Another related and common mistake is to assign multiple domains�(or multiple ranges) to a property with the intention of saying that the�subject (or object) is of one of those types. [...] "
p.36 from A Practical Guide To Building OWL Ontologies Using Protege, Matthew Horridge.
�"Although we have specified the domains and ranges of various properties for the purposes of this tutorial, we generally advise against doing this. The fact that domain and range conditions do not behave as constraints and the fact that they can cause `unexpected' classification results can lead problems and unexpected side effects. These problems and side effects can be particularly difficult to track�down in a large ontology."V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/15Make explicit any implicit SAREF InverseOf statements?2024-02-29T12:40:15ZMauro DragoniMake explicit any implicit SAREF InverseOf statements?Would it make more sense to explicitly define the inverse relation between properties instead of making an inference?
https://saref.etsi.org/core/hasMeasurement INVERSEOF https://saref.etsi.org/core/isMeasurementOf
https://saref.etsi...Would it make more sense to explicitly define the inverse relation between properties instead of making an inference?
https://saref.etsi.org/core/hasMeasurement INVERSEOF https://saref.etsi.org/core/isMeasurementOf
https://saref.etsi.org/core/isAccomplishedBy INVERSEOF https://saref.etsi.org/core/accomplishes
https://saref.etsi.org/core/isCommandOf INVERSEOF https://saref.etsi.org/core/hasCommand
https://saref.etsi.org/core/isPropertyOf INVERSEOF https://saref.etsi.org/core/hasProperty
https://saref.etsi.org/core/measurementMadeBy INVERSEOF https://saref.etsi.org/core/makesMeasurement
https://saref.etsi.org/core/offers INVERSEOF https://saref.etsi.org/core/isOfferedBy
https://saref.etsi.org/core/relatesToMeasurement INVERSEOF https://saref.etsi.org/core/relatesToProperty
https://saref.etsi.org/saref4agri/isContainedIn INVERSEOF https://saref.etsi.org/saref4agri/contains
https://saref.etsi.org/saref4agri/isLocationOf INVERSEOF https://saref.etsi.org/saref4agri/isLocatedIn
https://saref.etsi.org/saref4agri/isMemberOf INVERSEOF https://saref.etsi.org/saref4agri/hasMember
https://saref.etsi.org/saref4agri/receives INVERSEOF https://saref.etsi.org/saref4agri/hasReceived
https://saref.etsi.org/saref4auto/isConfidenceOf INVERSEOF https://saref.etsi.org/saref4auto/hasConfidence
https://saref.etsi.org/saref4auto/isMemberOf INVERSEOF https://saref.etsi.org/saref4auto/hasMember
https://saref.etsi.org/saref4bldg/isContainedIn INVERSEOF https://saref.etsi.org/saref4bldg/contains
https://saref.etsi.org/saref4bldg/isSpaceOf INVERSEOF https://saref.etsi.org/saref4bldg/hasSpace
https://saref.etsi.org/saref4city/isKPIOf INVERSEOF https://saref.etsi.org/saref4city/hasKPI
https://saref.etsi.org/saref4envi/hasDigitalRepresentation INVERSEOF https://saref.etsi.org/saref4envi/encapsulates
https://saref.etsi.org/saref4envi/isComponentOf INVERSEOF https://saref.etsi.org/saref4envi/hasComponent
https://saref.etsi.org/saref4envi/isConnectedTo INVERSEOF https://saref.etsi.org/saref4envi/isConnectedTo
https://saref.etsi.org/saref4envi/isContainedIn INVERSEOF https://saref.etsi.org/saref4envi/contains
https://saref.etsi.org/saref4inma/isCategoryOf INVERSEOF https://saref.etsi.org/saref4inma/belongsToCategory
https://saref.etsi.org/saref4inma/isCreatedIn INVERSEOF https://saref.etsi.org/saref4inma/creates
https://saref.etsi.org/saref4inma/isFeatureOfInterestOf INVERSEOF https://saref.etsi.org/saref4inma/hasFeatureOfInterest
https://saref.etsi.org/saref4inma/produces INVERSEOF https://saref.etsi.org/saref4inma/isProducedBy
https://saref.etsi.org/saref4syst/connectedTo INVERSEOF https://saref.etsi.org/saref4syst/connectedTo
https://saref.etsi.org/saref4wear/triggers INVERSEOF https://saref.etsi.org/saref4wear/isTriggeredByV2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/14Make explicit any implicit SAREF Domain and Range statements?2024-02-29T12:40:14ZMauro DragoniMake explicit any implicit SAREF Domain and Range statements?The following SPARQL query returns the 2845 implicit Statements in the merged SAREF ontology collection as reported by GraphDB on 30-03-2023:
select DISTINCT ?s ?o FROM <http://www.ontotext.com/implicit> where { ?s a ?o .
FILTER ( STRS...The following SPARQL query returns the 2845 implicit Statements in the merged SAREF ontology collection as reported by GraphDB on 30-03-2023:
select DISTINCT ?s ?o FROM <http://www.ontotext.com/implicit> where { ?s a ?o .
FILTER ( STRSTARTS(STR(?s), "https://saref.etsi.org/") )
FILTER (isURI(?o))
}
Number {Inference Statement Type}
----------------------------------------------------------------------------------------------
1843 http://www.w3.org/2000/01/rdf-schema#subClassOf
834 http://www.w3.org/1999/02/22-rdf-syntax-ns#type
66 http://www.w3.org/2000/01/rdf-schema#seeAlso
37 http://www.w3.org/2000/01/rdf-schema#range
28 http://www.w3.org/2000/01/rdf-schema#domain
26 http://www.w3.org/2002/07/owl#inverseOf
8 http://proton.semanticweb.org/protonsys#transitiveOver
https://saref.etsi.org/saref4bldg/contains
https://saref.etsi.org/saref4bldg/hasSpace
https://saref.etsi.org/saref4bldg/isContainedIn
https://saref.etsi.org/saref4bldg/isSpaceOf
https://saref.etsi.org/saref4envi/hasComponent
https://saref.etsi.org/saref4envi/isComponentOf
https://saref.etsi.org/saref4syst/hasSubSystem
https://saref.etsi.org/saref4syst/subSystemOf
3 http://www.w3.org/2002/07/owl#equivalentClass => ~/saref4ehaw/Contact && ~/saref4ehaw/HealthActor
It would make more sense if Domain and Range values were explicitly declared, especially if they link named classes.
https://saref.etsi.org/saref4agri/contains DOMAIN http://www.opengis.net/ont/geosparql#SpatialObject
https://saref.etsi.org/saref4agri/contains RANGE http://www.opengis.net/ont/geosparql#SpatialObject
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4agri/generates DOMAIN https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4agri/generates RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4agri/receives DOMAIN https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4agri/receives RANGE https://saref.etsi.org/core/Measurement
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4auto/hasAbsolutePosition RANGE https://saref.etsi.org/saref4auto/RelativePosition
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4auto/hasHeight DOMAIN https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4auto/hasHeight RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4auto/hasLength DOMAIN https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4auto/hasLength RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4auto/hasMovement DOMAIN https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4auto/hasMovement RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4auto/hasPlatoonPosition RANGE https://saref.etsi.org/saref4auto/RelativePosition
https://saref.etsi.org/saref4auto/hasPlatoonRole RANGE https://saref.etsi.org/saref4auto/Role
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4auto/hasRelativePosition RANGE https://saref.etsi.org/saref4auto/RelativePosition
https://saref.etsi.org/saref4auto/hasRoadTopologyPosition RANGE https://saref.etsi.org/saref4auto/RelativePosition
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4auto/hasShape DOMAIN https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4auto/hasShape RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4auto/hasSize DOMAIN https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4auto/hasSize RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4auto/hasVehicleRole RANGE https://saref.etsi.org/saref4auto/Role
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4auto/hasWidth DOMAIN https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4auto/hasWidth RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4ener/hasEventStateConsume DOMAIN https://saref.etsi.org/core/Device
https://saref.etsi.org/saref4ener/hasEventStateConsume RANGE https://saref.etsi.org/core/State
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4ener/hasEventStateProduce DOMAIN https://saref.etsi.org/core/Device
https://saref.etsi.org/saref4ener/hasEventStateProduce RANGE https://saref.etsi.org/core/State
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4inma/hasGTIN12ID RANGE https://saref.etsi.org/saref4inma/ID
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4inma/hasGTIN13ID RANGE https://saref.etsi.org/saref4inma/ID
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4inma/hasGTIN14ID RANGE https://saref.etsi.org/saref4inma/ID
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4inma/hasGTIN8ID RANGE https://saref.etsi.org/saref4inma/ID
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4inma/hasIRDI RANGE https://saref.etsi.org/saref4inma/ID
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4inma/hasUUID RANGE https://saref.etsi.org/saref4inma/ID
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/canConnectToNetwork RANGE https://saref.etsi.org/saref4syst/System
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/connectedToEmergencyBattery DOMAIN https://saref.etsi.org/saref4syst/System
https://saref.etsi.org/saref4lift/connectedToEmergencyBattery RANGE https://saref.etsi.org/saref4syst/System
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasCarService DOMAIN https://saref.etsi.org/saref4syst/System
https://saref.etsi.org/saref4lift/hasCarService RANGE https://saref.etsi.org/saref4syst/Connection
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasCarTemperature DOMAIN https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4lift/hasCarTemperature RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasChannelBitErrorRate DOMAIN https://saref.etsi.org/core/FeatureOfInterest
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasCoverage DOMAIN https://saref.etsi.org/core/FeatureOfInterest
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasElectricPowerConsumption RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasEngineRoomTemperature DOMAIN https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4lift/hasEngineRoomTemperature RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasMainPowerSupply DOMAIN https://saref.etsi.org/saref4syst/System
https://saref.etsi.org/saref4lift/hasMainPowerSupply RANGE https://saref.etsi.org/saref4syst/ConnectionPoint
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasReceivedSignalStrengthIndicator DOMAIN https://saref.etsi.org/core/FeatureOfInterest
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasShaftTemperature DOMAIN https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4lift/hasShaftTemperature RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasStandardPowerSupply DOMAIN https://saref.etsi.org/saref4syst/System
https://saref.etsi.org/saref4lift/hasStandardPowerSupply RANGE https://saref.etsi.org/saref4syst/ConnectionPoint
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasTimeOfConfirmationOfLastPeriodicTest72hAttempt DOMAIN
https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4lift/hasTimeOfConfirmationOfLastPeriodicTest72hAttempt RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasTimeOfLastPeriodicTest72hAttempt DOMAIN https://saref.etsi.org/core/FeatureOfInterest
https://saref.etsi.org/saref4lift/hasTimeOfLastPeriodicTest72hAttempt RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4lift/hasVoltage RANGE https://saref.etsi.org/core/Property
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4wear/isLocatedIn DOMAIN https://saref.etsi.org/saref4wear/Wearable
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4wear/isLocatedNear DOMAIN https://saref.etsi.org/saref4wear/Wearable
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4wear/isLocatedOn DOMAIN https://saref.etsi.org/saref4wear/Wearable
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4wear/sendsInformationTo DOMAIN https://saref.etsi.org/saref4syst/System
https://saref.etsi.org/saref4wear/sendsInformationTo RANGE https://saref.etsi.org/saref4syst/System
----------------------------------------------------------------------------------------------
https://saref.etsi.org/saref4wear/sendsNotificationsTo DOMAIN https://saref.etsi.org/saref4syst/System
https://saref.etsi.org/saref4wear/sendsNotificationsTo RANGE https://saref.etsi.org/saref4syst/System
----------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4bldg/-/issues/13Inconsistent / redundant use of "contains" ObjectProperty in SAREF extensions.2024-02-29T12:40:14ZMauro DragoniInconsistent / redundant use of "contains" ObjectProperty in SAREF extensions.SAREF4ENVI and SAREF4BLDG were developed first.
SAREF4BLDG defines the `contains` property as transitive.
```
saref4bldg:contains a owl:ObjectProperty ;
owl:inverseOf ???:isContainedIn ;
a **owl:TransitiveProperty** ;
rdfs:comment "...SAREF4ENVI and SAREF4BLDG were developed first.
SAREF4BLDG defines the `contains` property as transitive.
```
saref4bldg:contains a owl:ObjectProperty ;
owl:inverseOf ???:isContainedIn ;
a **owl:TransitiveProperty** ;
rdfs:comment "A relation between a physical space and the objects located in such space."@en ;
rdfs:label "contains"@en .
```
SAREF4ENVI adds the word "physical" in the comment.
```
saref4envi:contains rdf:type owl:ObjectProperty ;
owl:inverseOf ???:isContainedIn ;
rdfs:comment "A relation between a physical object and the **physical** objects that can be contained in it."@en ;
rdfs:label "contains"@en .
```
SAREF4AGRI was developed later than SAREF4BLDG,
* it adds a subPropertyOf to `geo:sfContains`.
* the comment is too succint
```
s4agri:contains rdf:type owl:ObjectProperty ;
owl:inverseOf s4agri:isContainedIn .
rdfs:comment "contains"@en ;
rdfs:label "contains"@en ;
**rdfs:subPropertyOf geo:sfContains** .
```
SAREF4EHAW was defined by different experts, and defines `s4ehaw:contains` with a very different meaning:
```
s4ehaw:contains rdf:type owl:ObjectProperty ;
rdfs:domain **s4ehaw:Ban** ;
rdfs:range **s4ehaw:HealthDevice** ;
rdfs:comment "A Body Area Network or BAN contains one or multiple health devices"@en ;
rdfs:label "contains"@en .
```
**Proposal for `:contains`:**
* use definition: "A relation between a physical object and another physical object it contains."@en
* define as transitive
* define domain and range as `PhysicalObject`: a 3D spatial extent, which is also promoted to the core
* do not align to GeoSPARQL. Leave GeoSPARQL for 2D SpatialObjects
* add a comparison to `saref:consistsOf` in the definition (?)
* in SARE4EHAW, use `saref:consistsOf` instead of `s4ehaw:contains`
**Status:** agreed during STF641 WP2 and STF653 joint meeting 2023-04-25.V2.1.1_stableMauro DragoniMauro Dragoni