Review and updat of SAREF4LIFT
Commands, Service, Functions.
SAREF Commands are aligned to TD InteractionAffordances.
SAREF Functions group Commands
SAREF Services represent functions to the network.
SAREF Command executions cannot be modeled in SAREF.
SAREF ontologies should import other SAREF ontologies
PROPOSAL: The SAREF ontologies should be imported. The term definitions should only be copied for those ontologies that are not part of SAREF (e.g., GEO).
Topologies of building
PROPOSAL:
- reuse W3C BOT ontology, compatible with SAREF4SYST.
- reuse: sbldg:BuildingSpace s4bldg:hasSpace
- define s4lift:DoorSpace, s4lift:Door
Reuse SAREF4SYST.
PROPOSAL: reuse SAREF4SYST for the connection of the car (System) to the storey (System) via the Door (Connection). The Door have a Open/Close state.
PROPOSAL: reuse SAREF4SYST for the connection between a device and the communication network. The signal coverage and quality qualify the Connection between these Systems.
TS 103 735 Table 6.3-1: Information group name: AdministrativeInformation
PROPOSAL: mention references to ISO standards
PROPSAL: add missing properties liftManufacturingCompanyRepresentitive liftAlarmMonitoringCentre inspectionAuthority
PROPSOAL: rename hasLocationValidator in hasGeographicLocationValidator
usage: Fireman lifts
BS EN 81-72:2020 uses term Firefighters Lift. Not Fireman Lift.
PROPOSAL: use original denomination FirefightersSmartLift, refer to original reference.
usage: Goods only lifts
BS EN 81-31 uses term Accessible goods only lifts.
PROPOSAL: use original denomination AccessibleGoodsOnlySmartLifts, refer to original reference.
SmartLiftPlatform
EN 81-41 uses term Vertical lifting platforms intended for use by persons with impaired mobility
PROPOSAL: use original denomination VerticalSmartLiftingPlatform, refer to original reference.
usage: Lift
EN 81-20 uses term Passenger and goods passenger lifts
PROPOSAL: use original denomination PassengerAndGoodsPassengerLifts
TS 103 735 Table 6.4-1: Information group name: SLInstallation
technologyUsed
PROPOSAL: add ElectricalDevice, HydraulicDevice, and MachineRoomLessSmartLift (MRL)
manufacturer
PROPOSAL: use saref:hasManufacturer
plateinformation
PROPOSAL: defined s4lift:hasPlateInformation rdf:type owl:DatatypeProperty ;
groupConfiguration
PROPOSAL: use subproperties of s4lift:isGroupedIn : s4lift:isMasterInGroup isSecondaryInGroup isPeerInGroup
The NOGROUP can be obtained from the execution of a SPARQL query
ASK {
?sli a s4lift:SmartLiftInstallation .
FILTER NOT EXISTS {
?sli s4lift:isGroupedIn ?slg .
}
}
carStops
PROPOSAL:
- generalize s4lift:hasStops to be used by other s4syst:System entities.
- define s4lift:CarStopSpace rdfs:subClassOf sbldg:BuildingSpace, which connects at some s4lift:DoorConnectionPoint
can also be obtained from the execution of a SPARQL query
SELECT ?sli (count(DISTINCT ?carStopSpace) AS ?result ) {
?sli a s4lift:SmartLiftInstallation .
?sli s4bldg:hasSpace ?carStopSpace .
?carStopSpace a s4lift:CarStopSpace .
}
GROUP BY ?sli
doorsNumber
PROPOSAL:
- generalized to sbldg:BuildingSpace to be used by other sbldg:BuildingSpace
- defined s4lift:DoorConnectionPoint which are doors of a s4lift:SmartLiftCar
can also be obtained from the execution of a SPARQL query
SELECT ?space (count(DISTINCT ?door) AS ?result ) {
?space a s4lift:SmartLiftCar .
?space s4syst:connectsAt ?door .
?door a s4lift:DoorConnectionPoint .
}
GROUP BY ?space
carServices
PROPOSAL:
- defined s4lift:hasCarServices rdf:type owl:DatatypeProperty .
- defined s4lift:PossibleSmartLiftCarService rdf:subClassOf s4syst:Connection .
- defined s4lift:hasCarService rdfs:subPropertyOf s4syst:connectsThrough .
can also be obtained from the execution of a SPARQL query
SELECT ?sli (count(DISTINCT ?smartLiftCarService) AS ?result ) {
?sli a s4lift:SmartLiftInstallation .
?sli sbldg:hasSpace ?carStopSpace .
?sli s4lift:containsCar ?car .
?sli s4lift:hasCarService ?smartLiftCarService .
?carStopSpace a s4lift:CarStopSpace .
?car a s4lift:SmartLiftCar .
?space a sbldg:BuildingSpace .
?smartLiftCarService a s4lift:PossibleSmartLiftCarService ;
s4syst:connectsSystem ?carStopSpace ;
s4syst:connectsSystem ?space ;
s4syst:connectsSystemAt ?door ;
FILTER( ?space != ?carStopSpace )
}
GROUP BY ?sli
carloadLimit
PROPOSAL:
- defined s4lift:Load rdfs:subClassOf saref:Property
- defined s4lift:hasCarloadLimit rdfs:subPropetyOf saref:hasProperty .
emergencyCallSupport
PROPOSAL:
- defined s4lift:SmartLiftWithoutEmergencyCallSupport
mainPowerSupply
PROPOSAL:
- defined s4lift:ElectricPowerSystem rdfs:subClassOf s4syst:System .
- defined s4lift:ElectricalConnectionPoint rdfs:subClassOf s4syst:ConnectionPoint .
- defined s4lift:ThreePhaseConnectionPoint rdfs:subClassOf s4syst:ConnectionPoint .
- defined s4lift:SinglePhaseConnectionPoint rdfs:subClassOf s4syst:ConnectionPoint .
- defined s4lift:DirectCurrentConnectionPoint rdfs:subClassOf s4syst:ConnectionPoint .
- defined s4lift:hasMainPowerSupply rdfs:subPropertyOf s4syst:connectsAt .
- defined s4lift:hasStandardPowerSupply rdfs:subPropertyOf s4syst:connectsAt .
The main power supply is 3-PHASE if
ASK {
?sli s4lift:hasMainPowerSupply ?powersupply .
?powersupply a s4lift:ThreePhaseConnectionPoint
}
The main power supply is SINGLE-PHASE if
ASK {
?sli s4lift:hasMainPowerSupply ?powersupply .
?powersupply a s4lift:SinglePhaseConnectionPoint
}
powerSupplyVoltage
PROPOSAL:
- defined s4lift:hasVoltage rdfs:subPropertyOf saref:hasProperty .
- defined s4lift:Voltage rdfs:subClassOf saref:Property .
The voltage can be measured on the s4lift:ElectricalConnectionPoint
?sli s4lift:hasMainPowerSupply ?mainPowerSupply .
?mainPowerSupply s4lift:hasVoltage ?voltage
?measure a saref:Measurement ;
saref:hasValue "380 v"^^cdt:ucum ;
saref:relatesToProperty ?voltage .
valueOfStandardPowerSupply
The voltage can be measured on the s4lift:ElectricalConnectionPoint
?sli s4lift:hasStandardPowerSupply ?standardPowerSupply .
?standardPowerSupply s4lift:hasVoltage ?voltage
?measure a saref:Measurement ;
saref:hasValue "12 v"^^cdt:ucum ;
saref:relatesToProperty ?voltage .
TS 103 735 Table 6.5-1: Information group name: SLConfiguration
carServicesDescription
PROPOSAL:
- use the property s4lift:hasCarService
carStop of CarServices
PROPOSAL:
- not necessary to indicate the carStop. skos:hiddenLabel can be used on instances of s4lift:PossibleSmartLiftCarService.
doorStatus of CarServices
PROPOSAL:
- s4lift:PossibleSmartLiftCarService connectsSystemAt some DoorConnectionPoint
- the instance of DoorConnectionPoint can have a state Open/Close
?sli a s4lift:SmartLiftInstallation ;
?sli s4lift:hasCarService ?carservice .
?carservice a s4lift:PossibleSmartLiftCarService .
?carservice s4syst:connectsSystemAt ?door .
?door a s4lift:DoorConnectionPoint .
?door saref:hasState ?openclosestate .
?openclosestate a saref:OpenState .
?openclosestate saref:hasTimeStamp "2021-03-15T12:00:00Z"^^xsd:dateTime .
floorNames
PROPOSAL:
- For every s4lift:CarStopSpace that a s4lift:SmartLiftInstallation s4bldg:hasSpace, just use some label.
openDoorTime, closeDoorTime, travelTime
currently these concepts have range saref:Time. saref:Time is "A class that allows to specify the time concept." ... This saref:Time is deseperately void in its meaning. And a duration is different than a saref:Time.
Also, traveled is past tense. Should be travel.
PROPOSAL:
- s4lift:hasDoorOpenTime rdf:type owl:DatatypeProperty , with range xsd:duration
- s4lift:hasDoorCloseTime rdf:type owl:DatatypeProperty , with range xsd:duration
- s4lift:hasTravelTime rdf:type owl:DatatypeProperty , with range xsd:duration
realTimeModeDescriptor
PROPOSAL:
- Use the HTTP address of the realTimeModeDescriptor as the identifier for the instance of the Smart Lift Installation .
Signals vs measurements or states
The someValuesFrom(s4lift:Signal saref:isMeasuredIn saref:UnitOfMeasure)
implies that Signals are sorts of Measurements.
From [ISO/IEC 10746-3:2009 Information technology — Open Distributed Processing — Reference Model: Architecture, 7.1.1], a Signal is an atomic shared action resulting in one-way communication from an initiating object to a responding object. Note: A signal is an interaction.
A signal may convey information about a phenomenon: some Measurement of some Property, or some State.
Even if TS 103 735 classifies everything as a "signal" of some sort, SAREF actually already has some core classes that should be used to classify the concepts in the Smart Lift domain.
Still, signals and alarms are pretty useful and may be kept for future adoption in SAREF.
PROPOSAL:
- define s4lift:Signal
- Parallel to defining the taxonomy of signals, enrich the taxonomies of States and Properties.
s4lift:isAssociatedTo
SAREF already has saref:isAbout .
PROPOSAL:
- reuse saref:isAbout. A signal conveys some information about a featureofInterest
- define s4lift:conveys domain Signal comment "A relationship specifying an information (e.g., measurement, state) that is conveyed by a signal"@en
saref:hasValue
the literal's datatype of saref:hasValue is usually unspecified, to account for example for cases where a different datatype may be used (xsd:boolean, xsd:decimal, or cdt:ucum) the signal does not have a value. if the signal conveys a measurement, then the measurement has the value.
PROPOSAL: do not use use of saref:hasValue
TS 103 735 General Signals
currentCarStop and currentCarService
PROPOSAL:
- define connection s4lift:SmartLiftCarService between the s4lift:SmartLiftCar the s4lift:CarStopSpace and the sbldg:BuildingSpace
?sli a s4lift:SmartLiftInstallation ;
?sli s4lift:hasCarService ?carservice .
?carservice a s4lift:SmartLiftCarService .
?carservice s4syst:connectsSystem ?carstopspace .
?carstopspace a s4lift:CarStopSpace .
PROPOSAL:
- the signal is about the s4lift:SmartLiftCarService, and holds all the information about the currentCarStop and currentCarService
?signal a s4lift:Signal .
?signal s4lift:isAbout ?carservice.
?carservice s4syst:connectsSystem ?carstopspace .
movingUpwardDirection and movingDownwardDirection
PROPSAL:
- defined s4lift:MovingDirectionState rdfs:subClassOf saref:State
- defined s4lift:MovingUpwardDirectionState rdfs:subClassOf s4lift:MovingDirectionState
- defined s4lift:MovingDownwardDirectionState rdfs:subClassOf s4lift:MovingDirectionState
carInUnlockingSpace
PROPOSAL:
- same as currentCarStop and currentCarService: the connection s4lift:SmartLiftCarService holds all the information about the fact that the car is in UnlockingSpace
- define state and signal to refer to this situation:
- s4lift:CarInUnlockingSpaceState rdfs:subClassOf s4lift:State
- s4lift:CarInUnlockingSpaceSignal rdfs:subClassOf s4lift:StatusSignal (isabout SmartLiftCarService , conveys CarInUnlockingSpaceState)
?signal a s4lift:Signal .
?signal saref:isAbout ?carservice.
?carservice s4lift:conveys ?carinunlockingspacestate .
?carinunlockingspacestate a s4lift:CarInUnlockingSpaceState
doorStatus
PROPOSAL:
- Open/Close are states of the DoorConnectionPoints of the car
?sli a s4lift:SmartLiftInstallation .
?sli s4lift:containsCar ?car .
?car s4syst:connectsAt ?door .
?door a s4lift:DoorConnectionPoint .
?door saref:hasState ?openclosestate .
?openclosestate a saref:OpenState .
?openclosestate saref:hasTimeStamp "2021-03-15T12:00:00Z"^^xsd:dateTime .
PROPOSAL: Signal conveys state.
?door a s4lift:DoorConnectionPoint .
?door saref:hasState ?openclosestate .
?openclosestate a saref:OpenState .
?signal a s4lift:Signal .
?signal s4lift:conveys ?openclosestate.
Overload
PROPOSAL:
- define state s4lift:OverloadedState rdfs:subClassOf saref:State
- status signal can convey state
DetectedLoad
PROPOSAL:
- define state s4lift:DetectedLoadState rdfs:subClassOf saref:State
- status signal can convey state
inspectionOperation
PROPOSAL:
- define state s4lift:InspectionOperationState rdfs:subClassOf saref:State
- status signal can convey state
fireOperation
PROPOSAL:
- define state s4lift:FireOperationState rdfs:subClassOf saref:State
- status signal can convey state
testRideInExecution
PROPOSAL:
- define state s4lift:TestRideInExecutionState rdfs:subClassOf saref:State
- status signal can convey s4lift:TestRideInExecutionState.
TestRideCommand is not what we need . We don't need to "test the ride" we need to "do a test ride"
PROPOSAL:
- delete s4lift:TestRideCommand
realTimeMode
PROPOSAL:
- define state s4lift:RealTimeModeState rdfs:subClassOf saref:State
- status signal can convey state
Statistics Signals
PROPOSAL:
- The statistics signals convey statistics measurements over a period of time. usually from the last reset. Sometimes the statistics are about the number of executions of a command.
- define s4lift:StatisticsMeasurement rdfs:subClassOf saref:Measurement: "A measurement of some statistics of a feature of interest"
numberOfCalls, upwardTravels, downwardTravels, totalFloorsCovered, numberOfResetSequences, totalReversalDirection
PROPOSAL:
- s4lift:{ CamelCase(name) }Statistics rdfs:subClassOf s4lift:StatisticsMeasurement
- status signal can convey statistics
callsPerService
PROPOSAL:
- use s4lift:NumberOfCallsStatistics applied to a possible car service.
?stat a s4lift:NumberOfCallsStatistics ;
saref:hasValue 137 ;
saref:isMeasurementOf ?service .
?service a s4lift:PossibleSmartLiftCarService .
carTemperature, engineRoomTemperature, shaftTemperature
PROPOSAL:
- define s4lift:hasCarTemperature rdfs:subPropertyOf saref:hasProperty
- define s4lift:hasEngineRoomTemperature rdfs:subPropertyOf saref:hasProperty
- define s4lift:hasShaftTemperature rdfs:subPropertyOf saref:hasProperty
- use saref:Temperature property
?sli a s4lift:SmartLiftInstallation ;
saref:hasCarTemperature ?temperature .
?temperature a saref:Temperature .
?measure a saref:Measurement ;
saref:hasValue "34 Cel"^^cdt:ucum ;
saref:relatesToProperty ?temperature .
threephasePowerConsumption, singlephasePowerConsumption, servicesPowerConsumption
PROPOSAL:
- have only s4lift:hasElectricPowerConsumption, and attach it to the appropriate feature of interest: the three-phase connection point, a system that groups lights, etc.
?sli a s4lift:SmartLiftInstallation ;
saref:hasElectricPowerConsumption ?consumption .
?consumption a saref:Energy .
?measure a saref:Measurement ;
saref:hasValue "127 kWh"^^cdt:ucum ;
saref:relatesToProperty ?consumption .
realTimeInformation
PROPOSAL:
- not modeled
Faults
PROPOSAL:
- define s4lift:FaultSignal rdfs:subClassOf s4lift:Signal, comment "A signal describing some fault."
many faults are mentioned in TR 103 546, but not in TS 103 735 . The source of information should be the TS.
PROPOSAL:
- delete superfluous s4lift:AudioFault s4lift:DangerousFault
floodInTheWell
PROPOSAL:
- define state s4lift:FloodInTheWellState rdfs:subClassOf saref:State
- status signal can convey s4lift:FloodInTheWellState.
faults from EN 627
PROPOSAL:
- define s4lift:SmartLiftInstallationFaultState comment "A faulty state of a smart lift. The fault rdf:label shall be one of the values defined in EN 627, (e.g.: "01xx" broken security chain)."
- use the saref:hasTimeStamp for this.
?sli a s4lift:SmartLiftInstallation .
?sli saref:hasState ?fault .
?fault a saref:SmartLiftInstallationFaultState .
?fault rdfs:label "01xx" .
?fault saref:hasTimeStamp "2020-05-03T12:00:00Z"^^xsd:dateTime .
?signal a s4lift:Signal .
?signal s4lift:conveys ?fault.
General Commands in TS 103 735
sendCarToSpecificService, setOutOfService, testEmergencyNumber, mainBoardReset, testRide, setRealTimeMode
Current SAREF4LIFT has SendCarToSpecificFloorCommand. However the floor is not a service. there can be more than one service at a given floor.
PROPOSAL:
- define commands such as s4lift:SendCarToSpecificServiceCommand rdfs:subClassOf saref:Command
Real Time Mode Signals
PROPSOAL:
- do not model
Power Supply Signals
emergencyBatteryPower
PROPOSAL:
- model as a state for a generic battery.
- s4lift:BatteryPowerState rdfs:subClassOf s4lift:BatteryPowerState
- s4lift:GoodBatteryPowerState rdfs:subClassOf s4lift:BatteryPowerState
- s4lift:WarnBatteryPowerState rdfs:subClassOf s4lift:BatteryPowerState
- s4lift:CriticalBatteryPowerState rdfs:subClassOf s4lift:BatteryPowerState
- s4lift:InsufficientBatteryPowerState rdfs:subClassOf s4lift:BatteryPowerState
?sli a s4lift:SmartLiftInstallation .
?sli s4lift:connectedToEmergencyBattery ?battery .
?battery saref:hasState ?warn .
?warn a saref:WarnBatteryPowerState .
standardPowerSupply
PROPOSAL:
- define states s4lift:PowerSupplyState, s4lift:StandardPowerSupplyState, s4lift:EmergencyPowerSupplyStat
alarmSOSSystemPower
PROPOSAL:
- define s4lift:hasAlarmSOSSystem, which is a sub-system of the s4syst:System
?sli a s4lift:SmartLiftInstallation .
?sli s4lift:hasAlarmSOSSystem ?alarmSOSSystem .
?alarmSOSSystem s4lift:connectedToEmergencyBattery ?battery .
?alarmSOSSystem saref:hasState ?emergency .
?emergency a s4lift:EmergencyPowerSupplyState .
?battery saref:hasState ?good .
?good a s4lift:GoodBatteryPowerState .
TS 103 735 Table 6.13-1: Information group name: BCSConfiguration
homeNetworkOperator
PROPOSAL:
- not modeled
supportedNetworkTechnologies
PROPOSAL:
- s4lift:canConnectToNetwork rdfs:subPropertyOf s4syst:connectedTo
- delete supportsNetworkTechnology, use s4lift:canConnectToNetwork instead
- s4lift:Network rdfs:subClassOf s4syst:System
- s4lift:Network2G a s4lift:Network , ...
?sli a s4lift:SmartLiftInstallation .
?sli s4lift:canConnectToNetwork s4lift:Network2G .
liftTelephoneNumber, mainEmergencyNumber
PROPOSAL:
- s4lift:hasTelephoneNumber range xsd:anyURI - The value is expected to be a URI with the tel: URI scheme as defined RFC 3966
- s4lift:hasMainEmergencyTelephoneNumber range xsd:anyURI - The value is expected to be a URI with the tel: URI scheme as defined RFC 3966
?sli a s4lift:SmartLiftInstallation .
?sli s4lift:hasTelephoneNumber "tel:+123456789"^^xsd:anyURI .
otherEmergencyNumbers
PROPOSAL:
- s4lift:hasSecondaryEmergencyTelephoneNumber range xsd:anyURI - The value is expected to be a URI with the tel: URI scheme as defined RFC 3966
TS 103 735 Table 6.14-1: Information group name: BCSAlarms
PROPOSAL:
- Alarms are signals that convey a abnormal state about an entity
- s4lift:AlarmSignal rdfs:subClassOf s4lift:Signal
- comment from ISO 11064-5 "High priority signal used to attract the operator’s attention to important deviations or abnormal events in system operation (from ISO 11064-5:2008)"@en
- s4lift:AlarmState rdfs:subClassOf s4lift:State
many alarms are mentioned in TR 103 546, but not in TS 103 735 . The source of information should be the TS.
PROPOSAL:
- delete superfluous concepts
alarmInTheCar, alarmInTheWell, alarmInTheRoof,
PROPOSAL:
- model as a state of the smart lift installation
alarmInOtherPlace
PROPOSAL:
- only model s4lift:AlarmInTheMachineryState
Is modeled by the s4lift:BoardResetCommand
: a device may have this type of command.
Execution of commands cannot be modeled in SAREF. If they were, they could have some sender, some receiver, and some saref:hasTimestamp. The timestamp of the last reset command execution sent to the smart lift could be retrieved using a SPARQL query.
alarmAcknowledgement
unsufficiently described.
PROPOSAL:
- not model.
TS 103 735 Table 6.15-1: Information group name: BCSSignals
timeOfLastPeriodicTest72hAttempt and timeOfConfirmationOfLastPeriodicTest72hAttempt
PROPOSAL:
- define s4lift:hasTimeOfLastPeriodicTest72hAttempt rdfs:subPropertyOf saref:hasProperty
- define s4lift:TimeOfConfirmationOfLastPeriodicTest72hAttempt rdfs:subPropertyOf saref:hasProperty
?sli a s4lift:SmartLiftInstallation ;,
s4lift:hasTimeOfLastPeriodicTest72hAttempt ?timeOfLastPeriodicTest72hAttempt .
?measure a saref:Measurement .
?measure saref:relatesToProperty ?timeOfLastPeriodicTest72hAttempt .
?measure saref:hasValue "2020-03-05T12:00:00.000Z"^^xsd:dateTime ;
registeredNetworkOperator
unsufficiently described.
PROPOSAL:
- not model.
networkQualityRSSI, networkQualityBER
PROPOSAL:
- define 4lift:NetworkAccess rdfs:subClassOf s4syst:Connection ;
- define s4lift:hasReceivedSignalStrengthIndicator rdfs:subPropertyOf saref:hasProperty
- define s4lift:hasChannelBitErrorRate rdfs:subPropertyOf saref:hasProperty
expand RSSI
other considerations from the previous version of SAREF4LIFT
BCSSignal
BCS only means that the signal could have been emited by one or the other party.
PROPOSAL: delete the BCSSignal.
s4lift:receives and TEST LIFT-TEST-20;LIFT-20
why this object property with no domain ? and range BCSSignal (=bidirectional communication system signals). how is it intended to be used ?
I think the test LIFT-TEST-20;LIFT-20 SmartLiftInstallation receives BCSSignal should be deleted.
the BCSSignal are bidirectional. This just means that initator of the interaction can be the smart lift installation or the supervisor.
PROPOSAL: delete s4lift:receives and TEST LIFT-TEST-20;LIFT-20
s4lift:sendsCommand . Who sends commands ? should we use past tense like madeObservation or madeActuation, -> sentCommand ?
PROPOSAL: delete s4lift:sentCommand
saref:hasManufacturer has domain s4lift:SmartLiftInstallation and
range xsd:string, unlike in saref. as the value can be string with language tag, rdf:langString should be allowed
PROPOSAL: delete over specifications of saref:SmartLiftInstallation to avoid namespace hijacking
s4lift:hasBuildingManager s4lift:hasInstallerCompany
PROPOSAL:
- adapt to SAREF4SYST
- use same definition pattern as saref:hasManufacturer: "The value is expected to be a string or a string with language tag."
network value has no anchoring in the TS 103 735
PROPOSAL: delete s4lift:hasNetworkValue
hasStatusValue and hasStatisticValue
in TS 103735, it's not necessary that status signals are always booleans, and statistic signals are always integers.
PROPOSAL: simply use the saref:hasValue on s4lift:Signal, and see how to use it.
hasPositionValue has no anchoring in the TS 103 735, and is not used.
PROPOSAL: delete
NetworkCoverage
is associated with the coverage of the network. why subclass of BCSSignal
NetworkCoverageSignal: all we are insterested in is that that signal is associated with some measurement or state of the network coverage
individual Percentage is not used
PROPOSAL: delete.
networkQualityBER
BER is Channel Bit Error Rate: property of the network connection.
reset
Is modeled by the s4lift:BoardResetCommand
: a device may have this type of command.
Execution of commands cannot be modeled in SAREF. If they were, they could have some sender, some receiver, and some saref:hasTimestamp. The timestamp of the last reset command execution sent to the smart lift could be retrieved using a SPARQL query.
numberoffaults
isn't mentioned in TS 103 735 . Instead, there is a sequence of faults. Since the last reset.
If command executions were modeled in SAREF, the sequence of faults since the last board reset command could be retrieved using a SPARQL query:
s4lift:OutOfService s4lift:Overloaded
Correspond to states.
s4lift:CurrentCarStop s4lift:PositionSignal
PROPOSAL: delete: is just some sort of multilevel state
s4lift:TotalTimeOpened not mentioned in TS 103 735
PROPOSAL: delete.
many signals are mentioned in TS 103 735 but not in SAREF4LIFT
PROPOSAL: add measurement or state when required.
TotalReverseDirection is TotalReversalDirection in TS 103 735
PROPOSAL: change