SAREF issueshttps://labs.etsi.org/rep/groups/saref/-/issues2024-03-28T13:04:21Zhttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/32Why is MeasurementCollectionSession a sub-class of saref:Task ?2024-03-28T13:04:21ZMaxime LefrançoisWhy is MeasurementCollectionSession a sub-class of saref:Task ?MeasurementCollectionSession is defined as "Task in which a health actor (mainly a patient or a user) is subject of measurement collection (recording) by both some measurement-related health Device (e.g. Sensor, Wearable, ECG Device...) ...MeasurementCollectionSession is defined as "Task in which a health actor (mainly a patient or a user) is subject of measurement collection (recording) by both some measurement-related health Device (e.g. Sensor, Wearable, ECG Device...) and a health actor (mainly a caregiver)."
Domain of OP s4ehaw:hasParticipant "A measurement session has health actors as participants (caregiver controling the session, patient monitored during the session)."@en
Remarks:
- Measurement is deprecated
- A MeasurementCollectionSession represents an activity, more than a Task "The goal for which a device is designed, from a user perspective."
Proposed change:
rename MeasurementCollectionSession into ObservationCollectionExecution, define as a sub-class of ProcedureExecution (with phenomenonTime, resultTime, etc.), use madeBy to link to the HealthActor or the Device that made it, use observes to link to the patient ... use hasResult to link to the result, an ObservationCollectionV2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/31Modelling Functions and Commands2024-03-28T12:55:30ZMaxime LefrançoisModelling Functions and CommandsSAREF4EHAW defines one sub-class of saref:Function and two sub-classes of saref:Command:
- s4ehaw:MeasurementFunction rdfs:comment "The functionality necessary to accomplish the measurement task for which a measurement-related health De...SAREF4EHAW defines one sub-class of saref:Function and two sub-classes of saref:Command:
- s4ehaw:MeasurementFunction rdfs:comment "The functionality necessary to accomplish the measurement task for which a measurement-related health Device (e.g. Sensor, Wearable, ECG Device...) is designed for, e.g. a heart rate measurement function."@en
- s4ehaw:AlarmCommand rdfs:comment "A command corresponding to alarm sending."@en
- s4ehaw:ReminderCommand rdfs:comment "Command used for sending reminder notifications to health actors, e.g. patients, users or Caregivers."@en
Commands are low-level directives that a device implements, and are logically grouped in functions.
## MeasurementFunction
Remarks:
- this definition assumes the existence of a Task named "measurement"
- class Measurement is deprecated (See #14 )
- the name is generic but the definition focuses on health Devices
## Commands
The name of commands look more like functions, and some specific commands could be defined for each
```
:AlarmFunction a saref:Function .
:TriggerAlarm a saref:Command ; saref:isCommandOf :AlarmFunction .
:SnoozeAlarm a saref:Command ; saref:isCommandOf :AlarmFunction .
...
:ReminderFunction a saref:Function .
:SendReminder a saref:Command ; saref:isCommandOf :ReminderFunction .
...
```V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/30Modelling Services, including ServiceProcess, ServiceProfile2024-03-28T11:51:01ZMaxime LefrançoisModelling Services, including ServiceProcess, ServiceProfileSAREF4EHAW extends the definition of saref:Service with ServiceProcess and ServiceProfile
- ServiceProcess: "How the service works."@en
- OP s4ehaw:isDescribedBy links a Service to the ServiceProcess: "A service is described by a s...SAREF4EHAW extends the definition of saref:Service with ServiceProcess and ServiceProfile
- ServiceProcess: "How the service works."@en
- OP s4ehaw:isDescribedBy links a Service to the ServiceProcess: "A service is described by a service process (how the service works)."@en
- ServiceProfile: "A service presents a service profile (what the service does)."@en
- OP s4ehaw:presents "A service presents a service profile (what the service does)."@en
General remarks:
- Why an intermediate class ? why not attaching these properties directly to the Service ?
- the Service actually groups operations. Operations are executed. Not the service
Proposed change: Attach whatever is attached to these intermediate classes to the service directly, unless there a service may have more than one process / more than one profile, etc.
In details:
## ServiceProcess
Related:
- hasCalculationMethod rdfs:comment "The service process has a calculation method to get the output or result, e.g. the calculation formula to determine the posture of a patient."@en
- hasEffect rdfs:comment "The effect of a service can be an alert, nothing, an activation of another process..."@en
- hasInput rdfs:comment "The service process has data input like e.g. the patient ID, the timestamp, the read value from a sensor..."@en
- hasOutput rdfs:comment "The output is e.g. the calculated value returned by the process, e.g the posture of a patient."@en
- hasResult rdfs:comment "The process can have many results for the same output. Those results may include a message that should be displayed, an alert..."@en
- hasPrecondition rdfs:comment "The conditions that are imposed over the inputs of the process and the process must hold to be successufully invoked."@en
Notes:
- Why just "the posture" ?
- SAREF already introduces hasInput, hasOutput, hasResult. hasEffect and hasPrecondition could be re-defined to be applicable along saref:hasInput / saref:hasOutput
## ServiceProfile
- DP serviceDescription domain ServiceProfile, range xsd:string
- DP serviceName domain ServicePRofile, range xsd:string
Proposed change:
Reuse standard rdfs:label, rdfs:comment, dct:descriptionV2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/29Modelling ServiceGrounding2024-03-28T11:39:59ZMaxime LefrançoisModelling ServiceGroundingServiceGrounding is defined as "How to access the service."@en
Related:
- OP supports "A service supports a service grounding (how to access the service)." domain Service, range ServiceGrounding
- OP groundingProtocol "The grounding pr...ServiceGrounding is defined as "How to access the service."@en
Related:
- OP supports "A service supports a service grounding (how to access the service)." domain Service, range ServiceGrounding
- OP groundingProtocol "The grounding protocol is the protocol used to transmit the message by the service, e.g. BLE."@en, range CommunicationProtocol (see #18 )
- DP portNumber "The port number used to offer the service." range xsd:positiveInteger (assumes the service is UDP or TCP see RFC 6335)
Suggested changes:
As the service is the digital representation of a function over a network, we could directly attach the port and the protocol to the service.
We're indeed missing a link between the Service and the network over which it is available. This network could be a Connection/FeatureKind (the type of communication protocol), or a specific Connection/FeatureOfInterest (the specific network).
Extending how the SAREF Patterns are defined, we could introduce:
the port should be a property of the ConnectionPoint of the device through which the service is available. (see #26 )
s4ehaw:exposedOn a OP domain Service, range intersection( union( FeatureKind, FeatureOfInterest), union(Connection, ConnectionPoint))
In practice, exposedOn can be used to link a service to a Connection/FeatureKind (ex, Bluetooth), to a Connection/FeatureOfInterest (ex, <this_network> ), to a ConnectionPoint/FeatureKind (ex, TCPPort), to a connectionPoint/FeatureOfInterest (ex., <tcp_port_4255)V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/28Modelling Operating Constraints2024-03-28T11:23:46ZMaxime LefrançoisModelling Operating ConstraintsClass OperatingConstraint is defined as: "An empty container for describing the operating constraints of a device, e.g. recommended humidity and temperature range..."@en
Range of OP hasOperatingConstraint "The operating constraints of...Class OperatingConstraint is defined as: "An empty container for describing the operating constraints of a device, e.g. recommended humidity and temperature range..."@en
Range of OP hasOperatingConstraint "The operating constraints of a health device, e.g. recommended humidity and temperature range..."@en
Suggested change: delete and reuse the SAREF Core pattern for properties
```
Recommended a saref:Property "The recommended property values for some entity"
MinimumRecommended a saref:Property "The minimum recommended property value for some entity" ; skos:broader Recommended
MaximumRecommended a saref:Property "The maximum recommended property value for some entity" ; skos:broader Recommended
```
In practice:
```
<device> a saref:Device ;
hasPropertyValue [ saref:hasValue "10 CEL"^^cdt:ucum ; saref:isValueForProperty <temperature> , <mininmumRecommended> ]
```V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/27Modelling Location2024-03-28T11:18:32ZMaxime LefrançoisModelling LocationRelated:
- Class Location "The location, i.e. a position against the body (on - body surface – or in the body – implant –) and a physical location (i.e. a postal address and/or a current geolocation when available)."@en
- sub-class Bod...Related:
- Class Location "The location, i.e. a position against the body (on - body surface – or in the body – implant –) and a physical location (i.e. a postal address and/or a current geolocation when available)."@en
- sub-class BodySurfaceLocation "Defines a health device location in terms of a body surface position (i.e. on body health device)."@en with two instances:
- ArmpitLocation rdfs:comment "Armpit location, a user body surface location."@en
- WristLocation rdfs:comment "Wrist, a user body surface location."@en
- sub-class ImplantLocation rdfs:comment "Implant Device (i.e. in body health device) position."@en
- sub-class PhysicalLocation "The physical location, i.e. a postal address and a geolocation when available."@en
In general, this class is used to model heterogeneous things.
In details
## BodySurfaceLocation and ImplantLocation
The BodySurfaceLocation and ImplantLocation can be better modeled using the SAREF Core pattern for states, and be harmonized with the SAREF4WEAR extension. (defines OPs locatedIn, locatedOn, locatedNear)
```
WearableLocation rdfs:subClassOf saref:State
WeardOnBodySurface a :WearableLocation
ArmpitWeared a :WearableLocation ; skos:broader WeardOnBodySurface .
WristWeared a :WearableLocation ; skos:broader WeardOnBodySurface .
ImplantedInBody a :WearableLocation .
```
in practice:
```
<sensor> saref:hasState WristWeared
```
## PhysicalLocation
Related:
- OP hasPhysicalLocation domain Patient (could be relaxed!)
- DP geolocation rdfs:comment "The geolocation, when available, shall be given relatively to the current location - geolocation as standardized ISO 6709, e.g. +40.75-074.00/ -."@en range xsd:string
- DP postalAddress rdfs:comment "Defines the postal address."@en range xsd:string
Clause 5.13 of TS 103 264 (Features of Interest, devices, and spatial objects) states that features of interest can also be geo:Feature, and be described with the GeoSPARQL standard in terms of geolocation.
If we need the physical address, we could state that the OP hasLocation links a geo:Feature to a [vcard:Location](http://www.w3.org/2006/vcard/ns#Location) of the W3C VCard vocabulary in RDF (see https://www.w3.org/TR/vcard-rdf/#d4e1865)
Also the PhysicalLocation may be considered as a property. See https://labs.etsi.org/rep/saref/saref-portal/-/issues/58
There may be a saref:Property observed by a sensor (ex GPS) or controlled by an actuator (ex robotic arms)
```
PhysicalLocation a saref:Property .
PhysicalAddress skos:broader PhysicalLocation .
```V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/26Modelling Interfaces (e.g., Bluetooth, UWB, IEEE 802.15.6, ...)2024-03-28T11:40:00ZMaxime LefrançoisModelling Interfaces (e.g., Bluetooth, UWB, IEEE 802.15.6, ...)Related:
- Class Interface: "Used for modelling the interfaces of a health device (e.g. Bluetooth, UWB, IEEE 802.15.6, serial interface...)."@en
- OP hasInterface: "A health device has one or multiple interfaces (Bluetooth, UWB, IEEE 8...Related:
- Class Interface: "Used for modelling the interfaces of a health device (e.g. Bluetooth, UWB, IEEE 802.15.6, serial interface...)."@en
- OP hasInterface: "A health device has one or multiple interfaces (Bluetooth, UWB, IEEE 802.15.6, serial interface...)."@en domain HealthDevice, range Interface
- DP interfaceAddress "The interface address. The interface may have many addresses like MAC address, IP address or others."@en domain Interface range string
- DP interfaceDescription "The interface type description."@en range string
- OP interfaceProtocol "The interface communication protocol can be e.g. BLE, serial, Ethernet..."@en range CommunicationProtocol (see #18 )
- DP isGateway "This boolean variable indicates if the interface is a gateway or not."@en range xsd:boolean
- DP transmissionRate "The transmission rate of the interface, i.e. the number of bits transmitted per second (usually expressed in kbps or Mbps)."@en range xsd:float
Proposed change: rename Interface -> CommunicationInterface, and model communication interfaces as s4syst:ConnectionPoint at which systems can connect to a network.
In details:
## interfaceAddress
delete and define sub-properties of saref:hasIdentifier --> saref:hasMACAddress, saref:hasIPAddress, ...
## interfaceDescription
delete, we can use standard rdfs:label, rdfs:comment, dct:description
## interfaceProtocol
Instances Bluetooth, UWB, IEEE 802.15.6, ... should be defined once and used in many places. Best modelled as FeatureKind. The CommunicationInterface may be of that kind. In practice:
```
<device> connectsAt <device#bluetoothInterface> .
<device#bluetoothInterface> a CommunicationInterface ; hasFeatureKind <Bluetooth> .
```
## isGateway
A device (connected at a certain communication interface to a certain communication network) be the gateway for the network. This is a role, and as such, it should be modelled using some OP . For example, OP hasGateway a sub-property of s4syst:connectsSystem
`hasGateway a owl:ObjectProperty; rdfs:subPropertyOf s4syst:connectsSystem`
Some Devices are designed to actually serve the role of a gateway. It may make sense to define a featurekind Gateway for these.
`saref:Gateway a saref:FeatureKind`
## transmissionRate
DP transmissionRate rdfs:comment "The transmission rate of the interface, i.e. the number of bits transmitted per second (usually expressed in kbps or Mbps)."@en
Better use the SAREF core pattern for properties
`TransmissionRate a saref:Property`.V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/25Modelling Impairments2024-03-28T10:11:02ZMaxime LefrançoisModelling Impairmentsclass Impairment is defined as "Defined for users (that can in particular be patients) impairments modelling, e.g. aural impairment, skeletal impairment, ocular impairment, mobility impairment, intellectual impairment. Those non exhausti...class Impairment is defined as "Defined for users (that can in particular be patients) impairments modelling, e.g. aural impairment, skeletal impairment, ocular impairment, mobility impairment, intellectual impairment. Those non exhaustive impairments are compatible with the World Health Organization classification."@en and has five instances:
- s4ehaw:AuralImpairment rdfs:comment "Aural impairment (User level), i.e. impairments of auditory sensitivity."@en
- s4ehaw:IntellectualImpairment rdfs:comment "Skeletal impairment (User level), e.g. ..."@en
- s4ehaw:MobilityImpairment rdfs:comment "Mobility impairment (User level)."@en
- s4ehaw:OcularImpairment rdfs:comment "Ocular impairment (User level), i.e. impamnents of visual acuity."@en
- s4ehaw:SkeletalImpairment rdfs:comment "Skeletal impairment (User level), e.g. of head and trunk regions, limbs..."@en
Proposed change: use SAREF Core pattern for states
```
s4ehaw:Impairment rdfs:subClassOf saref:State .
s4ehaw:AuralImpairment a s4ehaw:Impairment .
s4ehaw:MobilityImpairment a s4ehaw:Impairment .
s4ehaw:IntellectualImpairment a s4ehaw:Impairment .
s4ehaw:OcularImpairment a s4ehaw:Impairment .
s4ehaw:SkeletalImpairment a s4ehaw:Impairment .
```
in practice:
```
<user> saref:hasState s4ehaw:OcularImpairment
```
Then the state of interest of the user can be used to qualify further this OcularImpairment .V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/24Modelling Habits2024-03-28T10:09:15ZMaxime LefrançoisModelling Habitsclass Habits is defined as "Defined for users (that can in particular be patients) habits modelling, e.g. smoking, alcohol drinking, overeating, undereating..."@en and has four instances:
- s4ehaw:AlcoholDrinking rdfs:comment "Alcohol ...class Habits is defined as "Defined for users (that can in particular be patients) habits modelling, e.g. smoking, alcohol drinking, overeating, undereating..."@en and has four instances:
- s4ehaw:AlcoholDrinking rdfs:comment "Alcohol drinking habit (User level)."@en
- s4ehaw:Overeating rdfs:comment "Overeating habit (User level)."@en
- s4ehaw:Smoking rdfs:comment "Smoking habit (User level)."@en
- s4ehaw:Undereating rdfs:comment "Undereating habit (User level)."@en
Proposed change: use SAREF Core pattern for states
```
s4ehaw:Habit rdfs:subClassOf saref:State .
s4ehaw:AlcoholDrinkingHabit a s4ehaw:Habit .
s4ehaw:OvereatingHabit a s4ehaw:Habit .
s4ehaw:SmokingHabit a s4ehaw:Habit .
s4ehaw:UndereatingHabit a s4ehaw:Habit .
```
in practice:
```
<user> saref:hasState s4ehaw:AlcoholDrinkingHabit
```
Then the state of interest of the user can be used to qualify further this AlcoholDrinkingHabit.V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/23Modelling DeviceCharacteristic including deviceCharacteristicName, dimension,...2024-03-28T10:04:41ZMaxime LefrançoisModelling DeviceCharacteristic including deviceCharacteristicName, dimension, ComputingPower, Mode, PowerSource, velocityThis is an unnecessary intermediate class between the device and its characteristics, and should be deleted.
Proposed change: delete class DeviceCharacteristic.
## DP deviceCharacteristicName
DP deviceCharacteristicName "The commercia...This is an unnecessary intermediate class between the device and its characteristics, and should be deleted.
Proposed change: delete class DeviceCharacteristic.
## DP deviceCharacteristicName
DP deviceCharacteristicName "The commercial name of a device."@en
Proposed change: delete and use existing DPs saref:hasModel and saref:hasManufacturer
## DP dimension
DP dimension: "The dimension of the device i.e. height*weight*length string."@en
Why weight ? should it be width ?
Proposed change: delete and use SAREF Core pattern for properties : define instances of saref:Property:
- s4ehaw:Height a saref:Property
- s4ehaw:Weight a saref:Property
- s4ehaw:Length a saref:Property
- s4ehaw:Width a saref:Property
- s4ehaw:Dimensions a saref:Property ; saref:consistsOf s4ehaw:Height, s4ehaw:Width, s4ehaw:Length
## ComputingPower
- OP hasComputingPower: "A health device characteristic describing the processing power or capabilities of the device (e.g. processor ID and manufacturer, duty cycle, available flash/RM memory, maximum flash/RAM memory...)."
- Class ComputingPower: "The computing power capabilities of a Health device."
- DP dutyCycle: "The duty cycle for each health device embedded processor, in percent."@en
- DP frequency: "The frequency is the number of instructions an embedded processor - within a health device - can perform per second (MIPS)."@en
- DP maximumFlash "Indicates the maximum flash memory space (in byte) of a health device."@en
- DP maximumRam "Indicates the maximum volatile memory space (in byte) of a health device."@en
Proposed change: delete and use SAREF Core pattern for features, and SAREF Core pattern for properties:
Define instances of saref:Property:
- ComputingPower a saref:Property ; isPropertyOf Device ; consistsOf DutyCycle , CPUFrequency , maximumFlash , maximumRam
- DutyCycle a saref:Property
- CPUFrequency a saref:Property
- maximumFlash a saref:Property
- maximumRam a saref:Property
## Mode
See #1
## PowerSource
Related:
- Class PowerSource: "The power sources of a health device, mainly describing energy source and battery related capabilities of the health device (number of power source, source type, rechargeable or not...)."@en
- OP hasPowerSource: "A health device characteristic is its power sources, mainly describing energy source and battery related capabilities of the health device (number of power source, source type, rechargeable or not, available power level...)."@en
- DP powerSourceType "The type of power source of a health device. It can be solar, battery, electricity..."@en domain PowerSource, range xsd:string
- DP rechargeable "This boolean variable indicates if the power source is rechargeable or not, e.g. a rechargeable battery."@en domain PowerSource, range xsd:boolean
Proposed change: Use SAREF Core patterns
```
SolarPowered a saref:FeatureKind
BatteryPowered a saref:FeatureKind
MainsPowered a saref:FeatureKind
Rechargeable a saref:FeatureKind
NonRechargeable a saref:FeatureKind
NumberOfPowerSource a saref:Property
AvailablePowerLevel a saref:Property
```
Note that Bluetooth has many properties and characterisics to describe the power source or battery status and level. Can we reuse these definitions @guillemin ?
## velocity
DP velocity "The velocity of a moving device (in m/s)."@en domain DeviceCharacteristic, range xsd:float.
Proposed change: Use SAREF Core pattern for properties.
```
Velocity a saref:Property
```V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/22Modelling ChronicDisease2024-03-28T09:39:19ZMaxime LefrançoisModelling ChronicDiseaseRelated:
- Class ChronicDisease: "For chronic disease modelling, e.g. diabetes, asthma..."@en, with instances
- Asthma "Asthma, a chronical disease that some users can have."@en
- Diabetes "Diabetes, a chronical disease that so...Related:
- Class ChronicDisease: "For chronic disease modelling, e.g. diabetes, asthma..."@en, with instances
- Asthma "Asthma, a chronical disease that some users can have."@en
- Diabetes "Diabetes, a chronical disease that some users can have."@en
- OP hasChronicDisease: "A patient can suffer from one or more chronic disease like Diabetes, azma, etc."@en domain Patient, range ChronicDisease
The SAREF Core pattern for states can be applied.
Suggested change: Delete the terms above, and define:
- `ChronicDisease a saref:State` "The situation of a patient that suffers from chronic disease, e.g. diabetes, asthma..."
- `Asthma skos:broader ChronicDisease` "The situation of a patient that suffers from asthma, a chronic disease"
- `Diabetes skos:broader ChronicDisease` "The situation of a patient that suffers from diabetes, a chronic disease"
In practice:
```
<patient> saref:hasState s4ehaw:Asthma .
<sensor> saref:observes s4ehaw:Asthma .
```
...V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/21Modelling BAN application domain2024-03-28T09:25:53ZMaxime LefrançoisModelling BAN application domainBAN application domain is defined as "The BAN application domain, e.g. healthcare, telemedicine, assisted living, sport training, safety and emergency..."@en
and it contains instances
- s4ehaw:AssistedLiving
- s4ehaw:Emergency
- s4ehaw...BAN application domain is defined as "The BAN application domain, e.g. healthcare, telemedicine, assisted living, sport training, safety and emergency..."@en
and it contains instances
- s4ehaw:AssistedLiving
- s4ehaw:Emergency
- s4ehaw:Healthcare
- s4ehaw:PervasiveComputing
- s4ehaw:Prevention
- s4ehaw:Safety
- s4ehaw:SportTraining
- s4ehaw:Telemedicine
SAREF Core pattern for Tasks seems suitable for this, and should be used instead.
It's the range of OP s4ehaw:hasBanApplicationDomain. This OP could be dropped, as the OP saref:accomplishes can be used instead.
We're left with:
```
s4ehaw:AssistedLiving a saref:Task .
s4ehaw:Emergency a saref:Task .
s4ehaw:Healthcare a saref:Task .
s4ehaw:PervasiveComputing a saref:Task .
s4ehaw:Prevention a saref:Task .
s4ehaw:Safety a saref:Task .
s4ehaw:SportTraining a saref:Task .
s4ehaw:Telemedicine a saref:Task .
```V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/20Modeling AgeCategory2024-03-28T09:17:46ZMaxime LefrançoisModeling AgeCategoryAgeCategory is defined as "The age group of a health actor, e.g. old or young."@en
The SAREF Core pattern for states can be used to model the AgeCategory.
```
s4ehaw:AgeCategory a saref:State .
s4ehaw:Old a saref:State ; skos:broader s4...AgeCategory is defined as "The age group of a health actor, e.g. old or young."@en
The SAREF Core pattern for states can be used to model the AgeCategory.
```
s4ehaw:AgeCategory a saref:State .
s4ehaw:Old a saref:State ; skos:broader s4ehaw:AgeCategory .
s4ehaw:Young a saref:State ; skos:broader s4ehaw:AgeCategory .
```
And in practice:
```
<actor> saref:hasState s4ehaw:Old .
```V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/19Modeling activities2024-03-28T09:14:54ZMaxime LefrançoisModeling activitiesActivities are "The activity of a patient/user, i.e. daily and nocturnal activities."
Activity has an activityKind (datatype property), and two sub-classes: s4ehaw:DailyActivity and s4ehaw:NocturnalActivity
These sub-classes sound like...Activities are "The activity of a patient/user, i.e. daily and nocturnal activities."
Activity has an activityKind (datatype property), and two sub-classes: s4ehaw:DailyActivity and s4ehaw:NocturnalActivity
These sub-classes sound like kinds of activities actually.
Arguably the SAREF Core pattern for states cannot represent activities, but it may be appropriate that SAREF4EHAW defines a similar pattern for activities.V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/18define s4ehaw:CommunicationProtocol as Connection and FeatureKind2024-03-28T11:39:59ZMaxime Lefrançoisdefine s4ehaw:CommunicationProtocol as Connection and FeatureKinds4ehaw:CommunicationProtocol is defined as "The communication protocol, e.g. BLE, serial, Ethernet..."@en
This class should be defined as sub-class of s4syst:Connection and saref:FeatureKind.s4ehaw:CommunicationProtocol is defined as "The communication protocol, e.g. BLE, serial, Ethernet..."@en
This class should be defined as sub-class of s4syst:Connection and saref:FeatureKind.V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/17Modelling s4ehaw:BAN2024-03-28T09:19:29ZMaxime LefrançoisModelling s4ehaw:BANBan is a kind of Connection: A connection describes potential interactions between systems. Any two connected systems are connected through a connection. A connection can connect more than two systems at the same time.
This a s4ehaw:BAN...Ban is a kind of Connection: A connection describes potential interactions between systems. Any two connected systems are connected through a connection. A connection can connect more than two systems at the same time.
This a s4ehaw:BAN could be defined as a sub-class of s4syst:Connection, and it `s4syst:connectsSystem` some HealthDevice (but not only)V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/16Modelling BanCommunicationType2024-03-28T09:33:38ZMaxime LefrançoisModelling BanCommunicationTypeThe naming "Type" should be avoided.
Related:
- Class BanCommunicationType: "The BAN communication function type, i.e. periodic, event driven or on request."@en , with sub-classes:
- s4ehaw:EventDrivenBanCommunicationType "BAN com...The naming "Type" should be avoided.
Related:
- Class BanCommunicationType: "The BAN communication function type, i.e. periodic, event driven or on request."@en , with sub-classes:
- s4ehaw:EventDrivenBanCommunicationType "BAN communication function way of working of the type event driven."@en
- s4ehaw:OnRequestBanCommunicationType "BAN communication function way of working of the type on request."@en
- s4ehaw:PeriodicBanCommunicationType "BAN communication function way of working of the type periodic."@en
- OP hasBanCommunicationType : "A BAN has a BAN communication type that is the type of communication carried out between BAN devices and BAN Hub."@en domain Ban, range BanCommunicationType
The term _function_ lets me believe these could be defined as kinds of functions (of communication functions)
The part _the type of communication carried out between BAN devices and BAN Hub_ lets me think it would best qualify the devices themselves, instead of the BAN (the network)
I suggest the following changes:
- delete these classes and properties
- use the SAREF Core pattern for functions to define CommunicationFunction and its narrower functions.V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/15Modes in SAREF4EHAW -> State2024-03-28T08:51:23ZMaxime LefrançoisModes in SAREF4EHAW -> StateModes aren't needed as they are subsumed by States from SAREF CoreModes aren't needed as they are subsumed by States from SAREF CoreV2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/14Class Measurement is deprecated2024-03-28T12:55:31ZMaxime LefrançoisClass Measurement is deprecatedObservation is used instead.
This implies the modification of the following entities:
- s4ehaw:hasMeasurement
- s4ehaw:TimeSeriesMeasurements
- s4ehaw:hasTimeSeriesMeasurement
Furthermore, s4envi:FrequencyMeasurement will be deleted.Observation is used instead.
This implies the modification of the following entities:
- s4ehaw:hasMeasurement
- s4ehaw:TimeSeriesMeasurements
- s4ehaw:hasTimeSeriesMeasurement
Furthermore, s4envi:FrequencyMeasurement will be deleted.V2.1.1_stablehttps://labs.etsi.org/rep/saref/saref4ehaw/-/issues/13Modeling of time series ?2024-03-28T12:57:08ZMaxime LefrançoisModeling 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_stable