# 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

