saref4wear issueshttps://labs.etsi.org/rep/saref/saref4wear/-/issues2024-03-27T22:55:24Zhttps://labs.etsi.org/rep/saref/saref4wear/-/issues/36Promote fabrication and versioning metadata to Core2024-03-27T22:55:24ZMauro DragoniPromote fabrication and versioning metadata to CoreDPs s4watr:fabricationNumber, s4watr:hasFirmwareVersion, s4watr:hasHardwareVersion, s4watr:hasVersion, could apply to other extensions and could be promoted to SAREF Core.DPs s4watr:fabricationNumber, s4watr:hasFirmwareVersion, s4watr:hasHardwareVersion, s4watr:hasVersion, could apply to other extensions and could be promoted to SAREF Core.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/35Should extensions define individuals of the class saref:FeatureOfInterest ?2024-03-27T23:03:02ZMauro DragoniShould extensions define individuals of the class saref:FeatureOfInterest ?Class s4watr:Water is a subclass of saref:FeatureOfInterest, and has different individuals. It may be problematic that this class contains generic individuals such as s4watr:DrinkingWater etc. which will be the object of measurements of ...Class s4watr:Water is a subclass of saref:FeatureOfInterest, and has different individuals. It may be problematic that this class contains generic individuals such as s4watr:DrinkingWater etc. which will be the object of measurements of all kinds. It may be better to have a pattern where these concepts are instances of s4watr:WaterKind, and an instance of s4watr:Water (a specific quantity of water) is linked to its kind.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/34Modeling System capabilities2024-03-27T22:46:05ZMauro DragoniModeling System capabilitiesSAREF4WEAR uses the SSN System module from the OGC and W3C SOSA/SSN ontology, to assign system capabilities to s4wear:Wearable instances. A SAREF version of this module could be developed and promoted to SAREF Core.SAREF4WEAR uses the SSN System module from the OGC and W3C SOSA/SSN ontology, to assign system capabilities to s4wear:Wearable instances. A SAREF version of this module could be developed and promoted to SAREF Core.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/33Promotion of triggers and isTriggeredBy ?2024-03-27T22:45:42ZMauro DragoniPromotion of triggers and isTriggeredBy ?OPs s4wear:triggers and s4wear:isTriggeredBy could be useful for other extensions and could be promoted to SAREF Core.OPs s4wear:triggers and s4wear:isTriggeredBy could be useful for other extensions and could be promoted to SAREF Core.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/32Promotion of MemoryStorage, PowerSupply, Software, User ?2024-03-27T22:57:33ZMauro DragoniPromotion of MemoryStorage, PowerSupply, Software, User ?Devices types s4wear:MemoryStorage and s4wear:PowerSupply, and Feature of Interest types s4wear:Software and s4wear:User, could be useful to other extensions and could be promoted to SAREF Core.Devices types s4wear:MemoryStorage and s4wear:PowerSupply, and Feature of Interest types s4wear:Software and s4wear:User, could be useful to other extensions and could be promoted to SAREF Core.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/31Delete s4wear:hasCommand2024-03-27T21:23:50ZMauro DragoniDelete s4wear:hasCommandSAREF4WEAR defines DP s4wear:hasCommand when there exists a OP saref:hasCommand for a similar purpose. The modelling pattern from SAREF could be used instead.SAREF4WEAR defines DP s4wear:hasCommand when there exists a OP saref:hasCommand for a similar purpose. The modelling pattern from SAREF could be used instead.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/30isLocatedIn / isLocatedNear / isLocatedOn2024-03-27T21:38:34ZMauro DragoniisLocatedIn / isLocatedNear / isLocatedOnSAREF4WEAR defines an architectural ODP, defining three OPs s4wear:isLocatedIn, s4wear:isLocatedNear, s4wear:isLocatedOn, which are all sub-properties of s4wear:isLocated and whose domain is respectively s4wear:InBodyWearable, s4wear:Nea...SAREF4WEAR defines an architectural ODP, defining three OPs s4wear:isLocatedIn, s4wear:isLocatedNear, s4wear:isLocatedOn, which are all sub-properties of s4wear:isLocated and whose domain is respectively s4wear:InBodyWearable, s4wear:NearBodyWearable, s4wear:OnBodyWearable. A similar ODP could be adopted for other types of devices and located differently on/in/near other types of features of interest.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/29Modeling the power supply of devices2024-03-27T22:58:11ZMauro DragoniModeling the power supply of devicesOP s4wear:hasPowerSupply is used to link a device to the type of power supply it is equipped with. SAREF4LIFT also models similar knowledge, differently. Some harmonization may be needed.OP s4wear:hasPowerSupply is used to link a device to the type of power supply it is equipped with. SAREF4LIFT also models similar knowledge, differently. Some harmonization may be needed.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/28Promotion of s4wear:controlsFeature, s4wear:measuresFeature and inverses2024-03-27T22:22:09ZMauro DragoniPromotion of s4wear:controlsFeature, s4wear:measuresFeature and inversesSAREF4WEAR introduces different OPs that link devices to the features of interest they measure or control. This is missing from SAREF Core and could be useful to other extensions. It could be promoted to SAREF Core.SAREF4WEAR introduces different OPs that link devices to the features of interest they measure or control. This is missing from SAREF Core and could be useful to other extensions. It could be promoted to SAREF Core.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/27Modeling of time series ?2024-03-27T22:54:28ZMauro DragoniModeling of time series ?SAREF4EHAW attempts to model time series as s4ehaw:TimeSeriesMeasurement, a subclass of saref:Measurement, which has exactly one xsd:decimal as a value. The modelling is partial. Time series may be of interest to other extensions. Some m...SAREF4EHAW attempts to model time series as s4ehaw:TimeSeriesMeasurement, a subclass of saref:Measurement, which has exactly one xsd:decimal as a value. The modelling is partial. Time series may be of interest to other extensions. Some more discussion is needed to model time series in SAREF, and this part could be deleted from SAREF4EHAW in the meantime.
InterConnect has a different proposal.
I can agree it's relevant to annotate timeseries.
But is it relevant to model all the datapoints of a timeseries in RDF ?V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/26Explicit what property sensors measure ?2024-03-27T22:37:40ZMauro DragoniExplicit what property sensors measure ?SAREF4AGRI defines seven types of sensors. None of them have restrictions associated such as the type of property they measure. Yet, the definitions of some sensors is explicit about which property they measure. For example the s4agri:So...SAREF4AGRI defines seven types of sensors. None of them have restrictions associated such as the type of property they measure. Yet, the definitions of some sensors is explicit about which property they measure. For example the s4agri:SoilTensiometer is said to measure the soil moisture, but it is not linked to s4agri:SoilMoisture.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/25Modeling events2024-03-27T22:38:54ZMauro DragoniModeling eventsSAREF4CITY contains a content ODP for describing Events. 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...SAREF4CITY contains a content ODP for describing Events. 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.
SAREF4AGRI defines four DPs with range xsd:dateTime: s4agri:hasPlantDate and s4agri:hasHarvestDate, s4agri:hasBirthDate and s4agri:hasDeathDate.
SAREF4WEAR hijacks SAREF4CITY by defining s4city:Event as a subclass of s4wear:Occurrence.
It may be useful to generalize how events occurring over the lifespan of features of interests are modeled, maybe using a pattern. For example generalizing the class s4city:Event. The kind of event could then be defined by a link to a concept from a code list that depend on the type of feature of interest.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/24Highly generic properties2024-03-27T22:37:55ZMauro DragoniHighly generic propertiesSAREF4AGRI defines some OP that are very generic, such as s4agri:hasName, and saref:hasDescription.
saref:hasDescription has been deprecated in SAREF. Other properties should be used, for example from the RDFS or Dublin Core Terms voca...SAREF4AGRI defines some OP that are very generic, such as s4agri:hasName, and saref:hasDescription.
saref:hasDescription has been deprecated in SAREF. Other properties should be used, for example from the RDFS or Dublin Core Terms vocabularies.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/23Use of SKOS in extensions2024-03-27T22:57: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/saref4wear/-/issues/22Pattern for specializing saref:Function ?2024-03-27T22:45:04ZMauro DragoniPattern for specializing saref:Function ?SAREF4INMA specializes saref:Function into the class s4inma:ProductionEquipmentFunction. The naming is thus “{name of the feature of interest}Function” , while in SAREF Core it is often “{type of action}Function”.SAREF4INMA specializes saref:Function into the class s4inma:ProductionEquipmentFunction. The naming is thus “{name of the feature of interest}Function” , while in SAREF Core it is often “{type of action}Function”.V2.1.1_stableMauro DragoniMauro Dragonihttps://labs.etsi.org/rep/saref/saref4wear/-/issues/21Position as property ?2024-03-27T22:57:47ZMauro 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/saref4wear/-/issues/20PhysicalObject in SAREF ?2024-03-27T22:46:22ZMauro 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/saref4wear/-/issues/19Decoupling kinds of evaluations and kinds of properties2024-03-27T22:59:01ZMauro 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/saref4wear/-/issues/18Spatial ontologies2024-03-27T22:22:58ZMauro 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/saref4wear/-/issues/17W3C Time ontology2024-03-27T22:45:22ZMauro DragoniW3C Time ontologyMost SAREF extensions use W3C Time ontology, sometimes differently.
It may be imported at the level of SAREF Core directly
- SAREF4ENVI uses the W3C Time Ontology and copies the definition for time:TemporalUnit, but additionally states...Most SAREF extensions use W3C Time ontology, sometimes differently.
It may be imported at the level of SAREF Core directly
- SAREF4ENVI uses the W3C Time Ontology and copies the definition for time:TemporalUnit, but additionally states it’s a subclass of saref:UnitOfMeasure. This is considered a bad practice.
- SAREF4CITY uses the W3C Time Ontology and declares class time:TemporalEntity, time:Instant, and time:Interval. It uses time:TemporalEntity in local restrictions on classes s4city:Event and s4city:KeyPerformanceIndicator.
- SAREF4AGRI uses the W3C Time ontology. It copies the definition of time:Instant, time:Interval, and time:TemporalEntity. Other SAREF ontologies use these concepts, therefore it could be useful to define them at the level of SAREF Core.
- SAREF4AUTO uses the W3C Time ontology. It copies the definition of time:Instant, time:Interval, and time:TemporalEntity, and several properties. Other SAREF ontologies use these concepts, therefore it could be useful to define them at the level of SAREF Core.
- SAREF4WATR uses the W3C Time ontology. It copies the definition of time:DayOWeek, time:Instant, time:Interval, time:TemporalEntity, and time:TemporalDuration, and several properties. Other SAREF ontologies use these concepts, therefore it could be useful to define them at the level of SAREF Core. SAREF4WATR use these concepts in ranges of some properties that apply to the class s4watr:Tariff, which may be interesting to promote to SAREF Core.V2.1.1_stableMauro DragoniMauro Dragoni